Re: Deauthentications with p54usb

Re: Deauthentications with p54usb

[Chunkeey]

"Larry Finger" <Larry.Finger@lwfinger.net> wrote:
> 
> I'll try to collect a dump.
> 
Any news regarding that dump?
Or are you too busy reviewing b43's LP code? :)

It looks like more drivers are affected. 
 - Luis reported some deauth (reasons=7) for ath9k with a cisco ap.
 - Kalle has the same issues with wl1271 with a ?Zyxel? AP.

Regards,
 Chr
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/

Re: Deauthentications with p54usb

[Larry Finger]

Chunkeey@web.de wrote:
> "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>> I'll try to collect a dump.
>>
> Any news regarding that dump?
> Or are you too busy reviewing b43's LP code? :)
> 
> It looks like more drivers are affected. 
>  - Luis reported some deauth (reasons=7) for ath9k with a cisco ap.
>  - Kalle has the same issues with wl1271 with a ?Zyxel? AP.

Not only reviewing the code, but updating the specs and doing the RE
work. No, I have no further info. Mine have been on a Linksys AP.

Larry

Re: Deauthentications with p54usb

[Christian Lamparter]

On Friday 14 August 2009 00:53:16 Larry Finger wrote:
> Chunkeey@web.de wrote:
> > "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
> >> I'll try to collect a dump.
> >>
> > Any news regarding that dump?
> > Or are you too busy reviewing b43's LP code? :)
> > 
> > It looks like more drivers are affected. 
> >  - Luis reported some deauth (reasons=7) for ath9k with a cisco ap.
> >  - Kalle has the same issues with wl1271 with a ?Zyxel? AP.
> 
> Not only reviewing the code, but updating the specs and doing the RE
> work. No, I have no further info. Mine have been on a Linksys AP.
yeah, b43 definitely needs the attention.

The powersave default mode should be back to "off" for p54, due to:
"[PATCH] cfg80211: allow driver to override PS default".
so, no need to revert the psm patch again.

Regards,
	Chr

Re: Deauthentications with p54usb

[Kalle Valo]

Chunkeey@web.de writes:

> "Larry Finger" <Larry.Finger@lwfinger.net> wrote:
>> 
>> I'll try to collect a dump.
>> 
> Any news regarding that dump?
> Or are you too busy reviewing b43's LP code? :)
>
> It looks like more drivers are affected. 
>  - Luis reported some deauth (reasons=7) for ath9k with a cisco ap.
>  - Kalle has the same issues with wl1271 with a ?Zyxel? AP.

Actually that was with wl1251. It was a bug in the driver, I'll send a
patch within few days.

-- 
Kalle Valo

Re: Deauthentications with p54usb

[Larry Finger]

On 03/08/2010 05:38 PM, Christian Lamparter wrote:
> Hello Larry,
> 
> Remember?

I had forgotten. Using the 'iwconfig wlanX power on' results in lots of
deauthentications:

The output of 'dmesg | grep deauthen' results in

[19826.645917] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20006.645407] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20126.663059] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20301.031865] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20366.659815] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20501.417748] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20606.644271] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20846.658392] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[20966.653835] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[21095.942856] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[21332.790772] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[21446.649393] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[21570.643913] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[21686.652360] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[21946.714794] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[22078.162861] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[22166.651450] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[22406.651968] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[22526.667053] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[22646.651483] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23054.133847] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23139.129081] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23249.743447] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23377.759110] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23487.119197] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23622.154154] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23846.651794] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[23966.649980] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[24206.644314] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[24446.650418] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[24576.569191] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[24686.645975] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)
[24806.650948] wlan6: deauthenticated from 00:14:bf:85:49:fa (Reason: 7)

As soon as I used 'iwconfig wlanX power off', the deauthentications stopped.

Larry

Re: Deauthentications with p54usb

[Christian Lamparter]

Hello Larry,

Remember?

