Re: 4311 v2 Bail - 2.6.26-rc2

Re: 4311 v2 Bail - 2.6.26-rc2

[Michael Buesch]

On Tuesday 13 May 2008 23:31:17 Daniel wrote:
> Hello,
> 
> Michael Buesch wrote:
> > Could you _please_ be so kind an explain your actual problem??
> > My magic crystalball is broken today.
> 
> Sorry, it's the problem where after X minutes the device seems to loose 
> the ability to communicate. It seems to be on a high number of 
> connections/sec scenario.
> 
> It seems to occur at the 2nd or 3rd issue of the "wrong buffer size" 
> message.

Where does this "wrong buffer size" message come from, and what does it mean?

> b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac: 
> ff:ff:ff:ff:ff:ff
> wlan0: wrong buffer size<7>wlan0: wrong buffer size<7>wlan0: wrong 
> buffer size<7>wlan0: wrong buffer size
> b43-phy1 debug: Disabling hardware based encryption for keyidx: 1, mac: 
> ff:ff:ff:ff:ff:ff

-- 
Greetings Michael.

Re: 4311 v2 Bail - 2.6.26-rc2

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]


> Where does this "wrong buffer size" message come from, and what does it mean?
> 
> > b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac: 
> > ff:ff:ff:ff:ff:ff
> > wlan0: wrong buffer size<7>wlan0: wrong buffer size<7>wlan0: wrong 
> > buffer size<7>wlan0: wrong buffer size

It comes from mac80211 when the AP is sending invalid A-MSDU frames.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: 4311 v2 Bail - 2.6.26-rc2

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Wed, 2008-05-14 at 01:33 +0200, Johannes Berg wrote:
> > Where does this "wrong buffer size" message come from, and what does it mean?
> > 
> > > b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac: 
> > > ff:ff:ff:ff:ff:ff
> > > wlan0: wrong buffer size<7>wlan0: wrong buffer size<7>wlan0: wrong 
> > > buffer size<7>wlan0: wrong buffer size
> 
> It comes from mac80211 when the AP is sending invalid A-MSDU frames.

Wait. If this is with b43, why the hell is it sending A-MSDU frames in
the first place? Or maybe it's receiving totally corrupt data. A monitor
mode trace would help.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: 4311 v2 Bail - 2.6.26-rc2

[Michael Buesch]

On Wednesday 14 May 2008 01:36:04 Johannes Berg wrote:
> On Wed, 2008-05-14 at 01:33 +0200, Johannes Berg wrote:
> > > Where does this "wrong buffer size" message come from, and what does it mean?
> > > 
> > > > b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac: 
> > > > ff:ff:ff:ff:ff:ff
> > > > wlan0: wrong buffer size<7>wlan0: wrong buffer size<7>wlan0: wrong 
> > > > buffer size<7>wlan0: wrong buffer size
> > 
> > It comes from mac80211 when the AP is sending invalid A-MSDU frames.
> 
> Wait. If this is with b43, why the hell is it sending A-MSDU frames in
> the first place? Or maybe it's receiving totally corrupt data. A monitor
> mode trace would help.


Here's the full dmesg.
Also notice "tx_ring_AC_VO: Used slots 128/128" after about 17000 successfull
frames. Weird.

