Enables some HT (802.11n) capabilities in the run driver.
Also make a change to net80211 to send HT IEs in probe requests.
The changes are protected by an #ifdef #endif to not interfere with others' work.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
From @kevlo : this is not enough for letting run(4) to support 802.11n, the RX/TX paths also need to be modified to handle HT.
Comment Actions
@adrian had recommended the #ifdef approach taken here to start incrementally adding 11n bits as lrx works out the rest of the details
Comment Actions
@kevans thanks for the clarification, and @lrx337_gmail.com please keep on the good work.
Comment Actions
Exactly produce probe requests as rt2x00.
All the A-MPDU and RX MCS bitsets are now the same as what is advertised by rt2x00.
These changes, however, result in a kernel panic.
Needs further investigation.
Comment Actions
Changes in ieee80211_output.c
This was required in order to add an htcap IE to the probe requests being sent out. The existing code only seemed to do
that when operating in adhoc mode and so I added a similar block of code for STA mode. I believe this cannot be done in
the driver and must be done in the net80211 code.
Changes in ieee80211_ht.c
The changes relate to generating the "Rx Supported Modulation and Coding Scheme Set: MCS Set" part of the frame (as reported
by wireshark). I'm not sure if only comparing the number of rx and tx streams is enough for concluding the values of all 4 fields.
TX Supported MCS Set: Shouldn't this be inferred from HTCAP_XXX capabilities?
Tx and Rx MCS Set Equal: Is comparing number of rx/tx streams sufficient to conclude this?
Maximum number of tx spatial streams supported: Only useful when not equal to number of rx streams
Unequal modulation: Don't understand why the if block does a bitwise OR with 0x16 when all four of these need to be packed in
a byte and according to wireshark the Unequal modulation bit belongs exclusively to the left nibble.
Comment Actions
Get 802.11n frames on the wire.
The MCS Index in the transmission is still 0 for everything we send out, that should be improved. Other bits in the txwi could be tweaker similar to rt2x00 but perhaps right now is a good time to look at the rx path to "learn" from incoming packets and operate at a higher rate. Not exactly clear why run operates at a low rate index.
Comment Actions
First 802.11n frames on the wire.
MCS Index is still 0, and its unclear why the run driver wants to operate at lower rates even when the device seems more capable.
Comment Actions
Add MCS rates to run's rate table, print out tx descriptor and decide which PHY to use based on the rate / ridx instead of channel being HT20.
| sys/dev/usb/wlan/if_run.c | ||
|---|---|---|
| 6440 ↗ | (On Diff #72265) | i'm honestly surprised it's not logging an amrr error. Let's figure that out too.. |
| sys/net80211/ieee80211_ht.c | ||
| 2996 ↗ | (On Diff #72265) | so almost noone needs to worry or implement TXMCS32, so we can mostly ignore it. :-) The stream comparison should be done during HT negotiation so the right number of MCS rates is used. |
| sys/net80211/ieee80211_output.c | ||
| 2418 ↗ | (On Diff #72265) | Yeah, I need to figure out what to do here, cause in theory they should've been added by now.. |
Comment Actions
Add MCS table from datasheet. RX AMPDU works now (verified with a wireshark monitor).
Comment Actions
Add tx_ampdu_enable for run (function returns 0 for now meaning that no tx ampdu support in driver). Disable MCS32 RX/TX bits.