>Number: 172338 >Category: misc >Synopsis: [ath] [net80211] CCMP IV transmit counters are not correctly >protected by a lock >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: Thu Oct 04 22:20:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: -HEAD >Organization: >Environment: -HEAD! >Description: The driver is responsible for calling ieee80211_crypto_encap() as part of the 802.11 packet assembly and transmission. And for each node there's an RX CCMP counter for each TID but a single TX CCMP counter for all TIDs.
Neither of these are protected by any locks. (Same as TX/RX sequence numbers, but they're per-TID..) The ath(4) driver doesn't currently implement a global per-node lock to protect the whole TX path for each node. The -9 and previous driver uses no lock; the -HEAD driver uses a per-TID "lock" (which is actually the hardware queue lock that backs the TID. But still, there's a "per-TID lock".) This works fine for serialising things such as sequence number allocation but since there is one TX CCMP sequence number space, there's no locking there and no guarantee things will remain in order. Sigh. >How-To-Repeat: Lots of concurrent TX traffic in a WPA2+CCMP session, over multiple TIDs. >Fix: I honestly think at this point the solution should be "replace the per-TID lock with a per-node lock, and that will serialise the CCMP number allocation." Since sequence numbers get allocated by the stack _before_ they get handed to the driver (except for aggregation, but I digress), there's still a problem there. It's quite likely that the correct behaviour here should be either "net80211 ensures that there's only one TX path active for a driver at one time", or "the actual frame setup is pushed back into the driver and it's up to the driver to implement correct locking." >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]"