> b43-phy1: Broadcom 4311 WLAN found
> b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 9
> b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
> b43-phy1 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config
> phy1: Selected rate control algorithm 'pid'
> Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ]
> firmware: requesting b43/ucode13.fw
> firmware: requesting b43/lp0initvals13.fw
> b43-phy1: Loading firmware version 410.2160 (2007-05-26 15:32:10)
> b43-phy1 debug: Chip initialized
> b43-phy1 debug: 64-bit DMA initialized
> b43-phy1 ERROR: PHY transmission error
> b43-phy1 debug: Wireless interface started
> b43-phy1 debug: Adding Interface type 2
> wlan0: Initial auth_alg=0
> wlan0: authenticate with AP 00:90:d0:f4:18:d4
> wlan0: RX authentication from 00:90:d0:f4:18:d4 (alg=0 transaction=2
> status=0)
> wlan0: authenticated
> wlan0: associate with AP 00:90:d0:f4:18:d4
> wlan0: RX AssocResp from 00:90:d0:f4:18:d4 (capab=0x411 status=0 aid=1)
> wlan0: associated
> wlan0: switched to short barker preamble (BSSID=00:90:d0:f4:18:d4)
> b43-phy1 debug: Using hardware based encryption for keyidx: 0, mac:
> 00:90:d0:f4:18:d4
> b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac:
> ff:ff:ff:ff:ff:ff
> wlan0: wrong buffer size<7>wlan0: wrong buffer size<7>wlan0: wrong
> buffer size<7>wlan0: wrong buffer size
> b43-phy1 debug: Disabling hardware based encryption for keyidx: 1, mac:
> ff:ff:ff:ff:ff:ff
> b43-phy1 debug: Removing Interface type 2
> b43-phy1 debug: Wireless interface stopped
> b43-phy1 debug: DMA-64 rx_ring: Used slots 3/64, Failed frames 0/0 =
> 0.0%, Average tries 0.00
> b43-phy1 debug: DMA-64 tx_ring_AC_BK: Used slots 0/128, Failed frames
> 0/0 = 0.0%, Average tries 0.00
> b43-phy1 debug: DMA-64 tx_ring_AC_BE: Used slots 0/128, Failed frames
> 0/0 = 0.0%, Average tries 0.00
> b43-phy1 debug: DMA-64 tx_ring_AC_VI: Used slots 0/128, Failed frames
> 0/0 = 0.0%, Average tries 0.00
> b43-phy1 debug: DMA-64 tx_ring_AC_VO: Used slots 128/128, Failed frames
> 106/17766 = 0.5%, Average tries 1
> b43-phy1 debug: DMA-64 tx_ring_mcast: Used slots 0/128, Failed frames
> 0/0 = 0.0%, Average tries 0.00
> wlan0: deauthenticate(reason=3)


-- 
Greetings Michael.

Re: 4311 v2 Bail - 2.6.26-rc2

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]


> > b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 9
> > b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
> > b43-phy1 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config
> > phy1: Selected rate control algorithm 'pid'
> > Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ]
> > firmware: requesting b43/ucode13.fw
> > firmware: requesting b43/lp0initvals13.fw

Huh? lp0initvals?!

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: 4311 v2 Bail - 2.6.26-rc2

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Wed, 2008-05-14 at 01:48 +0200, Johannes Berg wrote:
> > > b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 9
> > > b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
> > > b43-phy1 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config
> > > phy1: Selected rate control algorithm 'pid'
> > > Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ]
> > > firmware: requesting b43/ucode13.fw
> > > firmware: requesting b43/lp0initvals13.fw
> 
> Huh? lp0initvals?!

Hmm. specs bug? But probably unrelated anyway since, well, it works for
other people.

We really need a raw monitor frame capture.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: 4311 v2 Bail - 2.6.26-rc2

[Daniel]

Hello,

Johannes Berg wrote:
> We really need a raw monitor frame capture.

Not sure how I go about that one?

I have an external RTL8187 device I can stick into monitor mode? But 
then it wouldn't be associated/encryption keys...

Tips anyone?



Cheers,

Dan.

Re: 4311 v2 Bail - 2.6.26-rc2

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]


> > We really need a raw monitor frame capture.
> 
> Not sure how I go about that one?
> 
> I have an external RTL8187 device I can stick into monitor mode? But 
> then it wouldn't be associated/encryption keys...
> 
> Tips anyone?

In this case, adding a monitor interface to your local b43 machine (with
iw: http://wireless.kernel.org/en/users/Documentation/iw) might be
preferable.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: 4311 v2 Bail - 2.6.26-rc2

[Pavel Roskin]

On Wed, 2008-05-14 at 01:27 +0200, Michael Buesch wrote:

> Where does this "wrong buffer size" message come from, and what does it mean?

net/mac80211/rx.c

There are two instances of that message, both in ieee80211_rx_h_amsdu(),
and both in the code path that returns RX_DROP_UNUSABLE.

I guess the code complains about some invalid frames and drops them.
Somebody with a better knowledge of the code should write better
descriptions and make the messages different.

-- 
Regards,
Pavel Roskin