0

I have a Raspberry Pi (running Raspbian) and an LB-LINK wireless USB adapter serving as an 802.11n access point with WPA2, running with hostapd and isc-dhcp-server. On the Pi, I have a python script that sends multicast packets about 50 bytes in size at a rate of 25Hz. We've noticed that when a wireless client goes out of range (and sometimes when it comes back into range) of the AP, the AP starts behaving oddly. Specifically, the socket.sendto() command in the python script blocks, and disconnected wireless clients cannot join the network. On Android tablets, the network shows up with 1 bar of signal strength, even though they're right next to the antenna. Clients already connected to the AP seem to stay connected (Wireshark capture from a client that was already connected shows it continuing to exchange packets with the router), and show a full bar of signal strength. Note that the wireless client that goes out of range doesn't have to be part of the multicast group (at least, I never explicitly set it to be, and we're not sending to the all hosts group). The wireless channel we're using is unused by other nearby access points. hostapd reports no abnormalities, and stopping it and starting it doesn't fix the problem. We have not seen this with regular UDP traffic being sent at the same rate.

Does anyone know off the bat why taking a wireless client out of range of the connected access point might cause the access point to "crash" if there's multicast data being sent over the network? Unfortunately, I don't have a lot of resources to pursue this issue significantly further, so I'm just asking to see if the issue sounds familiar to anyone, and if they were able to resolve it.

EDIT: I have just reproduced this on completely different hardware. A NETGEAR WNR2000 with the multicast packets coming from a Visual C++ application running on a WinCE device connected via ethernet (i.e., completely different than the setup used above). It seems to be rarer with this configuration, though, but I definitely made it happen.

  • Are you using a blocking sendto? If so, it shouldn't be surprising that it blocks. – David Schwartz Aug 5 '14 at 21:22
  • It's not surprising. It's just a symptom that occurs alongside the access point no longer being able to accept new wireless clients for awhile. – Raspberry Aug 6 '14 at 0:55
0

It could be that as the device reaches the edge of the range, the usb adapter starts requesting more power than the Pi can provide, and thus lead to instability. This would make sense as far as only affecting TCP traffic which requires a response, while the UDP traffic could never reach the target and simply be discarded, without causing any issues.

I am not understanding how you have "TCP multicast"

  • There's no such thing as TCP multicast. When I say "regular UDP traffic", I mean UDP datagrams addressed to a non-multicast address. Although, your idea about the power is interesting. However, I just reproduced the issue on different hardware (a NETGEAR router), i.e. I was able to put it into this hobbled state where new clients can't connect and it shows up with 1 bar of signal strength. In this case, the multicast packets were coming in over an ethernet port from a WinCE device, so that's completely different as well (however, it is harder to get it into this state with the NETGEAR router). – Raspberry Aug 6 '14 at 0:54
0

What would cause it to crash? A bug in the AP-mode support in the driver of your AP's Wi-Fi chipset. Well, the driver, or the chipset firmware, or potentially in the hardware of the chipset itself.

If you have access to the sources of said driver to try and debug it, I'd start by looking at how it handles multicast delivery when clients have invoked 802.11 power save mode.

If you just want to work around it, start by trying a high-quality brand-name USB Wi-Fi adapter, with a chipset from a top-tier vendor such as Broadcom or QCA (Qualcomm Atheros).

  • This happens on more than just the USB WiFi adapter. Per my edit above, I've reproduced this on an off-the-shelf NETGEAR router. My Android clients cannot connect to the AP when it's in this state, but strangely enough, iOS devices can (albeit with some difficulty). Could be a problem with Android, and the states the APs are being put into is considered normal behavior (or else two completely different wireless routers have the same bug). I will followup if I do any additional testing. – Raspberry Aug 6 '14 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.