* Re: Deauthentications with p54usb
@ 2009-08-13 22:27 Chunkeey
2009-08-13 22:53 ` Larry Finger
2009-08-14 17:17 ` Kalle Valo
0 siblings, 2 replies; 12+ messages in thread
From: Chunkeey @ 2009-08-13 22:27 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
"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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
2009-08-13 22:27 Deauthentications with p54usb Chunkeey
@ 2009-08-13 22:53 ` Larry Finger
2009-08-14 10:41 ` Christian Lamparter
2009-08-14 17:17 ` Kalle Valo
1 sibling, 1 reply; 12+ messages in thread
From: Larry Finger @ 2009-08-13 22:53 UTC (permalink / raw)
To: Chunkeey; +Cc: wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
2009-08-13 22:53 ` Larry Finger
@ 2009-08-14 10:41 ` Christian Lamparter
0 siblings, 0 replies; 12+ messages in thread
From: Christian Lamparter @ 2009-08-14 10:41 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
2009-08-13 22:27 Deauthentications with p54usb Chunkeey
2009-08-13 22:53 ` Larry Finger
@ 2009-08-14 17:17 ` Kalle Valo
1 sibling, 0 replies; 12+ messages in thread
From: Kalle Valo @ 2009-08-14 17:17 UTC (permalink / raw)
To: Chunkeey; +Cc: Larry Finger, wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
@ 2009-08-09 21:45 Chunkeey
0 siblings, 0 replies; 12+ messages in thread
From: Chunkeey @ 2009-08-09 21:45 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
"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/
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Deauthentications with p54usb
@ 2009-08-09 20:02 Chunkeey
2009-08-09 20:27 ` Larry Finger
0 siblings, 1 reply; 12+ messages in thread
From: Chunkeey @ 2009-08-09 20:02 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
"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/
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Deauthentications with p54usb
2009-08-09 20:02 Chunkeey
@ 2009-08-09 20:27 ` Larry Finger
2010-03-08 23:38 ` Christian Lamparter
0 siblings, 1 reply; 12+ messages in thread
From: Larry Finger @ 2009-08-09 20:27 UTC (permalink / raw)
To: Chunkeey; +Cc: wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
2009-08-09 20:27 ` Larry Finger
@ 2010-03-08 23:38 ` Christian Lamparter
2010-03-09 2:12 ` Larry Finger
0 siblings, 1 reply; 12+ messages in thread
From: Christian Lamparter @ 2010-03-08 23:38 UTC (permalink / raw)
To: Larry Finger, wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
2010-03-08 23:38 ` Christian Lamparter
@ 2010-03-09 2:12 ` Larry Finger
0 siblings, 0 replies; 12+ messages in thread
From: Larry Finger @ 2010-03-09 2:12 UTC (permalink / raw)
To: Christian Lamparter; +Cc: wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Deauthentications with p54usb
@ 2009-08-07 20:50 Larry Finger
2009-08-07 21:50 ` Christian Lamparter
0 siblings, 1 reply; 12+ messages in thread
From: Larry Finger @ 2009-08-07 20:50 UTC (permalink / raw)
To: Chr; +Cc: wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
2009-08-07 20:50 Larry Finger
@ 2009-08-07 21:50 ` Christian Lamparter
2009-08-09 15:12 ` Larry Finger
0 siblings, 1 reply; 12+ messages in thread
From: Christian Lamparter @ 2009-08-07 21:50 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deauthentications with p54usb
2009-08-07 21:50 ` Christian Lamparter
@ 2009-08-09 15:12 ` Larry Finger
0 siblings, 0 replies; 12+ messages in thread
From: Larry Finger @ 2009-08-09 15:12 UTC (permalink / raw)
To: Christian Lamparter; +Cc: wireless
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-03-09 2:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-13 22:27 Deauthentications with p54usb Chunkeey
2009-08-13 22:53 ` Larry Finger
2009-08-14 10:41 ` Christian Lamparter
2009-08-14 17:17 ` Kalle Valo
-- strict thread matches above, loose matches on Subject: below --
2009-08-09 21:45 Chunkeey
2009-08-09 20:02 Chunkeey
2009-08-09 20:27 ` Larry Finger
2010-03-08 23:38 ` Christian Lamparter
2010-03-09 2:12 ` Larry Finger
2009-08-07 20:50 Larry Finger
2009-08-07 21:50 ` Christian Lamparter
2009-08-09 15:12 ` Larry Finger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).