Skip to contentSkip to conversation

Deauthentications with p54usb

DISCUSSION [email protected] 3 participants 4 messages Aug 9, 2009 – Mar 9, 2010

lore
Share & tools
lore

[email protected]

author
#0 lore raw

"Larry Finger" <[email protected]> wrote

Quoted 16 lines
Quoted 15 lines · Christian Lamparter

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?

Quoted 7 lines
Quoted 3 lines

(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.

Quoted 2 lines

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/

#1 lore raw
Quoted 28 lines · [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.

Quoted 6 lines
Quoted 2 lines

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.

Quoted 9 lines

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

#2 lore raw

Hello Larry,

Remember?

Quoted 50 lines · On Sunday 09 August 2009 22:27:58 Larry Finger wrote:
Quoted 28 lines · [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.

Quoted 6 lines
Quoted 2 lines

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.

Quoted 7 lines

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).

Quoted 6 lines
Quoted 2 lines

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

#3 lore raw
Quoted 3 lines · Christian Lamparter

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