Ugh. A somewhat dumb question is how would I disable bluetooth entirely on the rpi3?
I had done some initial tests on the rpi3 for the fq_codel on wifi work and gave up due to dismal results on the flent tests. I hadn't got around to writing them up here, http://blog.cerowrt.org/tags/wifi/ but perhaps disabling bluetooth would help. On Mon, May 9, 2016 at 9:59 AM, Barry Reinhold <barryreinh...@lnihealth.com> 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. > > 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? > > ________________________________________ > From: Arend Van Spriel <arend.vanspr...@broadcom.com> > Sent: Monday, May 9, 2016 8:23 > To: Barry Reinhold; linux-wireless@vger.kernel.org > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
