Ar-750S 2.4GHz WiFi speed

Exile1975 · 2019-02-08T13:44:50.558Z

Thanks for the article, interesting read, but if I use an ar-750 instead it then works as expected giving a proper link speed

nopro404 · 2019-02-08T17:43:08.568Z

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.

sfx2000 · 2019-02-08T19:49:16.965Z

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)

nopro404 · 2019-02-08T19:52:46.365Z

sfx2000:

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

Yes thats right. But forcing without testing for the ‘conditionals’ is a violation. which is what is being done.

sfx2000 · 2019-02-08T19:53:47.546Z

nopro404:

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…

nopro404 · 2019-02-08T20:10:23.336Z

sfx2000:

It’s not forcing the mode - going wide allows the secordary to be used…

This is incorrect. Here is the patch in OpenWRT that allows it to be forced:

github.com

openwrt/openwrt/blob/99956528dfc703043ce927797ecd9af1032a180a/package/network/services/hostapd/patches/300-noscan.patch

--- a/hostapd/config_file.c
+++ b/hostapd/config_file.c
@@ -3317,6 +3317,10 @@ static int hostapd_config_fill(struct ho
 		}
 #endif /* CONFIG_IEEE80211W */
 #ifdef CONFIG_IEEE80211N
+	} else if (os_strcmp(buf, "noscan") == 0) {
+		conf->noscan = atoi(pos);
+	} else if (os_strcmp(buf, "ht_coex") == 0) {
+		conf->no_ht_coex = !atoi(pos);
 	} else if (os_strcmp(buf, "ieee80211n") == 0) {
 		conf->ieee80211n = atoi(pos);
 	} else if (os_strcmp(buf, "ht_capab") == 0) {
--- a/src/ap/ap_config.h
+++ b/src/ap/ap_config.h
@@ -781,6 +781,8 @@ struct hostapd_config {
 
 	int ht_op_mode_fixed;
 	u16 ht_capab;
+	int noscan;

This file has been truncated. show original

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.

sfx2000 · 2019-02-08T22:18:29.153Z

nopro404:

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…

nopro404 · 2019-02-09T06:42:06.516Z

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!|
| — | — | — | — |

nopro404 · 2019-02-09T18:25:53.455Z

sfx2000:

Might want to study the ath9k code…

will you report back when you know something?

sfx2000 · 2019-02-10T00:32:44.555Z

nopro404:

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.

github.com

qca/open-ath9k-htc-firmware/blob/master/target_firmware/wlan/ieee80211.h

/*-
 * Copyright (c) 2001 Atsushi Onoe
 * Copyright (c) 2002-2005 Sam Leffler, Errno Consulting
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 *    derived from this software without specific prior written permission.
 *
 * Alternatively, this software may be distributed under the terms of the
 * GNU General Public License ("GPL") version 2 as published by the Free
 * Software Foundation.
 *

This file has been truncated. show original

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…

nopro404 · 2019-02-10T08:57:06.466Z

Well I tested it on a very busy 2.4GHz band and it seems it does force 40 MHz

GL-iNET default:

Screenshot_20190210-163056_WiFiAnalyzer-40562×999 55.9 KB

OpenWRT default (and unpatched hostapd):

Screenshot_20190210-163211_WiFiAnalyzer562×998 56.8 KB

Exile1975 · 2019-02-10T17:54:14.401Z

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.

sfx2000 · 2019-02-10T19:29:08.157Z

nopro404:

Well I tested it on a very busy 2.4GHz band and it seems it does force 40 MHz

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.

sfx2000 · 2019-02-10T19:29:38.354Z

Exile1975:

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

What is the client device?

Exile1975 · 2019-02-10T19:57:24.242Z

I’ve got a Nexus 5x, Galaxy tab s3, and an Acer laptop.

sfx2000 · 2019-02-11T00:42:26.969Z

The Nexus 5x and Galaxy Tab S3 - the wifi chips support HT40, however, it depends on the driver supplied by Android and/or the Vendor (LG/Samsung) to enable HT40 mode - two things that can impact - they might configure the WiFi chipset to 20MHz only, and they might set the 40MHz Intolerant Bit (this is how Apple devices can trigger an HT40 device to HT20 only)

WIth the Acer Laptop - they use many different vendors across their laptop line, so it would help to identify the Wireless Adapter (Vendor/Model - for example “Intel 3165”)

In any event, the adjacent networks in a busy area just might preclude wide channel operation - it’s conditional - consider it “up to 300Mbps”

Exile1975 · 2019-02-11T01:03:39.378Z

And that’s why I think it’s a problem with the AR-750S, if I unplug the power and Ethernet from it and plug into an original AR750 the link speed shows as 300

Screenshot_20190210-180055_WiFiAnalyzer2048×1536 377 KB

Screenshot_20190210-175847_Chrome2048×1536 354 KB

Like I said, not a very WiFi rich area

sfx2000 · 2019-02-11T23:57:30.365Z

One thing I forgot to mention - if the GL-iNet device is set to 300 (HT40), and using Wifi as the WAN side, it’ll match the bandwidth of the host AP - so if the host AP is running normal channels in 20MHz, the AR750 should match it.

@Exile1975 - John, is this the case here?

Exile1975 · 2019-02-12T00:41:45.819Z

I wish it were that simple. I’m using the ethernet for the wan/internet access.

Exile1975 · 2019-02-15T01:39:27.347Z

Is anyone able to confirm that the slate does in fact ever report a 300Mbps link speed on the 2.4ghz band? Maybe someone from gl-inet could look into this now that they’ve returned from their holiday?