>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: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
