Closed
Bug 1031111
Opened 10 years ago
Closed 10 years ago
Some WiFi devices / routers confused by discovery packets
Categories
(DevTools Graveyard :: WebIDE, defect)
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.
Assignee | ||
Comment 1•10 years ago
|
||
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. :)
Comment 2•10 years ago
|
||
> 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 :)
Assignee | ||
Comment 3•10 years ago
|
||
(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.
Assignee | ||
Updated•10 years ago
|
Summary: Some WiFi devices / routes confused by discovery packets → Some WiFi devices / routers confused by discovery packets
Assignee | ||
Comment 4•10 years ago
|
||
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
Comment 5•9 years ago
|
||
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.
Comment 6•9 years ago
|
||
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.
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•4 years ago
|
Product: DevTools → DevTools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•