Fix NetworkManager/wpa_supplicant race condition

PATCH In review Tim Gardner 2 participants 5 messages Apr 18, 2007 – Apr 19, 2007 Networking

Share & tools

Tim Gardner

author

2007-04-18 17:07 UTC #0 lore raw

PATCH 1/1 Fix NetworkManager/wpa_supplicant race condition

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?

rtg

Signature · 1 line

Tim Gardner [email protected]

net/ieee80211/softmac/ieee80211softmac_wx.c +7 -0

index fa2f7da..cc2e8ba 100644
@@ -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");

Dan Williams

2007-04-18 17:52 UTC #1 lore raw

Quoted 6 lines · Tim Gardner

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.

Quoted 7 lines

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

Quoted 20 lines

rtg
plain text document attachment (bug_103768)

net/ieee80211/softmac/ieee80211softmac_wx.c +7 -0

index fa2f7da..cc2e8ba 100644
@@ -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");

Tim Gardner

author

2007-04-18 19:18 UTC #2 lore raw

Quoted 48 lines · Dan Williams

Quoted 6 lines · Tim Gardner
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.
Quoted 7 lines
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
Quoted 12 lines
rtg
plain text document attachment (bug_103768)
net/ieee80211/softmac/ieee80211softmac_wx.c +2 -0
index fa2f7da..cc2e8ba 100644
@@ -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

Quoted 9 lines

net/ieee80211/softmac/ieee80211softmac_wx.c ieee80211softmac_wx_set_essid(struct net_device *net_dev, · line 100
Quoted 8 lines
net/ieee80211/softmac/ieee80211softmac_wx.c +5 -0
+			 * 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

Signature · 1 line

Tim Gardner [email protected]

Dan Williams

2007-04-19 03:00 UTC #3 lore raw

Quoted 59 lines · Tim Gardner

Quoted 48 lines · Dan Williams
Quoted 6 lines · Tim Gardner
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.
Quoted 7 lines
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
Quoted 12 lines
rtg
plain text document attachment (bug_103768)
net/ieee80211/softmac/ieee80211softmac_wx.c +2 -0
index fa2f7da..cc2e8ba 100644
@@ -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
Quoted 9 lines
net/ieee80211/softmac/ieee80211softmac_wx.c ieee80211softmac_wx_set_essid(struct net_device *net_dev, · line 100
Quoted 8 lines
net/ieee80211/softmac/ieee80211softmac_wx.c +5 -0
+			 * 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");

Quoted 4 lines

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.

When I say "reassociate", I mean a new association cycle to the _same_ BSSID/SSID using the settings that are current at that point in time. I guess I should have made that clear.

Dan

Quoted 7 lines

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

author

2007-04-19 15:51 UTC #4 lore raw

Dan Williams wrote:

snip, snip

Quoted 14 lines

When I say "reassociate", I mean a new association cycle to the _same_ BSSID/SSID using the settings that are current at that point in time. I guess I should have made that clear.
Dan
Quoted 7 lines
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

Dan,

I agree that driving the SoftMAC protocol through an auth/assoc cycle when changing ESSID or BSSID is architecturally the right thing to do. However, the required changes are a bit too extensive for me to add to a recently released kernel (Feisty). I'll have to get back to this when I have more freedom to whack and slash.

In the meantime, I still think emitting an ASSOC event is a good interim fix. I'll be testing it over the next few days within the Ubuntu community.

rtg

Signature · 1 line

Tim Gardner [email protected]