roam problem with wpa_supplicant and madwifi

[Thomas Schulz]

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:
- madwifi-0.9.3
   - 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
- wpa_supplicant-0.5.7
   - "-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
     desired newAP.

Questions:
  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
Thomas

-- 
Thomas Schulz
Software-Entwicklung
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>

zetesIND GmbH
Langenhorner Chaussee 42
22335 Hamburg
www.zetesIND.com <http://www.zetesIND.com>

Sitz der Gesellschaft: Hamburg
HRB Hamburg 55188
Gesch?ftsf?hrer: Rainer Skau