On Sunday 09 August 2009 22:27:58 Larry Finger wrote:
> Chunkeey@web.de wrote:
> > Ahh, wait... screw up: I failed to explain the difference between:
> > 
> > - powersave (=> responsible for your connection problems)
> >    In this mode: the device goes into a lower power state,
> >    but continues to listen for dtim beacons and multicast frames,
> >    from the AP.
> > 
> >    mac80211 does not have printks for these ps events,
> >    since the device power state may chance every second.
> > 
> >    howeve, it's possible to trace them through the generic _trace_
> >    framework with MAC80211_DRIVER_API_TRACER Kconfig
> >    option enabled.
> >    
> > vs. 
> > 
> >  - hibernation (soft rfkill that went in with "[PATCH] p54: implement rfkill")
> >    In this mode: the device's radio is completely shutdown... so
> >    it only makes sense to enter this mode when there's really nothing
> >    to do (=> the device is not scanning or associating/associated)
> >    
> >    mac80211 will printk (with CONFIG_MAC80211_VERBOSE_DEBUG set)
> >    whenever the IEEE80211_CONF_IDLE changes. e.g: 
> >        phy0: device no longer idle - REASON
> >     or:
> >        phy0: device now idle
> >     in the kernel logs.
> > 
> >> Turning off CONFIG_CFG80211_DEFAULT_PS stopped the messages,
> >> thus it certainly looks like a power saving event.
> > so hibernation (rfkill) is fine, just powersave is playing tricks...
> > weirdly, intel disabled ps in their driver _again_ not too long ago,
> > maybe a coincident, maybe not... do you think you can send me
> > a kismet/wireshark/airodump dump whenever the AP kicks the device?
> 
> We don't know that hibernation is OK. I just never make my machine
> hibernate (suspend to disk) or sleep (suspend to RAM). The last time I
> tried it had one or more drivers that would not cooperate, and I have
> not tried recently.
> 
> I'll try to collect a dump.
> 
> > BTW: you can set different PS modes with the old iwconfig utility:
> > iwconfig wlanX power off <-- disables PS
> > (just like turning off the CONFIG_CFG80211_DEFAULT_PS option)
> > 
> > iwconfig wlanX power timeout 0 <--- most aggressive PS setting,
> > (only uses PS-POLL to retrieve data).
> > 
> > AFAIK the current default is just "1", maybe your link would be
> > totally reliable with a more  _relaxed_ 200, 500 setting...
> 
> I'll re-enable CONFIG_CFG80211_DEFAULT_PS and try a more relaxed value
> for the power timeout. In any case, with it disabled, there have been
> no deauthentications nor disassociations. The link is rock solid.

Obviously, there has been a lot of progress on power saving.
Can you please retest if p54(usb) link is still dying when
PSM is enabled?

(NB: the easiest way to enable/disable PSM: iwconfig wlanX power on/off,
 no need to recompile/rebuild the module)

Regards,
	Chr

Re: Deauthentications with p54usb

[Chunkeey]

"Larry Finger" <Larry.Finger@lwfinger.net> wrote:
> Chunkeey@web.de wrote:
> > Ahh, wait... screw up: I failed to explain the difference between:
> > vs.  
> >  - hibernation (soft rfkill that went in with "[PATCH] p54: implement rfkill")
> >    In this mode: the device's radio is completely shutdown... so
> >    it only makes sense to enter this mode when there's really nothing
> >    to do (=> the device is not scanning or associating/associated)
> >    
> >    mac80211 will printk (with CONFIG_MAC80211_VERBOSE_DEBUG set)
> >    whenever the IEEE80211_CONF_IDLE changes. e.g: 
> >        phy0: device no longer idle - REASON
> >     or:
> >        phy0: device now idle
> >     in the kernel logs.
> > 
> >> Turning off CONFIG_CFG80211_DEFAULT_PS stopped the messages,
> >> thus it certainly looks like a power saving event.
> > so hibernation (rfkill) is fine, just powersave is playing tricks...
> > weirdly, intel disabled ps in their driver _again_ not too long ago,
> > maybe a coincident, maybe not... do you think you can send me
> > a kismet/wireshark/airodump dump whenever the AP kicks the device?
> 
> We don't know that hibernation is OK. I just never make my machine
> hibernate (suspend to disk) or sleep (suspend to RAM).
> The last time I tried it had one or more drivers that would not cooperate,
> and I have not tried recently.

