BUG? I can reproduce "Association request to the driver failed" at will

Holger Schurig hs4233
Mon Sep 21 08:31:38 PDT 2009


Hmm, this seems to be racy. This morning I succeeded 3 times to 
get that message, now I didn't on the first try. But now I 
enabled verbose-mac80211-debugging ...

But on the second try, I succeeded again.

> Let wpa_supplicant associate.

phy10: Selected rate control algorithm 'minstrel'
ath5k phy10: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy10: RF2112B 2GHz radio found (0x46)
eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:13:19:80:da:30 (try 1)
eth1: authenticated
eth1: associate with AP 00:13:19:80:da:30 (try 1)
eth1: RX AssocResp from 00:13:19:80:da:30 (capab=0x11 status=0 
aid=114)
eth1: associated

> Turn one AP off. wpa_supplicant automatically associates to the
> second. 

eth1: deauthenticated from 00:13:19:80:da:30 (Reason: 1)
eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1: direct probe to AP 00:13:19:80:da:30 (try 2)
eth1: direct probe to AP 00:13:19:80:da:30 (try 3)
eth1: direct probe to AP 00:13:19:80:da:30 timed out
eth1: direct probe to AP 00:1b:d4:44:35:90 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:1b:d4:44:35:90 (try 1)
eth1: authenticated
eth1: associate with AP 00:1b:d4:44:35:90 (try 1)
eth1: RX AssocResp from 00:1b:d4:44:35:90 (capab=0x11 status=0 
aid=127)
eth1: associated

Side node: here mac80211 had stale scan data in the cache, thus 
wpa_supplicant first asked it to authenticate to the 
just-turned-off AP. You can see the three probes ...


> Now turn the first AP on again. Issue a manual scan command

eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:13:19:80:da:30 (try 1)
eth1: authenticate with AP 00:13:19:80:da:30 (try 2)
eth1: authenticated

-- 
http://www.holgerschurig.de



More information about the Hostap mailing list