Closed Bug 1031111 Opened 10 years ago Closed 10 years ago

Some WiFi devices / routers confused by discovery packets

Categories

(DevTools Graveyard :: WebIDE, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: jryans, Assigned: jryans)

References

Details

I recently observed my Flame device fail to respond to discovery packets on a WiFi network at a local coffee shop.

It will take some more testing to get to the core of the issue.

Known so far:

* Flame can be discovered when on my home WiFi network
* Coffee shop's WiFi network had a lot of other UDP multicast packets flying around

Something about *our* UDP multicast usage plus *their* WiFi router is not working out.
Same issue is seen with Nexus 4 on the bad network.

However, my OS X laptop and Ubuntu VM are able to find each other while on the bad network.  I am pretty sure they were talking over WiFi, so this suggests the issue affects all b2g devices when on this network.

To be completely sure, I'd need to bring two laptops to the coffee shop...  I'll think about it. :)
> I am pretty sure they were talking over WiFi

Your VM use your host WiFI to detect the host over WiFi? I think you need 2 laptops to confirm that :)
(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #2)
> > I am pretty sure they were talking over WiFi
> 
> Your VM use your host WiFI to detect the host over WiFi? I think you need 2
> laptops to confirm that :)

Yeah, it was my best effort attempt. :) Maybe I'll get a loaner laptop and try again.
Summary: Some WiFi devices / routes confused by discovery packets → Some WiFi devices / routers confused by discovery packets
I spent quite a while on this problematic network with 2 laptops trying to debug this issue.  Here is the data I gathered:

* Both laptops were connected to the same SSID and BSSID
* They can each reach the public Internet
* The 2 laptops were not able to overhear each other's local packets in Wireshark
  * However, some packets from other machines on the network were overhearable
* Multicast discovery packets sent by laptop A never arrive at B and vice versa
  * However, some multicast protocols like mDNS and SSDP were in use and visible

I was not able to isolate why the machines are "partially" hidden in this way.  My suspicion is a router bug or misconfiguration.

I have not yet seen this behavior on any other WiFi network, so I am hoping it's a rare problem.  Closing for now, but will reopen if we find this is a more frequent issue.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
TL;DR: It looks like Firefox is binding to the wrong interface on the computer and messages are not being sent, or received over the network as a result. 


I think I am experiencing the same root problem you are but in a slightly different context.  I am guessing I should submit a new bug for this, but I cannot reliably reproduce the bug and it is making me question my sanity.  As someone who I believe experienced the same root cause, I am hoping you can help.

I have been trying to make an extension to communicate with devices on the local network over SSDP (UDP multicast).  I have been using the nsIUDPSocket and sometimes (I cannot see a pattern) it will simply fail to send/listen.  I never get an error - if I step through with the debugger it appears the packet was sent or that it is listening.  However the request never makes it off my computer, and other requests that make it to my computer don't show up in Firefox.

Yesterday I had it working all day (never failed and I was working on it for at least 4-6 hours).  Today  however up until about 10 minutes ago when I was writing this I had been trying to get it to work for at least a couple of hours with no success.

I use windows 8.1 64 bit with 32 bit Firefox. Have tried with current Nightly, Dev Edition, and stable and have had it both work and fail on all three versions.

I have been using the Microsoft Message Analyzer and on two separate occasions when it was failing it was trying to send the request out on my wired interface even though it is unplugged and I am on WiFi.  In the Message Analyzer the source IP is the IP assigned to the wired adapter (I have assigned static IPs on the router for each network adapter).  Just to be sure I ran ipconfig and my wireless adapter is showing a different IP than the source from the Message Analyzer.  Also ipconfig doesn't recognize the wired adapter as being plugged in nor does it show the wired adapter as having an IP address.

When it was sending out over the unplugged wired adapter, I was receiving the messages I was sending - but not messages coming from the network - indicating that I was at least listening on the wired adapter. I know about the aLoopbackOnly parameter of the nsIUDPSocket.init function and it is set to false.

I have also tried this with another computer which only has a wired connection.  On at least one occasion when it was failing I could see it being sent out over the IPV4 Loopback interface, but not on the actual wired interface (I don't believe Wireshark will show anything on the loopback interface).


The problem might be bug 1117184 but as of now the description is blank.
I just found bug 1046897.  On my laptop disabling the Ethernet adapter then creating a new UDP Socket resolves my issue.  If you haven't read my previous novel of a post do yourself a favor and don't.
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.