Skip to contentSkip to conversation

roaming/disassoc fixes

PATCH In review Johannes Berg 2 participants 5 messages Aug 6, 2009 – Aug 8, 2009

Subsystems (2)
mac80211 802.11 (including cfg80211/NL80211)
lore
Share & tools
lore

Johannes Berg

author maintainer
#0 lore raw

cover roaming/disassoc fixes

Pavel reported a bug, and it was hard to fix :)

Here's the fix patchset, including another fix
for a bug I noticed while testing.

This requires Pavel's patch, of course, but applies without it in the tree too.

johannes

author maintainer
#1 lore raw

PATCH 1/3 mac80211: stay authenticated after disassoc

After being disassociated by the AP, mac80211 currently reports this to cfg80211, and then goes to delete the association. That's fine, but cfg80211 assumes that it's still authenticated, however, mac80211 throws away all state.

This fixes mac80211 to keep track of the authentication in that case so that cfg80211 can request a deauth or new association properly.

Signed-off-by Johannes Berg <[email protected]>
---
 net/mac80211/ieee80211_i.h |    1 +
 net/mac80211/mlme.c        |   31 ++++++++++++++++++++++---------
 2 files changed, 23 insertions(+), 9 deletions(-)
net/mac80211/ieee80211_i.h +1 -0
@@ -284,6 +284,7 @@ struct ieee80211_if_managed {
 
 	struct mutex mtx;
 	struct ieee80211_bss *associated;
+	struct ieee80211_mgd_work *old_associate_work;
 	struct list_head work_list;
 
 	u8 bssid[ETH_ALEN];
net/mac80211/mlme.c +22 -9
@@ -880,10 +880,11 @@ static u32 ieee80211_handle_bss_capabili
 }
 
 static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
