Bug 172338 - [ath] [net80211] CCMP IV transmit counters are not correctly protected by a lock
Summary: [ath] [net80211] CCMP IV transmit counters are not correctly protected by a lock
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-04 23:20 UTC by Adrian Chadd
Modified: 2018-05-28 19:47 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer 2012-10-04 23:20:09 UTC
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.

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."
How-To-Repeat: Lots of concurrent TX traffic in a WPA2+CCMP session, over multiple TIDs.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2012-10-05 01:59:41 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:59 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.