summaryrefslogtreecommitdiffstats
path: root/contrib/netbsd-tests/lib/libc
diff options
context:
space:
mode:
authoradrian <adrian@FreeBSD.org>2015-02-27 04:45:47 +0000
committeradrian <adrian@FreeBSD.org>2015-02-27 04:45:47 +0000
commitd43da4a89cf3d17d8d8715de15eec4feb8a0ac1a (patch)
tree26eb658799972f6ebf3ddce59c8a609d6cab51f0 /contrib/netbsd-tests/lib/libc
parentace438b760037d15dc1c3afa90ad9c330a85647a (diff)
downloadFreeBSD-src-d43da4a89cf3d17d8d8715de15eec4feb8a0ac1a.zip
FreeBSD-src-d43da4a89cf3d17d8d8715de15eec4feb8a0ac1a.tar.gz
Fix kern/196290 - don't announce 11n HTINFO rates if the channel is
configured as 11b. This came up when debugging other issues surrounding scanning and channel modes. What's going on: * The VAP comes up as an 11b VAP, but on an 11n capable NIC; * .. it announces HTINFO and MCS rates; * The AP thinks it's an 11n capable device and transmits 11n frames to the STA; * But the STA is in 11b mode, and thus doesn't receive/ACK the frames. It didn't happen for the ath(4) devices as the AR5416/AR9300 HALs unconditionally enable MCS frame reception, even if the channel mode is not 11n. But the Intel NICs are configured in 11b/11a/11g modes when doing those, even if 11n is enabled and available. So, don't announce 11n capabilities if the VAP isn't on an 11n channel when sending management assocation request / reassociation request frames. TODO: * Lots more testing - 11n should be "upgraded" after association, and I just want to make sure I haven't broken 11n upgrade. I shouldn't have - this is only happening for /sending/ association requests, which APs aren't doing. Tested: * ath(4) APs (AR9331, AR7161+AR9280, AR934x) * AR5416, STA mode * Intel 5100, STA mode PR: kern/196290
Diffstat (limited to 'contrib/netbsd-tests/lib/libc')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud