I'm hopeful for a dialog on DRS for community knowledge and my own selfish reasons. Though I am not hopeful to troubleshoot this specific problem in this thread - it is illustrative of an example to use for the dicusssion.
Ok - I have an Atheros client device running Windows and the latest possible driver. But it is an old device and supports only 802.11n 2.4Ghz.
Access point 'A' = some none-wrt AP
Access point 'B' = Openwrt AP
Winodws Reports = netsh wlan show interfaces
When connected to access point 'A' Windows reports 100% signal strength and 144Mbps Tx/Rx rate.
Shut down access point 'A' and turn on access point 'B'
When connected to access point 'B' Windows reports 100% signal strength and 72.2Mbps.
Now knowing the client side DRS algo is proprietary - it isn't clear to me why it wouldn't make the same decision on either AP. Also not clear to me where to look inside a wireless monitor capture to see the DRS negotiation. Anyone have deep insights they would like to share.
Are both access points the same hardware and only the software differs? The difference between 72 and 144mbps is either going to be NSS or 20/40 channel width.
The first comparison hardware wise is to check they’re using the same number of antennas.
Then a wifi spectrum check with a phone app to ensure widths are the same.
NSS doesn't affect the rate control algorithm, and that's the only thing displayed there (not the effective throughput). Apart from that, the hardware in question seems to be 802.11n to begin with (for which there is no NSS anyways), which strongly hints at HT20 vs HT40.
Interesting - I was under the impression that 144 was achievalbe under HT20. @slh are you saying that is not the case or that likely the client in this case need HT40 to achieve 144? Thanks!
Well coming back on this one. I can answer my own question. In this specific scenerio there are other clients on the Openwrt 2.4 that are running 144.4 in HT20 so ....... that is interesting.
@lantis1008 They are not both the same hardware. In this case I don't even know which Comcast modem is in use but I can find out.
I had noticed reading different things around that Short GI is required to hit 144. But it appears in this case Short GI is active.
Well I just learned something about the practical application of my knowledge. @slh nailed it with HT40.
I couldn't find specs on the "older" client card to tell me anything but it seems to likely be single stream capable.
So there were clients connecting to HT20 @144.4 but those must be 2 spacial stream devices.
Although it still seems odd to me that in my test case the "old" client reported 144.4Mbps to the non-openwrt WiFi as 144.4 is clearly an MCS 15 (2 spacial stream) HT20 rate. But switching the openwrt wifi device to HT40 caused the "old" client to connect at 40Mhz MCS7 or 150Mbps.
Given the 144.4 rate on the non-Openwrt WiFi device I am still not sure this is strictly an HT20/HT40 issue unless we're also dealing with a windows reporting issue on the rate side. I haven't been able to gather the netsh wlan show interfaces from after my changes. But Openwrt definitely shows that "old" client connected at 150Mpbs (MCS7 HT40) now.
NSS offloading has been introduced with ipq8064, went from there into ipq8065, ipq807x, ipq60xx and ipq50xx. The former of those two are 802.11ac, the later 802.11ax.
The various ath79 SOCs never had NSS cores (well, they are single core to begin with), some of the switch chips (ar8337n) might have had hardware NAT (no firmware required), but that's quite different from NSS (NSS firmware required).
We can argue that the 2.4 GHz radios didn't change much between 802.11n and 802.11ac (they did for 802.11ax), but that would be different topic.
NSS = Number of Spatial Streams
You've gone on a bit of a tangent there. I understand how the mistake happened but they're pretty unrelated.
And to be fair, i don't think it was referred to as NSS until VHT, but i think the concept (and acronym) carry across just fine.
Something is still amiss in my head beacause of this:
feel I am looking for a magical switch=Some capabilities advertisement in the radio0 settings that will "fix"=allow them to consider the HT20 144.4 rate for these older clients. Or at least that I can find a clue in the RF capture somewhere. There are SO many fields in the radiotap I just get confused looking at them
Of course if could be something in the standards for .11n that the chipset isn't capable of doing which, in turn means that there is no switch to flip. I am not deeply familiar with the standards.
We can try to inspect what the openwrt device is capable of.
iw phy0 info (and phy1 if you have a dual band device) I think will show the MCS sets it supports.
Otherwise examine some of the beacons if you have those captured which will contain the MCS info.
Not sure this will be simple to get to the bottom of.
What is the openwrt device by the way?
@lantis1008 - thanks the device is the Belkin E8450. But I have seen the same result on the Netgear WAX202. So ....I'm thinking something along the lines of the .11ac chip-sets aren't doing something that the legacy .11n chip-sets were doing.
First remember I am not specifically caring to "solve" this problem per se' ....I'm just forcing a theoretical gain of knowledge for myself ...and the community that reads all of this. I don't actually have access to the specific WiFi device that the client used to connect at the HT20 144.4 rate.
I have learned a couple new things though. The modem/WiFi gateway that did allow this particular client to connect at the HT20 144.4 rate was a Cisco DPC3839 and it appears to have only supported .11b/g/n stuff. The client is Qualcomm Atheros AR956x Wireless Network Adapter.
Here is the output from the OpenWrt device.
Wiphy wl0
wiphy index: 0
max # scan SSIDs: 4
max scan IEs length: 2304 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0xf RX 0xf
Configured Antennas: TX 0xf RX 0xf
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 1:
Capabilities: 0x1ff
RX LDPC
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-31
Frequencies:
* 2412 MHz [1] (28.0 dBm)
* 2417 MHz [2] (28.0 dBm)
* 2422 MHz [3] (28.0 dBm)
* 2427 MHz [4] (28.0 dBm)
* 2432 MHz [5] (28.0 dBm)
* 2437 MHz [6] (28.0 dBm)
* 2442 MHz [7] (28.0 dBm)
* 2447 MHz [8] (28.0 dBm)
* 2452 MHz [9] (28.0 dBm)
* 2457 MHz [10] (28.0 dBm)
* 2462 MHz [11] (28.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 16,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: 0
max scan plan iterations: 0
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
I know this theorectical discussion it boring for some - I'm going to go try and sift through some standards docs today and see what I can find. My gut is that someone out there knows exactly what is different already.
I'm also going to acquire both pieces of hardware (if I can) and see if I can create a lab here. Just can't stand not knowing exactly what is the cause.
Remember also that modern adapters (say my samsung phone) will connect at 144.4 HT20 rate to the OpenWrt device. So it seems truly related to legacy .11n only adapters. Thanks for the discussion!
