diff options
author | adrian <adrian@FreeBSD.org> | 2015-02-27 04:45:47 +0000 |
---|---|---|
committer | adrian <adrian@FreeBSD.org> | 2015-02-27 04:45:47 +0000 |
commit | d43da4a89cf3d17d8d8715de15eec4feb8a0ac1a (patch) | |
tree | 26eb658799972f6ebf3ddce59c8a609d6cab51f0 /contrib/netbsd-tests/lib/libc | |
parent | ace438b760037d15dc1c3afa90ad9c330a85647a (diff) | |
download | FreeBSD-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