wpa_supplicant: authentication timeout problem
Wed Jun 20 15:08:26 PDT 2007
> Hi everybody,
> Our wireless client has atheros wireless card (madwifi-0.9.3 driver).
> The deployment, scenario and the problem I am facing are explained below.
> There are two access points in range of wireless client.
> (1) AP-1, configured with ssid: helloworld, Security mode: WPA2, channel:6)
> (2) AP-2, configured with ssid: helloworld, Security mode: WPA2,
> Our requirement:
> Our wireless client has to roam from AP-1 to AP-2 with minimal delay (In
> order of milli seconds).
How do you plan to achive roam within some milliseconds?
According to my experiences a full EAP-TTLS-PAP authentication takes
180..250 milliseconds, a reauthentication with only 4WAY_HANDSHAKE for
keys takes 70..100 milliseconds.
> The authentication timeouts in wpa_supplicant source code are set around
Which "authentication timeouts" do you mean?
The EAP timeouts (seconds) can be set at runtime, e.g.
'wpa_cli set EAPOL::startPeriod 5', similar for "EAPOL::authPeriod".
> I ran wpa_supplicant at client side and associated to AP-1.
> After successful association with AP-1, I
> switched off AP-1. Now it disassociated with AP-1.
> Now it has to associate with AP-2. But I am observing authentication
> timeouts (failed to authenticate) for some times. After some iterations
> it is able to associate with AP-2.
I guess wpa_supplicant gets the initial request message from AP-2 and
sends an appropriate response, but AP-2 does not answer the latter.
Messages sent by wpa_supplicant get lost during almost exactly 1 second
after the disassociation event. They are transmitted and answered by
AP-2 after some "RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added"
appeared in the wpa_supplicant log.
Can you approve these presumptions?
> If I introduce one second delay after getting disassociation event (for
> AP-1) from the driver, I am able to associate
> with AP-2 immediately after one second delay without any authentication
> I tried to introduce delay less than one second. Still I am getting
> authentication timeouts.
> (1) Why authentication timeouts occurred without one second delay? Is
> this delay required (for some unknown reasons like key clean-up e.t.c.)?
I assume you use Linux on the client, which kernel version?
The one second delay is not required, but a problem with the madwifi
driver and the Linux kernel.
Madwifi does netif_carrier_off() in ieee80211_notify_node_leave() when
it loses association with AP-1 due to "beacon miss". After association
with AP-2 it does netif_carrier_on() in ieee80211_notify_node_join(),
usually only some milliseconds after netif_carrier_off().
netif_carrier_off() and netif_carrier_on() are information about the
state of the network interface and both call linkwatch_fire_event(),
which is in <linux-source>/net/core/link_watch.c. Therein the rate of
linkwatch events is limited to one per second to prevent a storm of
messages on the netlink socket. Due to this limitation the effect of
netif_carrier_on() is delayed by 1 second and messages sent during that
time are discarded, although messages received by madwifi are passed to
IMHO the fault is neither alone in madwifi nor in the Linux kernel,
but both could behave better.
Madwifi should not ieee80211_notify_node_leave() about lost association,
but only about association to the new AP, because this usually happens
The Linux kernel should not suspect an event storm by only 2 linkwatch
events within short time. At least it should immediately process the
important event from netif_carrier_on() instead of delaying it.
The Linux kernel people (Herbert Xu) seem to be working on this, found
I am working on a solution in madwifi. ieee80211_notify_node_leave()
delays netif_carrier_off() and wireless_send_event() by e.g. 100 ms.
ieee80211_notify_node_join() cancels the delay timer if association to
the new AP happens earlier and no carrier off events will be sent.
> (2) Is this a problem in madwifi driver or wpa_supplicant?
No problem in wpa_supplicant, but the madwifi driver and the Linux
kernel cooperate to produce this problem ;-). It can be solved in
either of them.
> HostAP mailing list
> HostAP at shmoo.com
Langenhorner Chaussee 42
More information about the Hostap