On 9-5-2016 18:59, Barry Reinhold wrote: > Arend (and Hante), > > I appreciate the feedback on the core problem - that brings the issue into a lot sharper focus. Based on your response I assume we should be able to see successful coexistence with Bluetooth and 802.11 STA mode, as well as STA and AP (with Bluetooth turned off). However, BT with AP mode should fail, and BT with AP and STA will fail. > > I will rerun some of our crude tests to see if I can corroborate your understanding by testing the different "should coexist" and "should not coexist" cases. > > You have a very interesting lead in statement in your response (bottom of message) but the sentence just ends with "because of...". Would you be willing to complete that thought, I would like to further understand the nature of the problem. These kind of references are why inline replies are preferrable. Anyway let me try and finish that sentence. An AP has to be able to sent a beacon on fixed times and subsequent traffic. As BT is master in most if not all bt-coex schemes that can easily screw up the beacon timing, which by the way is a reason for clients to disconnect. > Is there a known reason why the brcmfmac does not support the set_bitrate_mask() callback (such as the associated family of chips do not support rate limiting) or is this something that nobody has cared about to do date, ie, is it something that could be done if there was interest and resources? No specific reason. Regards, Arend > ________________________________________ > From: Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx> > Sent: Monday, May 9, 2016 8:23 > To: Barry Reinhold; linux-wireless@xxxxxxxxxxxxxxx > Cc: Tom Harada; brcm80211-dev-list > Subject: Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac > > On 7-5-2016 21:24, Barry Reinhold wrote: >> I have observed erratic behavior with http connectivity over the WiFi interface of the Raspberry PI 3. This appears to be consistent with issues that a number of other people have reported. I fear, but can not provide definitive evidence, that these failures could be an RF design/layout issue with the RP-3 itself. >> >> The purpose of this post is to see if this possible issue can be confirmed by others, and to seek a possible work around by re configuring the BCM43438 chip via the brcmfmac driver; or the other associated wifi modules. >> >> How the issue is being seen: >> >> Note: The testing I have done is limited and has the potential to be misleading, so any input on improving the test process would be appreciated. >> >> There are two metrics we are using to define/see failure: (1) Loss/delay in ICMP Echo requests/replys (pings), and (2) The output of messages in journalctl from the wpa_supplicant or hostapd (sudo journalctl -u wpa_supplicant -u hostapd -f) indicating a disconnect event with associated reason - typically 0 - (wlan0: CTRL-EVENT-DISCONNECTED bssid=60:02:92:cd:c9:30 reason=0). >> Ping times vary from 1 to several hundred ms, to outright loss. >> There are also failures to reassociate (wlan0: CTRL-EVENT-ASSOC-REJECT status_code=16). >> >> The test Environment is composed of: >> An official Raspberry PI-3 model B with an official Raspberry PI-3 power supply. >> Raspbian release: Jesse (March 18) >> Kernel 4.4.6 >> wpa_supplicant 2.3 >> brcmfmac 7.45.41.23 (as reported by ethool) >> BCM43438 firmware: 01-cc44eda9c >> BlueZ 5.23 >> >> We are running both wpa_supplicant and hostapd, (disabling hostapd does not impact the results of the tests). >> We have an application that is monitoring for BTLE/Bluetooth connections so it is scanning on a regular basis, as well as sending out Bluetooth INQUIRE messages. >> >> WiFi Access Points: >> 1. Cisco DPC3939B (supports n) >> 2. Cisco Linksys E1200 (supports n) >> 3. Netgear WNDR3400 (supports n) >> 4. Linksys WAP54G v3 (does not support n) >> >> >> >> Test Process >> >> >> While the application is running (thus generating Bluetooth activity) >> 1. Connect a PC to the RPi3's software access point and ping the RPi3 continuously. >> 2. Connect the RPi3 to an AP from the set above. >> 3. Let the system run for 10 minutes while counting wpa_supplicant disconnects and lost pings. >> >> Observations: >> In our testing we noticed that either we essentially got no errors, or we got 12+ errors. Some error rates high enough that we couldn't count them as they just scrolled off our screen. Hence we considered thing to work (less then 2 errors) or failed (greater than 10 errors). >> >> The results table for the different APs is as follows: >> DPC3939B - Failed >> E1200 - Failed >> WNDR3400 - Failed >> WAP54G - Passed >> >> Since only the WAP54G passed (no n support), we modified the data rate on the Netgear WND3400 and limited its data rate to 54 mbs, at this point the WNDR3400 passed. >> >> We then tried changing channels. this did not impact the metrics we were monitoring. >> >> Now being suspicious of RF issues on the board, we modified our application which performs the Bluetooth communications so that Bluetooth was disabled. This did not eliminate errors but dramatically reduced them. We then modified our application to generate a lot of Bluetooth inquiry messages and discovered that the generation and resulting response from INQUIRY messages correlated with journalctl disconnection messages. >> >> We repeated this on the AP WAP54G and the rate limited WNDR3400 and did not see problems. >> >> Our initial conjecture is that there is some coexistence/RF issue with the RPI-3 board when using Bluetooth and WiFi that is impacting when operating with a IEEE 802.11 N AP. >> >> Notes and steps taken: >> Background reading led us to try the following fixes that have worked for others: >> 1. Disable power management >> 2. Set the Country Code to US >> These fixes did not help. >> >> I have two questions: >> 1. Are there some obvious things I can do to identify/validate the initial conjecture as to the cause of the error? >> 2. Is there a way to force the RPI-3 when operating as a client of another AP to rate limit or function as a "G" device? If the RPI-3 or the BCM43438 do indeed have RF issues it would seem like some work around will be needed. I could not identify a way to limit the data rate in brcmfmac. > > Hi Barry, > > What you are trying to do is simply not possible. Indeed the RF is such > that Wifi and BT share the same antenna, which is the root-cause of the > problems you see. When the antenna is used by BT the Wifi is > unavailable. This is handled by bt-coex, but that is designed > specifically for station mode. This is simply not possible when the Wifi > is operating in AP mode, because of > > The reason why things get better/working when using g-rates is probably > because INQUIRE scan takes 14 x 1.25ms = 17.5 ms (thanks for the > calculation, Hante) and wifi frame retries at g-rate get past that. > cfg80211_ops have .set_bitrate_mask() callback, but brcmfmac does not > implement that. > > Regards, > Arend > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
