2009-08-09 20:02:18

by Christian Lamparter

[permalink] [raw]
Subject: Re: Deauthentications with p54usb

"Larry Finger" <[email protected]> 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/



2009-08-09 20:28:01

by Larry Finger

[permalink] [raw]
Subject: Re: Deauthentications with p54usb

[email protected] 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

2010-03-08 23:38:40

by Christian Lamparter

[permalink] [raw]
Subject: Re: Deauthentications with p54usb

Hello Larry,

Remember?

On Sunday 09 August 2009 22:27:58 Larry Finger wrote:
> [email protected] 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

2010-03-09 02:12:54

by Larry Finger

[permalink] [raw]
Subject: Re: Deauthentications with p54usb

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