Endless loop of association & de-auth
Sun Jan 30 12:35:21 PST 2011
On 01/30/2011 11:07 AM, Jouni Malinen wrote:
> On Sat, Jan 29, 2011 at 10:45:36PM -0800, Ben Greear wrote:
>> I have 129 stations trying to connect to hostap. This is the hostapd
>> that isn't sending wmm_params, so hostapd is configured for HT40-,
>> but clients are running 'NO HT'. Rates for associated stations are
>> low (13.5 mostly).
>> Driver is ath9k, kernel 2.6.37 wireless-testing. Client side is 2.6.38-rc2-wireless testing.
> I'm assuming this is with the client side using virtual station
> interfaces with a shared radio and running wpa_supplicant. Is that the
Yes. The client side is constantly showing disconnect with reason code 2,
so maybe it's the problem. I'm having a hard time determining the
Also, I don't see the endless loop if the AP is running w/out HT40
(which in my case, makes the rates closer to 130Mbps instead of
>> Here is a snippet of hostapd logs.
>> 1296369318.329355: mgmt::auth
>> 1296369318.330644: 1296369318.344601: vap0: mgmt::deauth
>> 1296369318.344678: vap0: deauthentication: STA=00:0c:42:61:00:0e reason_code=4
> That is the station deauthenticating and wpa_supplicant doesn't use that
> reason code. As such, it would need to be coming from somewhere in
> cfg80211 or mac80211. The only place where I can see these reason codes
> being used in in net/mac80211/mlme.c for the case where the connection
> to the AP has been lost (Beacon loss?). That reason code seems quite
> bogus for that particular case, but anyway, I would assume something
> prevents the station from receiving Beacon frames from the AP and
> directed polls would also be failing.. This should show up in mac80211
> debug on the station.
I didn't see anything obvious. Even if it's beacon loss, I think it
should take longer than .5sec to give up.
I'll poke at it some more.
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the Hostap