[pkg-wpa-devel] Bug#403045: wpasupplicant: race condition in wpa_action disconnect between ifdown and if_post_down_up

[Stefan Lippers-Hollmann]

tags 403045 - patch
thanks

Hi

On Monday 26 September 2011, Henning Glawe wrote:
> Package: wpasupplicant
> Version: 0.5.5-3
> Severity: normal
> Tags: patch
> 
> I have configured a roaming wpa configuration on my laptop using
> 
> allow-hotplug wlan0
> iface wlan0 inet manual
>         wpa-driver wext
> 		wpa-roam /etc/wpa_supplicant.conf
> 
> in /etc/network/interfaces.
> 
> If a disconnect event occurs, wpa_action is called with the action
> DISCONNECTED, which "ifdown"s the interface and then should immediately
> re-enable the scanning mode by calling 
> /etc/wpa_supplicant/functions.sh::if_post_down_up
> 
> the problem is, at least in my case, that the link is _down_ afterwards,
> so wpasupplicant is not able to scan further. This seems to be caused by
> the interface not being completely downed yet when ifdown finishes;
> putting a 'sleep 1' into functions.sh::ifdown immediately after the call
> to /sbin/ifdown "solves" this problem.
> 
> Furter system configuration info:
> - madwifi-ng wlan, using wpa_supplicants 'wext' driver
> - dhcpcd dhcp client
> 
> 
> -- System Information:
> Debian Release: 4.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.18-3-686
> Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> 
> Versions of packages wpasupplicant depends on:
> ii  libc6                        2.3.6.ds1-9 GNU C Library: Shared libraries
> ii  libdbus-1-3                  1.0.1-2     simple interprocess messaging syst
> ii  libncurses5                  5.5-5       Shared libraries for terminal hand
> ii  libreadline5                 5.2-1       GNU readline and history libraries
> ii  libssl0.9.8                  0.9.8c-4    SSL shared libraries
> ii  lsb-base                     3.1-22      Linux Standard Base 3.1 init scrip
> 
> Versions of packages wpasupplicant recommends:
> pn  dhcp3-client                  <none>     (no description available)

Given that this bug hasn't seen any action in 4 years and considering 
that both wpasupplicant and the kernel (ath5k with replacing 
madwifi-ng) have changed massively since then, I'd like to know if this
is still an issue using contemporary wpasupplicant versions, ath5k and
wpa_supplicant's 'nl80211' driver.

Regards
	Stefan Lippers-Hollmann