meh, overloaded words ;-)

that hibernation paragraph is about the hibernation _filter_ state:
#define P54_FILTER_TYPE_HIBERNATE       BIT(5) <-- lmac.h

this operation mode silence the device (no frames will be send, or received),
which makes it ideal for soft - rfkill.

but yeah, that name is definitely misleading. We don't want to
hibernate/(suspend) the whole machine... just the p54 device,
when it's not connected. 

> > BTW: you can set different PS modes with the old iwconfig utility:
> > iwconfig wlanX power off <-- disables PS
> > (just like turning off the CONFIG_CFG80211_DEFAULT_PS option)
> > 
> > iwconfig wlanX power timeout 0 <--- most aggressive PS setting,
> > (only uses PS-POLL to retrieve data).
> > 
> > AFAIK the current default is just "1", maybe your link would be
> > totally reliable with a more  _relaxed_ 200, 500 setting...
> 
> I'll re-enable CONFIG_CFG80211_DEFAULT_PS and try a more relaxed value
> for the power timeout. In any case, with it disabled, there have been
> no deauthentications nor disassociations. The link is rock solid.

Thanks for confirming my thoughts!

So, the rfkill changes are not to blame for this problem and we can
take them out of the equation.

The weird thing is that the driver's PS code (relevant to STA mode)
has not changed since you did the exhaustive tests last month.

Regards,
    Chr
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/

Re: Deauthentications with p54usb

[Larry Finger]

Chunkeey@web.de wrote:
> Ahh, wait... screw up: I failed to explain the difference between:
> 
> - powersave (=> responsible for your connection problems)
>    In this mode: the device goes into a lower power state,
>    but continues to listen for dtim beacons and multicast frames,
>    from the AP.
> 
>    mac80211 does not have printks for these ps events,
>    since the device power state may chance every second.
> 
>    howeve, it's possible to trace them through the generic _trace_
>    framework with MAC80211_DRIVER_API_TRACER Kconfig
>    option enabled.
>    
> vs. 
> 
>  - hibernation (soft rfkill that went in with "[PATCH] p54: implement rfkill")
>    In this mode: the device's radio is completely shutdown... so
>    it only makes sense to enter this mode when there's really nothing
>    to do (=> the device is not scanning or associating/associated)
>    
>    mac80211 will printk (with CONFIG_MAC80211_VERBOSE_DEBUG set)
>    whenever the IEEE80211_CONF_IDLE changes. e.g: 
>        phy0: device no longer idle - REASON
>     or:
>        phy0: device now idle
>     in the kernel logs.
> 
>> Turning off CONFIG_CFG80211_DEFAULT_PS stopped the messages,
>> thus it certainly looks like a power saving event.
> so hibernation (rfkill) is fine, just powersave is playing tricks...
> weirdly, intel disabled ps in their driver _again_ not too long ago,
> maybe a coincident, maybe not... do you think you can send me
> a kismet/wireshark/airodump dump whenever the AP kicks the device?

We don't know that hibernation is OK. I just never make my machine
hibernate (suspend to disk) or sleep (suspend to RAM). The last time I
tried it had one or more drivers that would not cooperate, and I have
not tried recently.

I'll try to collect a dump.

> BTW: you can set different PS modes with the old iwconfig utility:
> iwconfig wlanX power off <-- disables PS
> (just like turning off the CONFIG_CFG80211_DEFAULT_PS option)
> 
> iwconfig wlanX power timeout 0 <--- most aggressive PS setting,
> (only uses PS-POLL to retrieve data).
> 
> AFAIK the current default is just "1", maybe your link would be
> totally reliable with a more  _relaxed_ 200, 500 setting...

