Handoff with wpa_supplicant and madwifi driver
stephan.schlumbohm at tu-harburg.de
Thu Nov 24 22:38:04 EST 2005
I did some testing with the same wireless card under Windows with a Cisco
driver (and supplicant) and got a handoff time of less than 300 ms on
average. In this setup the station is sending re-association request frames
to the new access point.
I tested then the same card together with the Cisco driver under Linux using
Linuxand DriverLoader and wpa_supplicant-0.4.7. I achieved for the same
setup a handoff time of 1 to 1.5 seconds on average. This time
wpa_supplicant is using re-association request frames as well (as compared
to the madwifi-ng driver). It seems wpa_supplicant is not performing a very
quick handoff. As I understand, the handoff is triggered by the driver,
wpa_supplicant gets a wireless event and some re-association information and
then walks through the re-association. It seems to me that the handoff is
not very well implemented in the madwifi driver and / or the madwifi driver
is not communicating the information in the right way to wpa_supplicant.
Another thing I noticed with both supplicants is that if you keep sending
ICMP Echo Request every 20 ms during the handoff you can screw up the EAPOL
message exchange very badly. Handoff in that setup to up to 10!! seconds,
because the station went through a few authentications until it finally
The handoff is created naturally, just by walking the laptop out of the
range of the first access point to the next access point. Mesh access points
just connect the access points wirelessly together instead of over a wired
Von: hostap-bounces+stephan.schlumbohm=tu-harburg.de at shmoo.com
[mailto:hostap-bounces+stephan.schlumbohm=tu-harburg.de at shmoo.com] Im
Auftrag von Leonardo Maccari
Gesendet: Dienstag, 22. November 2005 03:48
An: hostap at shmoo.com
Betreff: Re: Handoff with wpa_supplicant and madwifi driver
On Sat, Nov 19, 2005 at 01:14:45PM -0800, Stephan Schlumbohm wrote:
> Hi all,
> I'm having serious trouble with the handoff from one access point to
another using wpa_supplicant (stable 0.3.8 and development 0.4.6) with the
madwifi driver (madwifi-ng latest svn snapshot from madwifi.org).
> Both access points have the same ESSID and operate on the same channel and
have the same security settings. In fact, those access points are mesh
access points - both are connected to a FreeRADIUS server.
> Authentication (Open, WPA-PSK, WPA-802.1X-TLS/PEAP/TTLS) works fine in
this setup to each access point.
> But, when I try to roam from one access point to another, wpa_supplicant
does not initiate a reassociation request to the new access point. Instead,
it disassociates the old access point, then it performs the scanning and
then finally goes through a full new authentication with the new access
My experience says that scan time is not the real bottlenck, delay is
introduced by loss of conectivity _before_ triggering a new scan, then from
RADIUS authentication (multi-hop packets, worse in a mesh environment), and
finally some delays that I couldn't really explain after authentication and
before first EAPOL packet. Jouni said a few time ago that a bug was cleaned
that caused hostapd waste some time after authentication.
Anyway if you use WPA/WPA2 you must renegotiate the PMK key (whatever
authentication method you use) and renegotiate the PTK/GTK.
> This causes the handoff to take about 1.5 to 3 seconds. This is not
acceptable and is not intended by the developers. A single channel handoff
should take about 10 to 300 ms (depending on authentication).
there is an old thread about handoff times that you might read in the
a couple questions: how do you trigger handoff procedure from one AP to
another? and what does mesh access points means? how do they authenticate
each other ?
Key fingerprint = 3129 C583 F03B 2E73 0115 C040 3489 0185 B592 19FE
Obviously -thisaintpartofmyaddress- is not part of my real email address
HostAP mailing list
HostAP at shmoo.com
More information about the HostAP