wpa_supplicant: authentication timeout problem

[Thomas Schulz]

Jagadish wrote:
> 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.
> 
> Deployment:
> 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, 
> channel:11)
> 
> 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.

> Scenario:
> The authentication timeouts in wpa_supplicant source code are set around 
> 200ms. 

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 
> timeouts.
> I tried to introduce delay less than one second. Still I am getting 
> authentication timeouts.
> 
> Clarifications:
> (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
wpa_supplicant.
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
within milliseconds.
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
http://lkml.org/lkml/2007/5/8/181

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.

> 
> thanks,
> Jagadish

HTH

> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap

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