I'll re-enable CONFIG_CFG80211_DEFAULT_PS and try a more relaxed value
for the power timeout. In any case, with it disabled, there have been
no deauthentications nor disassociations. The link is rock solid.

Larry

Re: Deauthentications with p54usb

[Chunkeey]

"Larry Finger" <Larry.Finger@lwfinger.net> wrote
> Christian Lamparter wrote:
> > 
> > reason 7 must be:
> > WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA
> > 
> > and class 3 frames are (according to 802.11-2007 11.3.c)
> > 	- "normal" data frames
> > 	(- some MLMEs - probably not relevant )
> > 	- control frame:
> > 		=> especially: Power Save Poll.
> > 
> > your log doesn't hold any records about a disassoc event from the AP.
> > so, my first guess would be that you're hitting yet another
> > power saving related issue.  And as far as I know b43 does not do that yet.
> > So, can you please give the device another go without ps?
> > 
> > (BTW: mac80211 prints a debug text (if enabled in kconfig),
> >  whenever the device goes or leaves the hibernation mode...
> >  do you see any of those too?) 
> 
> Once I got that debug mode set with PS enabled, I still got the deauth
> events, but no messages from mac80211. I may not have had the debug
> value set correctly.
Ahh, wait... screw up: I failed to explain the difference between:

- powersave (=> responsible for your connection problems)
   In this mode: the device goes into a lower power state,
   but continues to listen for dtim beacons and multicast frames,
   from the AP.

   mac80211 does not have printks for these ps events,
   since the device power state may chance every second.

   howeve, it's possible to trace them through the generic _trace_
   framework with MAC80211_DRIVER_API_TRACER Kconfig
   option enabled.
   
vs. 

 - hibernation (soft rfkill that went in with "[PATCH] p54: implement rfkill")
   In this mode: the device's radio is completely shutdown... so
   it only makes sense to enter this mode when there's really nothing
   to do (=> the device is not scanning or associating/associated)
   
   mac80211 will printk (with CONFIG_MAC80211_VERBOSE_DEBUG set)
   whenever the IEEE80211_CONF_IDLE changes. e.g: 
       phy0: device no longer idle - REASON
    or:
       phy0: device now idle
    in the kernel logs.

> Turning off CONFIG_CFG80211_DEFAULT_PS stopped the messages,
> thus it certainly looks like a power saving event.
so hibernation (rfkill) is fine, just powersave is playing tricks...
weirdly, intel disabled ps in their driver _again_ not too long ago,
maybe a coincident, maybe not... do you think you can send me
a kismet/wireshark/airodump dump whenever the AP kicks the device?

BTW: you can set different PS modes with the old iwconfig utility:
iwconfig wlanX power off <-- disables PS
(just like turning off the CONFIG_CFG80211_DEFAULT_PS option)

iwconfig wlanX power timeout 0 <--- most aggressive PS setting,
(only uses PS-POLL to retrieve data).

AFAIK the current default is just "1", maybe your link would be
totally reliable with a more  _relaxed_ 200, 500 setting...

Regards,
    Chr
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/

Re: Deauthentications with p54usb

[Larry Finger]

Christian Lamparter wrote:
> 
> reason 7 must be:
> WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA
> 
> and class 3 frames are (according to 802.11-2007 11.3.c)
> 	- "normal" data frames
> 	(- some MLMEs - probably not relevant )
> 	- control frame:
> 		=> especially: Power Save Poll.
> 
> your log doesn't hold any records about a disassoc event from the AP.
> so, my first guess would be that you're hitting yet another
> power saving related issue.  And as far as I know b43 does not do that yet.
> So, can you please give the device another go without ps?
> 
> (BTW: mac80211 prints a debug text (if enabled in kconfig),
>  whenever the device goes or leaves the hibernation mode...
>  do you see any of those too?) 

