Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Sep 2014 17:32:37 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-wireless@FreeBSD.org
Subject:   [Bug 193569] New: [iwn] [wpi] 5GHz association fails on passive channels
Message-ID:  <bug-193569-21060@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193569

            Bug ID: 193569
           Summary: [iwn] [wpi] 5GHz association fails on passive channels
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Only Me
          Priority: ---
         Component: wireless
          Assignee: freebsd-wireless@FreeBSD.org
          Reporter: adrian@freebsd.org

The TL;DR is this:

* 5GHz passive channels require the station to hear a beacon from an AP doing
DFS before it transmits anything;
* so net80211 does this;
* then it tries to associate;
* .. and iwn/wpi will just issue a new RXON to associate, clearing the firmware
state
* which includes that it's seen beacons;
* so then it transmits a frame (association request);
* and the firmware immediately fails it with some status code (IWN_TX_*) that
says "nope, need to see a beacon first."

I forget the status code but it's pretty easy to see with 'sysctl
dev.iwn.0.debug=0x1' when associating on a 5GHz channel.

What the linux iwlwifi driver does - and what I think we should do - is this:

* have a per-vap buffer of temporarily failed frames;
* (not per-node; it's not required for this NIC);
* if we see a TX fail for this reason, don't free the mbuf - just append it to
the vap retry queue - and set some flag + channel number;
* upon receiving a beacon notification - if it's for a beacon on the currently
associated channel then schedule a taskqueue to flush that queue;
* .. then flush this queue as appropriate in iwn_newstate().
* .. and make sure the taskqueue is cancelled during state changes,
suspend/resume, etc.

the flush may get complicated - we should flush it if we transition away from
RUN. Just make sure it works. :)

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193569-21060>