summaryrefslogtreecommitdiffstats
path: root/sys/net/if_ethersubr.c
diff options
context:
space:
mode:
authorstsp <stsp@openbsd.org>2016-05-18 08:15:28 +0000
committerstsp <stsp@openbsd.org>2016-05-18 08:15:28 +0000
commit6371114138ff58a289b8ce48b7d1a66e7876d165 (patch)
treebde77dd2da3886bdcd04a20cb49f606970f1335c /sys/net/if_ethersubr.c
parentMove the code to update an ARP cache into its own function. (diff)
downloadwireguard-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