From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.tpi.com ([198.107.51.143]:2311 "EHLO mail.tpi.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993062AbXDRTSc (ORCPT ); Wed, 18 Apr 2007 15:18:32 -0400 Message-ID: <46266EF9.3050001@canonical.com> Date: Wed, 18 Apr 2007 13:18:17 -0600 From: Tim Gardner MIME-Version: 1.0 To: Dan Williams CC: linux-wireless , kernel-team@lists.ubuntu.com Subject: Re: [PATCH] Fix NetworkManager/wpa_supplicant race condition References: <462649E3.4000208@canonical.com> <1176916954.20244.14.camel@localhost.localdomain> In-Reply-To: <1176916954.20244.14.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Dan Williams wrote: > 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"); > I don't think simply reassociating is sufficient. Consider what happens if the authentication algorithm is changed. ieee80211_wx_set_auth() does nothing more then set some values. A subsequent attempt to reassociate would get all hosed up. A quick look at ieee80211_ioctl_siwessid() shows that it always forces an authentication cycle. I'll experiment a little to see how the Softmac can be driven through an authentication/association cycle on calls to SIOCSIWESSID or SIOCSIWAP. rtg -- Tim Gardner tim.gardner@ubuntu.com