[pkg-wpa-devel] Bug#403045: wpasupplicant: race condition in wpa_action disconnect between ifdown and if_post_down_up
Stefan Lippers-Hollmann
s.L-H at gmx.de
Mon Sep 26 15:43:31 UTC 2011
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
More information about the Pkg-wpa-devel
mailing list