-				     struct ieee80211_bss *bss,
+				     struct ieee80211_mgd_work *wk,
 				     u32 bss_info_changed)
 {
 	struct ieee80211_local *local = sdata->local;
+	struct ieee80211_bss *bss = wk->bss;
 
 	bss_info_changed |= BSS_CHANGED_ASSOC;
 	/* set timing information */

@@ -896,6 +897,7 @@ static void ieee80211_set_associated(str
 		bss->cbss.capability, bss->has_erp_value, bss->erp_value);
 
 	sdata->u.mgd.associated = bss;
+	sdata->u.mgd.old_associate_work = wk;
 	memcpy(sdata->u.mgd.bssid, bss->cbss.bssid, ETH_ALEN);
 
 	/* just to be sure */

@@ -1010,7 +1012,8 @@ ieee80211_authenticate(struct ieee80211_
 	return RX_MGMT_NONE;
 }
 
-static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata)
+static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
+				   bool deauth)
 {
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 	struct ieee80211_local *local = sdata->local;

@@ -1028,6 +1031,16 @@ static void ieee80211_set_disassoc(struc
 	ifmgd->associated = NULL;
 	memset(ifmgd->bssid, 0, ETH_ALEN);
 
+	if (deauth) {
+		kfree(ifmgd->old_associate_work);
+		ifmgd->old_associate_work = NULL;
+	} else {
+		struct ieee80211_mgd_work *wk = ifmgd->old_associate_work;
+
+		wk->state = IEEE80211_MGD_STATE_IDLE;
+		list_add(&wk->list, &ifmgd->work_list);
+	}
+
 	/*
 	 * we need to commit the associated = NULL change because the
 	 * scan code uses that to determine whether this iface should

@@ -1345,7 +1358,7 @@ ieee80211_rx_mgmt_deauth(struct ieee8021
 			sdata->dev->name, bssid, reason_code);
 
 	if (!wk) {
-		ieee80211_set_disassoc(sdata);
+		ieee80211_set_disassoc(sdata, true);
 	} else {
 		list_del(&wk->list);
 		kfree(wk);

@@ -1378,7 +1391,7 @@ ieee80211_rx_mgmt_disassoc(struct ieee80
 	printk(KERN_DEBUG "%s: disassociated (Reason: %u)\n",
 			sdata->dev->name, reason_code);
 
-	ieee80211_set_disassoc(sdata);
+	ieee80211_set_disassoc(sdata, false);
 	return RX_MGMT_CFG80211_DISASSOC;
 }
 

@@ -1581,7 +1594,8 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
 	 * ieee80211_set_associated() will tell the driver */
 	bss_conf->aid = aid;
 	bss_conf->assoc_capability = capab_info;
-	ieee80211_set_associated(sdata, wk->bss, changed);
+	/* this will take ownership of wk */
+	ieee80211_set_associated(sdata, wk, changed);
 
 	/*
 	 * Start timer to probe the connection to the AP now.

@@ -1590,7 +1604,6 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
 	ieee80211_sta_rx_notify(sdata, (struct ieee80211_hdr *)mgmt);
 	mod_beacon_timer(sdata);
 
-	kfree(wk);
 	return RX_MGMT_CFG80211_ASSOC;
 }
 

@@ -2096,7 +2109,7 @@ static void ieee80211_sta_work(struct wo
 			printk(KERN_DEBUG "No probe response from AP %pM"
 				" after %dms, disconnecting.\n",
 				bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
-			ieee80211_set_disassoc(sdata);
+			ieee80211_set_disassoc(sdata, true);
 			mutex_unlock(&ifmgd->mtx);
 			/*
 			 * must be outside lock due to cfg80211,

@@ -2500,7 +2513,7 @@ int ieee80211_mgd_deauth(struct ieee8021
 
 	if (ifmgd->associated && &ifmgd->associated->cbss == req->bss) {
 		bssid = req->bss->bssid;
-		ieee80211_set_disassoc(sdata);
+		ieee80211_set_disassoc(sdata, true);
 	} else list_for_each_entry(wk, &ifmgd->work_list, list) {
 		if (&wk->bss->cbss == req->bss) {
 			bssid = req->bss->bssid;

@@ -2552,7 +2565,7 @@ int ieee80211_mgd_disassoc(struct ieee80
 		return -ENOLINK;
 	}
 
-	ieee80211_set_disassoc(sdata);
+	ieee80211_set_disassoc(sdata, false);
 
 	mutex_unlock(&ifmgd->mtx);
author maintainer
#2 lore raw

PATCH 2/3 cfg80211: fix nl80211 disconnected events

In reply to Johannes Berg

When reporting a disconnection to userspace, we try to report whether it was from the AP or by our own choice. However, we misreported a broadcast deauth or disassoc as being by own choice, which is wrong. Fix this by checking the sender address instead of the destination address.

Signed-off-by Johannes Berg <[email protected]>
---
 net/wireless/mlme.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/wireless/mlme.c +2 -2
@@ -149,7 +149,7 @@ static void __cfg80211_send_deauth(struc
 
 		reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
 
-		from_ap = memcmp(mgmt->da, dev->dev_addr, ETH_ALEN) == 0;
+		from_ap = memcmp(mgmt->sa, dev->dev_addr, ETH_ALEN) != 0;
 		__cfg80211_disconnected(dev, NULL, 0, reason_code, from_ap);
 	} else if (wdev->sme_state == CFG80211_SME_CONNECTING) {
 		__cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, NULL, 0,

@@ -215,7 +215,7 @@ static void __cfg80211_send_disassoc(str
 
 	reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code);
 
-	from_ap = memcmp(mgmt->da, dev->dev_addr, ETH_ALEN) == 0;
+	from_ap = memcmp(mgmt->sa, dev->dev_addr, ETH_ALEN) != 0;
 	__cfg80211_disconnected(dev, NULL, 0, reason_code, from_ap);
 }
author maintainer
#3 lore raw

PATCH 3/3 cfg80211: fix SME association after disassociation

In reply to Johannes Berg

When an AP disassociates us, we currently go into a weird state because the SME doesn't handle authenticated but not associated well unless it's within its own state machine, it can't recover from that. However, it shouldn't need to, since we don't do any decisions in it really -- so when we get disconnected, simply deauthenticate too.

Reported-by Pavel Roskin <[email protected]>
Signed-off-by Johannes Berg <[email protected]>
---
 net/wireless/sme.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
net/wireless/sme.c +20 -0
@@ -570,10 +570,30 @@ void __cfg80211_disconnected(struct net_
 	wdev->ssid_len = 0;
 
 	if (wdev->conn) {
+		const u8 *bssid;
+		int ret;
+
 		kfree(wdev->conn->ie);
 		wdev->conn->ie = NULL;
 		kfree(wdev->conn);
 		wdev->conn = NULL;
+
+		/*
+		 * If this disconnect was due to a disassoc, we
+		 * we might still have an auth BSS around. For
+		 * the userspace SME that's currently expected,
+		 * but for the kernel SME (nl80211 CONNECT or
+		 * wireless extensions) we want to clear up all
+		 * state.
+		 */
+		for (i = 0; i < MAX_AUTH_BSSES; i++) {
+			if (!wdev->auth_bsses[i])
+				continue;
+			bssid = wdev->auth_bsses[i]->pub.bssid;
+			ret = __cfg80211_mlme_deauth(rdev, dev, bssid, NULL, 0,
+						WLAN_REASON_DEAUTH_LEAVING);
+			WARN(ret, "deauth failed: %d\n", ret);
+		}
 	}
 
 	nl80211_send_disconnected(rdev, dev, reason, ie, ie_len, from_ap);
#4 lore raw
In reply to Johannes Berg
Quoted 7 lines · Johannes Berg

Pavel reported a bug, and it was hard to fix :)

Here's the fix patchset, including another fix
for a bug I noticed while testing.

This requires Pavel's patch, of course, but applies without it in the tree too.

I'm getting a reasonable behavior in the managed mode now. Thank you!

Signature · 2 lines
Regards,
Pavel Roskin