4

I'm using a Raspberry Pi 3 as the platform for a project whose requirements include acting as a WiFi access point as well as connecting to a wide variety of WiFi routers. Unfortunately, the WiFi connectivity is very unstable. The most prominent symptom is frequent disassociations from the router, often accompanied by a failure to reassociate. In the worst case, the RPi3 disconnects more than once per minute. Pinging the RPi3 from a machine connected to its software access point results in wildly varying ping times in addition to significant packet loss.

Some example output from wpa_supplicant:

wlan0: CTRL-EVENT-DISCONNECTED bssid=60:02:92:cd:d9:30 reason=0 
locally_generated=1
wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US
wlan0: Trying to associate with SSID 'MySSID'
wlan0: CTRL-EVENT-ASSOC-REJECT status_code=16
wlan0: Trying to associate with SSID 'MySSID'
wlan0: Associated with 60:02:92:cd:d9:30
wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
wlan0: WPA: Key negotiation completed with 60:02:92:cd:d9:30 [PTK=CCMP 
GTK=TKIP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 60:02:92:cd:d9:30 completed 
[id=0 id_str=]

I've tried several fixes that worked for other people, including updating the kernel, disabling power management, setting the regulatory domain, and switching the channel of the router, without any success. Disabling the software AP doesn't help either. However, I've made a couple of interesting discoveries.

Firstly, the instability seems to be affected by use of the built-in Bluetooth, which our project also requires. Running a repeated Bluetooth inquiry greatly increases the rate of disconnects reported by the RPi's wpa_supplicant, and also seems to make it less likely that the reassociation will succeed.

Secondly, the instability only seems to occur on WiFi routers supporting 802.11n. This is based on the following sample, which admittedly isn't very large:

  1. Cisco DPC3939B (n) - unstable
  2. Cisco Linksys E1200 (n) - unstable
  3. Netgear WNDR3400 (n) - unstable in n mode, but stable when limited to 54 Mbit/s.
  4. Linksys WAP54G v3 (g) - stable

Based on these observations, I'd like to try limiting the BCM43438 chip's data rate and forcing it to connect as an 802.11g device, but it's not clear whether this is possible using the existing drivers.

Details of my installation:

  • Raspberry Pi 3 Model B with official power supply
  • Raspbian Jessie from March 2016
  • Kernel 4.4.6
  • wpa_supplicant 2.3
  • brcmfmac 7.45.41.23 (as reported by ethool)
  • BCM43438 firmware 01-cc44eda9c
  • BlueZ 5.23

Any recommendations would be much appreciated.

Jacobm001
  • 11,898
  • 7
  • 46
  • 56
Barry
  • 51
  • 5

6 Answers6

1

Barry.

If I understand your plan, you are using a software access point, like hostapd, right? I think the configuration of this software allows you to specify a wireless mode, such as 802.11b, g, or n (or some combination.)

(I'm basing my understanding on this and other google hits.) http://lists.shmoo.com/pipermail/hostap/2012-March/025542.html

And you may want to also check:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=134588

In the simplest case, you want to edit /etc/hostapd/hostapd.conf to include lines that say: 

hw_mode=g
ieee80211n=0

Of course your case may not be simple. It does seem a little unlikely that my rusty networking kung fu could simply step in and make this right. But let us know how it goes.

PS: Please also let the Raspberry Pi Foundation know about this bug you have apparently discovered in how the machine's built-in networking functions in a widely-used mode. Just locking it into G doesn't fix the bug. :) https://www.raspberrypi.org/forums/

Tai Viinikka
  • 1,549
  • 1
  • 10
  • 8
  • Hi Tai, I appreciate your taking the time to think through this. Our core issue isn't with hostapd, although we need to use it. Our core issue is with wpa_supplicant -- and trying to limit its bit rate. That said, in reviewing the references you provided it gave me some hope that there might be a way to do this on the wpa_supplicant (client) side of things. Can one make the leap that if you can rate limit on the AP there will be a way to rate limit on the client side? – Barry May 03 '16 at 19:02
  • Barry, do you also control the access point that you will be connecting to as a client? I don't see a way to ask wpa_supplicant to enforce this. If you can, step upstream and only offer the client G-mode. – Tai Viinikka May 04 '16 at 02:56
  • No, the AP that we will connect to is not under our control. We can control it in our test environment but not in general. – Barry May 04 '16 at 12:43
1

If you are only interested in limiting the data rate for the purpose of reducing network utilization (as opposed, for example, for needing to force g mode rather than n mode because of radio spectrum considerations), the proper way to do it is is at the network layer. The term you are looking for is "traffic shaping", and a quick search revealed this as a reasonably easy-to-follow example.

https://www.iplocation.net/traffic-control

Doing traffic-shaping this way allows you much finer control than the selection of the various WiFi modes provides.

JayEye
  • 1,898
  • 11
  • 18
  • 1
    Hi JayEye, Thanks for the input. The reason we are trying to rate limit the BCM43438 is not for traffic shaping purposes but to avoid RF interference on the RPI-3 board with Bluetooth. Traffic shaping will be at a higher level, and though it may limit the throughput of things at the IP level, the individual 802.11 messages would still go out at higher bit rates associated with IEEE 802.11 "N" networks causing the problem to be manifested. I think I need to slow the IEEE 802.11 exchange. – Barry May 04 '16 at 21:56
  • If interference with BT is the problem (I haven't observed it, but I assume you have and that you know what you are doing :) ), have you tried running the wifi in the 5GHz band only? Or is your campus not supporting 5GHz?

    Of course, that will have range problems, and/or the devices that are connecting to you may not have 5GHz. Also, I don't know if the radio can do 2.4 and 5GHz at the same time, so you might have intermittent BT connectivity if you use the 5GHz band. Wireless is hard (still easier than shopping, though :) )

     – JayEye May 05 '16 at 15:31
  • I believe that the RP-3 doesn't support 5 GHZ operation (BCM43438). – Barry May 07 '16 at 16:17
  • As a follow up on your not seeing Bluetooth/WIfi issues, can you describe what you are doing and how you are monitoring Bluetooth/Wifi behavior? – Barry May 07 '16 at 16:22
1

It is not currently possible to limit the data rate on the BCM43438 through the brcmfmac.

However, the core issue we are observing is due to a limitation in the BCM43438. It uses one antenna for both Bluetooth and Wifi, due to this configuration it is not possible to operate the wifi in AP mode as the antenna cannot be shared in a way that meets the time constraints of both Bluetooth and the Wifi beaconing process associated with AP mode.

A more technical discussing can be found on the linux wireless email archive: http://blog.gmane.org/gmane.linux.kernel.wireless.general/day=20160509

Barry
  • 51
  • 5
  • Please accept your own answer with a click on the tick on its left side. Only this will finish the question and it will not pop up again year for year. – Ingo Apr 07 '20 at 09:35
1

Barry,

The problem you are having may also be related to : https://github.com/raspberrypi/linux/issues/1444

I have been battling similar problems with the RPi3. I have found even with low data rates I still have the problems. It looks to me like the Rpi3 has a problem with power management frames. I have been looking at the traffic with wireshark and it looks like even when power management is disabled, it is still used for flow control when bluetooth is enabled. To compound things it looks like the RPi3 has a glitch where it messes up the state of the power setting frames. This causes long lags on wifi.

mw.
  • 111
  • 3
0

Last weeks (2016-05-10) raspbian release seems to have improved some of the wifi issues, but has degraded the bluetooth performance. You may want to try the this to see if it improves things with your application. Hopefully you won't need to limit the bit anymore rate when you do this.

mw.
  • 111
  • 3
0

If you are experiencing problems due to conflicts between Bluetooth and using the wireless network in AP mode, one easy workaround (though with a small added cost) would be to use a USB dongle for either WiFi or Bluetooth.

That would eliminate the need for both communication protocols to share the same antenna.

Erik HB
  • 1
  • 1