[PATCH v2] mac80211: STA reassociation improvements

[PATCH v2] mac80211: STA reassociation improvements

[Daniel Drake]

My cheapy D-Link AP behaves strangely w.r.t reassociations.

The following sequence of commands causes me to lose association and to be
unable to regain it:

	ifconfig eth8 down
	ifconfig eth8 up
	iwconfig eth8 essid <x>

This is because mac80211 tries to reassociate, rather than just associate.
My AP replies with an association response (not a reassociation response...)
denying the association with code 12: "Association denied due to reason
outside the scope of this standard"

mac80211 tries this reassociation another 4 times or so before finally giving
up.

I see 2 problems here:
 1. bringing the interface down and up again should be resetting interface state
    i.e. after the interface is brought down, it should have no memory of if or
         where it was previously associated
 2. after the first reassociation fails, mac80211 should fall back to
    standard association for the next attempt

Signed-off-by: Daniel Drake <dsd@gentoo.org>

---
Changes since first submission: created ieee80211_if_open and moved state
resetting to there, and clarified reasoning for retrying with a full
association as requested by Jiri Benc.

Index: wireless-dev/net/mac80211/ieee80211.c
===================================================================
--- wireless-dev.orig/net/mac80211/ieee80211.c
+++ wireless-dev/net/mac80211/ieee80211.c
@@ -2277,6 +2277,18 @@ static struct net_device_stats *ieee8021
 	return &(sdata->stats);
 }
 
+static void ieee80211_if_open(struct net_device *dev)
+{
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+
+	switch (sdata->type) {
+	case IEEE80211_IF_TYPE_STA:
+	case IEEE80211_IF_TYPE_IBSS:
+		sdata->u.sta.prev_bssid_set = 0;
+		break;
+	}
+}
+
 static void ieee80211_if_shutdown(struct net_device *dev)
 {
 	struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
@@ -2426,6 +2438,7 @@ static int ieee80211_open(struct net_dev
 		local->hw.conf.flags |= IEEE80211_CONF_RADIOTAP;
 		return 0;
 	}
+	ieee80211_if_open(dev);
 	ieee80211_start_soft_monitor(local);
 
 	if (local->ops->add_interface) {
Index: wireless-dev/net/mac80211/ieee80211_sta.c
===================================================================
--- wireless-dev.orig/net/mac80211/ieee80211_sta.c
+++ wireless-dev/net/mac80211/ieee80211_sta.c
@@ -1605,8 +1605,10 @@ static void ieee80211_rx_mgmt_assoc_resp
 	if (status_code != WLAN_STATUS_SUCCESS) {
 		printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
 		       dev->name, status_code);
-		if (status_code == WLAN_STATUS_REASSOC_NO_ASSOC)
-			ifsta->prev_bssid_set = 0;
+		/* if this was a reassociation, ensure we try a "full"
+		 * association next time. This works around some broken APs
+		 * which do not correctly reject reassociation requests. */
+		ifsta->prev_bssid_set = 0;
 		return;
 	}
 

Re: [PATCH v2] mac80211: STA reassociation improvements

[Jiri Benc]

[removed netdev, no reason for sending this there]

On Sun, 15 Jul 2007 15:02:51 +0100 (BST), Daniel Drake wrote:
> My cheapy D-Link AP behaves strangely w.r.t reassociations.
> 
> The following sequence of commands causes me to lose association and to be
> unable to regain it:
> 
> 	ifconfig eth8 down
> 	ifconfig eth8 up
> 	iwconfig eth8 essid <x>
> 
> This is because mac80211 tries to reassociate, rather than just associate.
> My AP replies with an association response (not a reassociation response...)
> denying the association with code 12: "Association denied due to reason
> outside the scope of this standard"
> 
> mac80211 tries this reassociation another 4 times or so before finally giving
> up.
> 
> I see 2 problems here:
>  1. bringing the interface down and up again should be resetting interface state
>     i.e. after the interface is brought down, it should have no memory of if or
>          where it was previously associated
>  2. after the first reassociation fails, mac80211 should fall back to
>     standard association for the next attempt
> 
> Signed-off-by: Daniel Drake <dsd@gentoo.org>

Acked-by: Jiri Benc <jbenc@suse.cz>


-- 
Jiri Benc
SUSE Labs

Re: [PATCH v2] mac80211: STA reassociation improvements

[Daniel Drake]

Jiri Benc wrote:
> [removed netdev, no reason for sending this there]

Was I wrong for sending the patch there, or was it just your ACK that 
you didn't think would be relevant on netdev?

Re: [PATCH v2] mac80211: STA reassociation improvements

[Jiri Benc]

On Mon, 16 Jul 2007 22:15:32 -0400, Daniel Drake wrote:
> Jiri Benc wrote:
> > [removed netdev, no reason for sending this there]
> 
> Was I wrong for sending the patch there, or was it just your ACK that 
> you didn't think would be relevant on netdev?

linux-wireless mailinglist was created to lower traffic at netdev. I
understand that in the way that wireless patches should be sent to
linux-wireless only; they will be sent to nedev by John when he's asking
for a pull. But I'm not sure about that (Cc:ing John), my comment was more
about my ack.

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: [PATCH v2] mac80211: STA reassociation improvements

[John W. Linville]

On Tue, Jul 17, 2007 at 11:38:38AM +0200, Jiri Benc wrote:
> On Mon, 16 Jul 2007 22:15:32 -0400, Daniel Drake wrote:
> > Jiri Benc wrote:
> > > [removed netdev, no reason for sending this there]
> > 
> > Was I wrong for sending the patch there, or was it just your ACK that 
> > you didn't think would be relevant on netdev?
> 
> linux-wireless mailinglist was created to lower traffic at netdev. I
> understand that in the way that wireless patches should be sent to
> linux-wireless only; they will be sent to nedev by John when he's asking
> for a pull. But I'm not sure about that (Cc:ing John), my comment was more
> about my ack.

I think linux-wireless is sufficient, especially for small and/or
isolated patches.  But there is no real harm in including netdev,
especially for patches with broader impact.  For example, if Zhu Yi
and PJ had chosen to push the multiqueue stuff on wireless first then
it would certainly have been appropriate to copy netdev.  I guess
it is just a judgment call -- if your patch merits broader review,
then copy netdev as well.

Hth!  (I doubt if it does!)

John
-- 
John W. Linville
linville@tuxdriver.com