Once I got that debug mode set with PS enabled, I still got the deauth
events, but no messages from mac80211. I may not have had the debug
value set correctly. Turning off CONFIG_CFG80211_DEFAULT_PS stopped
the messages, thus it certainly looks like a power saving event.

Larry

Re: Deauthentications with p54usb

[Christian Lamparter]

Hello,

On Friday 07 August 2009 22:50:11 Larry Finger wrote:

> I've been working with b43 of late and had not run p54usb until I
> tested the rfkill code earlier today. Now I'm getting
> deauthentications with reason=7 that I did not get with b43 using the
> same AP in roughly the same geometric relationship.

hmm, so the SNR of b43 and p54 are comparable?

good...

reason 7 must be:
WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA

and class 3 frames are (according to 802.11-2007 11.3.c)
	- "normal" data frames
	(- some MLMEs - probably not relevant )
	- control frame:
		=> especially: Power Save Poll.

your log doesn't hold any records about a disassoc event from the AP.
so, my first guess would be that you're hitting yet another
power saving related issue.  And as far as I know b43 does not do that yet.
So, can you please give the device another go without ps?

(BTW: mac80211 prints a debug text (if enabled in kconfig),
 whenever the device goes or leaves the hibernation mode...
 do you see any of those too?) 
> I don't know if this is a regression, or not. The current kernel is
> 2.6.31-rc5-wl. I'll boot 2.6.30-wl to test if the older one is OK.
> 
> The logged data below shows nothing but the timing of the disconnects.

does the time between reassoc & _deauth_ vary, or is it always ~24 secs?)
do you experience this behavior on an idle or loaded link?
  
Regards,
	Chr

Deauthentications with p54usb

[Larry Finger]

Christian,

I've been working with b43 of late and had not run p54usb until I
tested the rfkill code earlier today. Now I'm getting
deauthentications with reason=7 that I did not get with b43 using the
same AP in roughly the same geometric relationship.

I don't know if this is a regression, or not. The current kernel is
2.6.31-rc5-wl. I'll boot 2.6.30-wl to test if the older one is OK.

The logged data below shows nothing but the timing of the disconnects.

Larry

============

Aug  7 15:28:33 larrylap kernel: wlan0: deauthenticated from
00:1a:70:46:ba:b1 (Reason: 7)
Aug  7 15:28:35 larrylap kernel: wlan0: direct probe to AP
00:1a:70:46:ba:b1 (try 1)
Aug  7 15:28:35 larrylap kernel: wlan0 direct probe responded
Aug  7 15:28:35 larrylap kernel: wlan0: authenticate with AP
00:1a:70:46:ba:b1 (try 1)
Aug  7 15:28:35 larrylap kernel: wlan0: authenticated
Aug  7 15:28:35 larrylap kernel: wlan0: associate with AP
00:1a:70:46:ba:b1 (try 1)
Aug  7 15:28:35 larrylap kernel: wlan0: RX AssocResp from
00:1a:70:46:ba:b1 (capab=0x431 status=0 aid=1)
Aug  7 15:28:35 larrylap kernel: wlan0: associated
Aug  7 15:29:59 larrylap kernel: wlan0: deauthenticated from
00:1a:70:46:ba:b1 (Reason: 7)
Aug  7 15:30:01 larrylap kernel: wlan0: direct probe to AP
00:1a:70:46:ba:b1 (try 1)
Aug  7 15:30:01 larrylap kernel: wlan0 direct probe responded
Aug  7 15:30:01 larrylap kernel: wlan0: authenticate with AP
00:1a:70:46:ba:b1 (try 1)
Aug  7 15:30:01 larrylap kernel: wlan0: authenticated
Aug  7 15:30:01 larrylap kernel: wlan0: associate with AP
00:1a:70:46:ba:b1 (try 1)
Aug  7 15:30:01 larrylap kernel: wlan0: RX AssocResp from
00:1a:70:46:ba:b1 (capab=0x431 status=0 aid=1)
Aug  7 15:30:01 larrylap kernel: wlan0: associated