roam problem with wpa_supplicant and madwifi
t.schulz at zetesind.com
Wed Jun 6 10:55:17 EDT 2007
Roaming from an accesspoint with low rssi (oldAP) to an accesspoint
with higher rssi (newAP) takes several (5..20) seconds until
authentication with newAP succeeds. During that time the wireless
connection is not available for application data transfer.
Without wpa_supplicant, i.e. WEP encryption only, the madwifi driver
roams to newAP in less than 1 second.
My test environment is:
- some fixes for roam on rssi/rate threshold exceeded,
work well as roaming without wpa_supplicant is OK
- debug logging enabled:
80211debug -i eth1 +assoc +auth +scan +roam +node +inact +state
athdebug -i wifi0 +beacon +beacon_proc +node +state
- "-D wext" for wireless-extensions driver
- "-dd -t -K" for maximum logging
- tuned EAPOL parameters for faster and more retries:
EAPOL::startPeriod=5 EAPOL::authPeriod=3 EAPOL::maxStart=6
- configuration "scan_ssid=1" and default "ap_scan=1"
- linux kernel 2.6.16
- 3 accesspoints in an office floor
The roam taking so long seems to be caused by 2 things:
1. The madwifi driver reassociates with the oldAP upon each ioctl
SIOCSIWxxx in wpa_driver_wext_associate(). Only the last
ioctl SIOCSIWAP makes madwifi associate with the newAP.
2. The madwifi driver generates 2 wireless events SIOCGIWAP
when it (re)associates with an accesspoint, the log shows:
1st "Wireless event: new AP: 00:00:00:00:00:00" (Not-Associated),
2nd "Wireless event: new AP: 00:15:70:14:7e:ed".
The Not-Associated events seem to cause trouble, because they make
wpa_supplicant change to state DISCONNECTED and blacklist the
1. What is responsible for avoiding reassociate on each SIOCSIWxxx:
wpa_supplicant or the madwifi driver ?
2 How to avoid the wireless event "Not-Associated" causing trouble:
Shall wpa_supplicant ignore it ?
Or shall the madwifi driver not generate it ?
Some bits from log inspections:
- The roaming process begins with wpa_supplicant getting scan results
from the madwifi driver. These scan results come from madwifi's
background scan, wpa_supplicant did not request the scan.
- wpa_supplicant and madwifi sometimes have different opinions with
which accesspoint they are associated, log:
Wireless event: new AP: 00:15:70:14:7e:ed
State: DISCONNECTED -> ASSOCIATED
Associated to a new BSS: BSSID=00:15:70:14:7a:f5
The first MAC is the oldAP, the second the desired newAP.
- wpa_supplicant receives EAP-RequestID from the oldAP and replies
EAP-ResponseID to the newAP. The newAP does not answer, because the
madwifi driver is still associated with the oldAP.
Timeout occurs (5 sec) and wpa_supplicant retries with send
EAPOL-Start to the newAP.
Thanks in advance
Tel: +49 (0) 40 532888 14
Fax: +49 (0) 40 532888 99
Mobil: +49 (0) 173 518 18 22
E-Mail: t.schulz at zetesIND.com <mailto:t.schulz at zetesIND.com>
Langenhorner Chaussee 42
Sitz der Gesellschaft: Hamburg
HRB Hamburg 55188
Geschäftsführer: Rainer Skau
More information about the HostAP