wpa_supplicant authentication timeout problem

[Jagadish]

Jagadish wrote:
> Hi Thomas Schulz,

Hello Jagadish,

> I am using suse 10.1. Kernel version is 2.6.16.13-4.

Looks very similar to the kernel version where I discovered the problem.
I'm using a customized kernel based on Debian kernel source package
linux-source-2.6.16_2.6.16-8_all.deb, which is based on kernel main line
stable release 2.6.16.6.

> Here are the questions you have asked me followed by my answers.
>
> (1) Which "authentication timeouts" do you mean?
>
> Here the authentication timeouts are for (a) Receiving first packet of 
> EAPOL 4-way handshake.
> (b) Completing the 4-way hand shake procedure.
>
> You said that netif_carrier_on() is delayed by 1 second and messages 
> sent during that
> time are discarded. Is this happening only in WPA mode? 

No, messages are discarded regardless of WPA or WEP mode.
I tested it with 'ping -i 0.2 <ipaddr>' and observed 5 lost pings
whenever madwifi roamed from one to another AP.
Messages will be discarded only if netif_carrier_off() _precedes_
netif_carrier_on() within some milliseconds. I did not observe the
1-second-transmission-drop after association if it was the initial
one and when changing AP took more than 1 second.

Rodolfo Giometti did also observe "1000ms delay after roaming", see
http://article.gmane.org/gmane.linux.drivers.madwifi.devel/4230
and the thread
http://thread.gmane.org/gmane.linux.drivers.madwifi.devel/4092/focus=4100
and another fellow sufferer
http://thread.gmane.org/gmane.linux.drivers.madwifi.devel/4258

> When we associate to an AP in open mode, we observed that this problem 
> was not occured. After association success (i.e., after calling 
> netif_carrier_on()), we were able to send data packets before the 1 
> second delay.

I did not test it without WEP encryption, i.e. "open mode".
It seems strange to me that you did not observe the
1-second-transmission-drop in "open mode". I guess that no 
netif_carrier_off() preceded netif_carrier_on() (initial association)
or the interval between them was more than 1 second.

> But in WPA case, after disassociating with AP-1, in the process of 
> association with AP-2, we observed that AP-2 is sending the first 
> packet of 4-way handshake for many times (Problem here is that client 
> is timing out before sending second packet of 4-way handshake).

I think that the association triggers the AP to send the first packet of
4-way handshake. The AP will repeat this after its own timeout (how long
ist that on your APs?) if it did not get an answer from the client.
I did never observe your scenario, because my wpa_supplicant's timeout
(5 seconds) is longer than my APs' timeout (2 seconds).

Please post a log to shed more light on your problem.
Run 'wpa_supplicant -ddt' for maximum debug level and timestamps and
also enable madwifi logging. For the latter I'm using
  80211debug -i ath0 +assoc +auth +scan +roam +node +inact +state +power
  athdebug -i wifi0 +beacon +beacon_proc +node +state +reset
  echo "4 4 1 7" > /proc/sys/kernel/printk
(the last command for keeping the console silent).

> Can you please clarify this difference between open mode and WPA mode. 
> If you have already fixed this problem, it would be of great help if 
> you could send the patch to fix this problem.

I will submit a patch to the madwifi ticket system.

> thanks,
> Jagadish

Hope this helps

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