Date: Wed, 27 Feb 2008 21:24:40 GMT From: Sam Leffler <sam@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 136369 for review Message-ID: <200802272124.m1RLOe9g029403@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=136369 Change 136369 by sam@sam_ebb on 2008/02/27 21:24:02 add a workaround for passive scan channels; still need to investigate what the linux code does but attempts to get the intel linux driver to associate to my 11a ap's have all failed (likely pilot error) Affected files ... .. //depot/projects/vap/sys/dev/iwn/if_iwn.c#4 edit Differences ... ==== //depot/projects/vap/sys/dev/iwn/if_iwn.c#4 (text+kox) ==== @@ -1631,8 +1631,28 @@ m = data->m, data->m = NULL; ni = data->ni, data->ni = NULL; - if (m->m_flags & M_TXCB) - ieee80211_process_callback(ni, m, (status & 0x80) != 0); + if (m->m_flags & M_TXCB) { + /* + * Channels marked for "radar" require traffic to be received + * to unlock before we can transmit. Until traffic is seen + * any attempt to transmit is returned immediately with status + * set to IWN_TX_FAIL_TX_LOCKED. Unfortunately this can easily + * happen on first authenticate after scanning. To workaround + * this we ignore a failure of this sort in AUTH state so the + * 802.11 layer will fall back to using a timeout to wait for + * the AUTH reply. This allows the firmware time to see + * traffic so a subsequent retry of AUTH succeeds. It's + * unclear why the firmware does not maintain state for + * channels recently visited as this would allow immediate + * use of the channel after a scan (where we see traffic). + */ + if (status == IWN_TX_FAIL_TX_LOCKED && + ni->ni_vap->iv_state == IEEE80211_S_AUTH) + ieee80211_process_callback(ni, m, 0); + else + ieee80211_process_callback(ni, m, + (status & IWN_TX_FAIL) != 0); + } m_freem(m); ieee80211_free_node(ni);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802272124.m1RLOe9g029403>