Endless loop of association & de-auth

[Ben Greear]

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
> case?

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

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

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

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com