Search Linux Wireless

Re: [PATCH] Fix NetworkManager/wpa_supplicant race condition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2007-04-18 at 10:40 -0600, Tim Gardner wrote:
> This patch fixes an assumption made by wpa_supplicant. Any time
> wpa_supplicant requests to set an ESSID (e.g., associate), it expects an
> event notifying that association has completed. If the Networkmanager
> has already setup an association, such as for an open auth AP, then the
> request to associate by wpa_supplicant will be ignored.
> 
> If Networkmanager is requested to restart the connection, such as by
> clicking on the SSID, then wpa_supplicant is allowed to build the
> association from scratch, which always works.
> 
> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/103768
> 
> By always emitting this event, am I causing any unintended side effects?

Interesting.  Setting the SSID should _always_ trigger a reassociation,
and therefore eventually trigger an SIOCGIWAP event to userspace.  So
this patch looks right from the behavioral point of view.

But it doesn't look right from the technical perspective.  Why isn't
softmac trying to reassociate?  Does it automatically reassociate if
parameters, like auth mode, keys, WPA, etc are set and so therefore,
when it comes around to the SSID being set it doesn't really matter?  If
so, we should still be sending the event, and this patch is OK.  But can
somebody _guarantee_ that if I authenticate to an AP, then later call
SIOCSIWENCODE, and then SIOCSIWESSID to the same SSID, that the new WEP
keys have been applied and a reassociation has occurred?  If the auth
mode is shared key, a reassociation attempt needs to happen.

WEXT convention is that setting the SSID or BSSID triggers reassociation
with the current parameters.  I'd argue that softmac should be starting
the association process over again when either SIOCSIWESSID or
SIOCSIWBSSID is called.

Dan

> rtg
> plain text document attachment (bug_103768)
> diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
> index fa2f7da..cc2e8ba 100644
> --- a/net/ieee80211/softmac/ieee80211softmac_wx.c
> +++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
> @@ -88,6 +88,13 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,
>  		   !memcmp(n->essid.data, extra, n->essid.len)) {
>  			dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
>  				MAC_ARG(sm->associnfo.bssid));
> +			/* wpa_supplicant expects an association event, regardless of prior
> +			 * association state. If associating, then the associnfo.work task
> +			 * will send the appropriate event.
> +			 */
> +			if (sm->associnfo.associated)
> +				ieee80211softmac_call_events_locked(sm,
> +					IEEE80211SOFTMAC_EVENT_ASSOCIATED, n);
>  			goto out;
>  		} else {
>  			dprintk(KERN_INFO PFX "Canceling existing associate request!\n");

-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux