Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jun 2012 07:27:20 GMT
From:      Adrian Chadd <adrian@FreeBSD.org>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/169432: [ath] BAR TX hang when aggregation session is reset during a reassociation
Message-ID:  <201206260727.q5Q7RKZm044027@red.freebsd.org>
Resent-Message-ID: <201206260730.q5Q7UDLp022580@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         169432
>Category:       kern
>Synopsis:       [ath] BAR TX hang when aggregation session is reset during a reassociation
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 26 07:30:13 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Adrian Chadd
>Release:        9.0-STABLE with -HEAD net80211/ath
>Organization:
>Environment:
>Description:
When doing some iperf testing from a FreeBSD 802.11n station -> FreeBSD 802.11n AP, I noticed the AP would get wedged. When I flushed the interface, the STA node was showing as 'BAR wait' - ie, it was paused due to a pending BAR TX.

Enabling "wlandebug +11n" showed that the AP would start sending BAR frames and would get about 20 or 30 of them in (with failed retries), then stop sending them. The hardware was reporting a TX failure, but something was disabling it.

After much printf debugging on the AP, I finally figured it out.

Here's what was going on.

* The STA was going deaf, so all TX to it was failing;
* The AP would start sending BAR TX frames;
* The STA would hit a beacon miss and rescan, and reassociate to the AP;
* The reassociation request was going via ieee80211_ht_node_init();
* .. and that called ieee80211_ht_node_cleanup() to reset the existing state;
* .. which reset the TX/RX aggregation state, stopped the timer.

. and unfortunately, my ath_addba_stop() routine wasn't undoing a BAR suspended pause.

>How-To-Repeat:

>Fix:
The fix is to check if the node is currently undergoing bar_wait and if so, unpause it.

The trick however is handling the tiny race condition where this occurs between the bar TX being in flight and having completed TX.

>Release-Note:
>Audit-Trail:
>Unformatted:



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