diff options
| author | 2016-05-18 08:15:28 +0000 | |
|---|---|---|
| committer | 2016-05-18 08:15:28 +0000 | |
| commit | 6371114138ff58a289b8ce48b7d1a66e7876d165 (patch) | |
| tree | bde77dd2da3886bdcd04a20cb49f606970f1335c /sys/net/if_ethersubr.c | |
| parent | Move the code to update an ARP cache into its own function. (diff) | |
| download | wireguard-openbsd-6371114138ff58a289b8ce48b7d1a66e7876d165.tar.xz wireguard-openbsd-6371114138ff58a289b8ce48b7d1a66e7876d165.zip | |
In hostap mode, don't re-use association IDs (AIDs) of nodes which are
still lingering in the node cache. This could cause an AID to be assigned
twice, once to a newly associated node and once to a different node in
COLLECT cache state (i.e. marked for future eviction from the node cache).
Drivers (e.g. rt2860) may use AIDs to keep track of nodes in firmware
tables and get confused when AIDs aren't unique across the node cache.
The symptom observed with rt2860 were nodes stuck at 1 Mbps Tx rate since
the duplicate AID made the driver perform Tx rate (AMRR) accounting on
the wrong node object.
To find out if a node is associated we now check the node's cache state,
rather than comparing the node's AID against zero. An AID is assigned when
a node associates and it lasts until the node is eventually purged from the
node cache (previously, the AID was made available for re-use when the node
was placed in COLLECT state). There is no need to be stingy with AIDs since
the number of possible AIDs exceeds the maximum number of nodes in the cache.
Problem found by Nathanael Rensen.
Fix written by Nathanael and myself. Tested by Nathanael.
Comitting now to get this change tested across as many drivers as possible.
Diffstat (limited to 'sys/net/if_ethersubr.c')
0 files changed, 0 insertions, 0 deletions
