Re: pull request: iwlwifi 2016-05-04

[Coelho, Luciano]

On Fri, 2016-05-06 at 14:34 +0300, Kalle Valo wrote:
> "Grumbach, Emmanuel"  writes:
> 
> > 
> > I know it is extremely late in the cycle, but this patch is
> > intended
> > for 4.6... It fixes a regression I introduced: a P2P specification
> > violation as mentioned in the commit message.
> > The patch is rather big in terms of number of lines changed, but
> > the
> > semantics is very simple. I have to copy the control block of the
> > skb
> > to the stack whereas we accessed we used to access it directly
> > through
> > a pointer.
> > This obviously introduces a lot of line changes, but don't really
> > change the behavior of the code (since most of the accesses are
> > read
> > only).
> > 
> > Let me know how it goes.
> [...]
> 
> > 
> > The following changes since commit
> > f742aaf36edf0390c54d0614bc4d20fd4cd3762a:
> > 
> >   iwlwifi: mvm: fix accessing Null pointer during fw dump
> > collection (2016-04-12 11:52:39 +0300)
> > 
> > are available in the git repository at:
> > 
> >   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-f
> > ixes.git tags/iwlwifi-for-kalle-2016-05-04
> Pulled, thanks. Let's see if this makes it to 4.6.
> 
> > 
> > I take this opportunity to inform you that I will be replaced by
> > Luca
> > for a few months at least. I will be working full steam on a side
> > project that will not allow me to do the maintainer job in
> > parallel.
> Ok, have fun in your new project.
> 
> Luca, as we _finally_ got sun here in Finland we have to have a "kick
> off meeting about the new organisation structure" by your grill ;)

Sounds good! When are you going to be coming to "The South"? :)

--
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac

[Barry Reinhold]

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.

 

Barry Reinhold
--
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