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