[OpenWrt-Devel,package] mwlwifi: generate TX_STATUS event on transmitting auth, associate, and reallocate responses

This patch addresses an issue specific to Apple devices experiencing a wireless disconnect when trying to associate with either 2.4Ghz or 5Ghz wifi of a Linksys WRT1900AC router.
Apple devices (MacBooks running Mac OS X 10.10.x Yosemite in particular, but there may be others), appear to re-auth/re-associate within approximately 25 seconds of initially associating.
Evidence of this can be seen by the presence of an entry similar to the following in the Apple system logs;
	MM/DD/YY HH:MM:SS.sss AM kernel[0]: wl0: Roamed or switched channel, reason #8, bssid xx:xx:xx:xx:xx:xx
The Marvell wifi driver doesn’t generate a NL80211_CMD_FRAME_TX_STATUS event on transmitting a response to auth and/or reassociate requests.  Thus, the respective callback handler functions (in hostapd’s ieee802_11.c) never get driven, ultimately leading to the problem.
The patch causes a TX_STATUS event to be generated for auth and reassociate request’s responses, in addition to associate request’s responses.

Signed-off-by: Pat Fruth <pat@patfruth.comt>
---
 .../mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch

On Wed, 2015-03-18 at 21:40 -0600, Pat Fruth wrote:
> This patch addresses an issue specific to Apple devices experiencing a wireless disconnect when trying to associate with either 2.4Ghz or 5Ghz wifi of a Linksys WRT1900AC router.
> Apple devices (MacBooks running Mac OS X 10.10.x Yosemite in particular, but there may be others), appear to re-auth/re-associate within approximately 25 seconds of initially associating.
> Evidence of this can be seen by the presence of an entry similar to the following in the Apple system logs;
> 	MM/DD/YY HH:MM:SS.sss AM kernel[0]: wl0: Roamed or switched channel, reason #8, bssid xx:xx:xx:xx:xx:xx
> The Marvell wifi driver doesn’t generate a NL80211_CMD_FRAME_TX_STATUS event on transmitting a response to auth and/or reassociate requests.  Thus, the respective callback handler functions (in hostapd’s ieee802_11.c) never get driven, ultimately leading to the problem.
> The patch causes a TX_STATUS event to be generated for auth and reassociate request’s responses, in addition to associate request’s responses.
> 
> Signed-off-by: Pat Fruth <pat@patfruth.comt>
> ---
>  .../mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch   | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>  create mode 100644 package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> 
> diff --git a/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> new file mode 100644
> index 0000000..5f0d7fb
> --- /dev/null
> +++ b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> @@ -0,0 +1,14 @@
> +--- a/mwl_tx.c
> ++++ b/mwl_tx.c
> +@@ -395,7 +395,10 @@ void mwl_tx_done(unsigned long data)
> + 
> + 				tr = (struct mwl_dma_data *)done_skb->data;
> + 
> +-				if (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> ++				// if (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> ++				if (ieee80211_is_assoc_resp(tr->wh.frame_control) ||
> ++				    ieee80211_is_reassoc_resp(tr->wh.frame_control) ||
> ++				    ieee80211_is_auth(tr->wh.frame_control)) {
> + 
> + 					/* Remove H/W dma header
> + 					*/

I don't think there's anything to be gained by commenting out the
original line. It only adds extra noise and the change that's been made
is evident from the log.

Ian

On Thu, 2015-03-19 at 12:05 +0800, Ian Kent wrote:
> On Wed, 2015-03-18 at 21:40 -0600, Pat Fruth wrote:
> > This patch addresses an issue specific to Apple devices experiencing a wireless disconnect when trying to associate with either 2.4Ghz or 5Ghz wifi of a Linksys WRT1900AC router.
> > Apple devices (MacBooks running Mac OS X 10.10.x Yosemite in particular, but there may be others), appear to re-auth/re-associate within approximately 25 seconds of initially associating.
> > Evidence of this can be seen by the presence of an entry similar to the following in the Apple system logs;
> > 	MM/DD/YY HH:MM:SS.sss AM kernel[0]: wl0: Roamed or switched channel, reason #8, bssid xx:xx:xx:xx:xx:xx
> > The Marvell wifi driver doesn’t generate a NL80211_CMD_FRAME_TX_STATUS event on transmitting a response to auth and/or reassociate requests.  Thus, the respective callback handler functions (in hostapd’s ieee802_11.c) never get driven, ultimately leading to the problem.
> > The patch causes a TX_STATUS event to be generated for auth and reassociate request’s responses, in addition to associate request’s responses.
> > 
> > Signed-off-by: Pat Fruth <pat@patfruth.comt>
> > ---
> >  .../mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch   | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >  create mode 100644 package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> > 
> > diff --git a/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> > new file mode 100644
> > index 0000000..5f0d7fb
> > --- /dev/null
> > +++ b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> > @@ -0,0 +1,14 @@
> > +--- a/mwl_tx.c
> > ++++ b/mwl_tx.c
> > +@@ -395,7 +395,10 @@ void mwl_tx_done(unsigned long data)
> > + 
> > + 				tr = (struct mwl_dma_data *)done_skb->data;
> > + 
> > +-				if (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> > ++				// if (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> > ++				if (ieee80211_is_assoc_resp(tr->wh.frame_control) ||
> > ++				    ieee80211_is_reassoc_resp(tr->wh.frame_control) ||
> > ++				    ieee80211_is_auth(tr->wh.frame_control)) {
> > + 
> > + 					/* Remove H/W dma header
> > + 					*/
> 
> I don't think there's anything to be gained by commenting out the
> original line. It only adds extra noise and the change that's been made
> is evident from the log.

On a different note this might resolve a problem I have that makes the
WRT1900AC unusable in my situation.

I use a number of different routers as media bridges and some of them
will work for a while and then I find they aren't connected. That could
be an example of the re-associate problem here.

Not sure when I'll be able to test this as it involves time I don't have
and putting the WRT1900AC in as my main router which has proven to be
disruptive, but I will get to it.

> 
> Ian