wpa_supplicant authentication timeout problem
Sat Jun 23 21:50:29 PDT 2007
> Hi Thomas Schulz,
> I am using suse 10.1. Kernel version is 184.108.40.206-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 220.127.116.11.
> 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
and the thread
and another fellow sufferer
> 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.
Hope this helps
Langenhorner Chaussee 42
More information about the Hostap