I just received an ar-750s and on the 2.4ghz WiFi the speed will not go over 144 even tho it is set to 300mbps. I’m using the latest 3.013 firmware. Any clues?
When you say 144, do you mean doing a speed test or this is the information displayed on your device? Pls give a screenshot if it is the later one.
If this is a speed test it will be a very very high speed for 2.4G.
The router says it is set at 300, but three different devices (phone, tablet, laptop) report the connection speed as 144. Not a speed test.
Mine is even worse. The most I’m getting is 96mbps. It’s connected via wired gigabit ethernet to my network. This is on 5G
I get the 433 Mbps connection speed from the 5ghz clients, but my 2.4ghz only connects at 144… like you I am also connected to a GbE port for my internet
The short story is that if you’ve been having trouble trying to get your 11n clients to connect to your router at link rates higher than 130 Mbps (144 Mbps for some brand routers) in the 2.4 GHz band, you might not be doing anything wrong. What you may be finding is that your router is operating as designed .
Thanks for the article, interesting read, but if I use an ar-750 instead it then works as expected giving a proper link speed
I appreciate your post for allowing me to look into this further. It seems GL-iNET does force 40 MHz mode on their 2.4 GHz devices that support it.
This is a violation the IEEE 802.11n specification - and can cause slower performance due to collisions even though the link speed says a bigger number.
I have disabled it.
It’s not a spec violation by running in wide channels - it’s conditional that the secondary channel has to pass a few tests before the channel is transmitted on. The secondary channel is opportunistic and it used when it can be used, and if there’s traffic on that channel, then only the primary is used.
Back in the 802.11n Draft Days before the formal release of 802.11n - 40MHz was just 40MHz, but that was resolved a long time ago.
Keep in mind - there’s a lot of client devices out there that are 20MHz only in 2.4GHz, including just about everything Apple has ever made (deliberate choice by their engineering team)
Yes thats right. But forcing without testing for the ‘conditionals’ is a violation. which is what is being done.
It’s not forcing the mode - going wide allows the secordary to be used…
A lot of folks misunderstand how that works…
This is incorrect. Here is the patch in OpenWRT that allows it to be forced:
Setting noscan causes hostapd to not take the precautions required to follow the specification.
/etc/init.d/gl_init which is baked into the gl-inet image sets noscan=1 on their devices that have 802.11n
Thus it will not properly scan AP’s and disable it as required by the specification.
Might want to study the ath9k code…
1 Like
OpenWRT states that setting the option violates the requirements.
https://oldwiki.archive.openwrt.org/doc/uci/wireless?s[]=noscan#mac80211_device_options
|noscan|boolean|no|0|Do not scan for overlapping BSSs in HT40+/- mode.
Turning this on will violate regulatory requirements!|
| — | — | — | — |
will you report back when you know something?
Go study the driver - here’s a hint…
the ath9k-htc driver exposes more info… The ath9k-htc driver is interesting to many, as it exposes some of the firmware that isn’t exposed by the kernel ath9k - htc has a lot of firmware hints here.
Anyways - choices there are HT20 and HT20_40 - from hostapd’s perspective, ether we program the ath9k for HT20 only, or we allow HT20_40, as this is what the driver allows - there is no HT40 only.
no_scan and ht_coex in hostapd.conf actually have no bearing here, as this is all the driver and the baseband.
Getting more into the why (as I explained the how from hostapd and driver already) - only the baseband/digital PHY can make decisions in real time if the PHY is running in HT20_40 - so the baseband does the CCA for the secondary, and if conditions are met, then it uses it in an opportunistic manner.
From a client STA - program it for 20/40, as the AP makes the decision based on the association handshake, and can do an 802.11 action message if conditions change.
Back in the Kernel 2.6 days, there was a real problem with the ath - if the baseband was operating in one mode - let’s say HT40, and conditions forced a switch to HT20 and still rx’ed HT40, it would crash the baseband. But that was back before ath9k was opensourced…
Well I tested it on a very busy 2.4GHz band and it seems it does force 40 MHz
GL-iNET default:
OpenWRT default (and unpatched hostapd):
So back to the original question, why won’t it reach a connection speed higher than 144Mbps on the 2.4 band? The area I live in currently has very little WiFi so no worries of congestion, but I have tried other channels with no luck.
You see that on the SSID scanner app as it parses the beacon frame - when in HT20_HT40, the beacon will reflect the wide channel in the htcaps stanza (which is appropriate). Some AP’s will dynamically update the beacon frame if conditions are not good enough for 40MHz channels (I’ve seen this with Marvell closed source drivers on the WRT products)
To really tell, one has to use a spectrum analyzer where you can see both the primary channel, along with the secondary when conditions allow traffic to be sent on the secondary.
Again, there’s a lot of confusion about wide channels, and it’s wide spread (pardon the pun) - there’s more than a few threads on the OpenWRT forums that discuss this very thing.
What is the client device?