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/lkm
l/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 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&g
t;
_______________________________________________
HostAP mailing list
HostAPshmoo.com
http:/
/lists.shmoo.com/mailman/listinfo/hostap
|
