An option description missing in Wi-Fi wiki page

The wiki page for Wi-Fi configuration provides lots of useful information, but there is one particular option not mentioned there or anywhere else in the wiki. It is the (in)famous noscan option which I think affects CCA behavior in the secondary (bonded) channel. It would be great to have a more complete documentation by including its description and conditions under which it is applicable (frequency band(s) for example).

Just looks like it wasn't imported from the oldwiki.
Wireless configuration [Old OpenWrt Wiki]

It only takes effect on the 2.4ghz band and HT40 (maybe HE40?) modes AFAIK.

1 Like

Thank you both for intervening, it's already where it should be :slight_smile:

@lantis1008 You wrote "just looks like it wasn't imported" and I'm sorry for being very forward, but how's that possible? What kind of migration truncates information? Do you know any similar examples that I should beware in the new wiki?

You'd have to ask @bobafetthotmail (if they remember) as they were the first author of that page. The content can't have come from nowhere, it is obviously a copy paste from another source.

By and large the wiki is a community effort and a lot of time and care has gone into it, but there's always going to be bits missing (unintentionally). Highlighting it and getting it addressed is all you can do :slight_smile:

2 Likes

Human mistakes. Wiki is created and maintained by unpaid community members which may or may not fully understand the wiki contents. We cannot guarantee 100% correct information or even 100% complete information.
If something is missing, please notify it, add or update it.

This is one of the reasons the old wiki has been turned read-only but it's still accessible and why all wiki edits are logged and can be reverted.
See below.

So it seems you guys have foiled my evil scheme for world domination in the end. :neutral_face:

Quite frankly I don't remember removing it nor any other option, maybe it got lost while I was reworking the page while posting it, I don't remember.
The page was copy-pasted together with most other stuff from the OpenWrt wiki of the time (what is now the oldwiki) in 2016 as we can see from the edit log https://openwrt.org/docs/guide-user/network/wifi/basic?do=revisions&first=100

and if we look at how the page looked back then it's not just missing the noscan option but a whole table about mac80211 options https://openwrt.org/docs/guide-user/network/wifi/basic?rev=1477142304

Thanks @vgaetera for adding it back btw https://openwrt.org/docs/guide-user/network/wifi/basic?rev=1629780777#mac80211_options

Like most other options in that coughmissingcough table (and wifi in general) it's actually passed to hostapd application, and it's hostapd that is doing the job.
So if you need more info about most of those options you can google "hostapd optionname" to find either hostapd docs or other people on Linux that use it.

In case of this specific noscan option it's a non-upstream modification to this application (that OpenWrt and Arch Linux have) that hacks it to disable a check it does to comply to wifi specifications when you try to enable 40Mhz or HT40 in wifi n on 2.4 Ghz radio in an overcrowded environment.

I'll copy-paste this dude's blog post that describes the issue. http://blog.anthonywong.net/2015/07/19/boost-wifi-speed-raspberry-pi-hostapd/

802.11n can double the channel bandwidth of 802.11g from 20 MHz to 40 MHz, but this operation mode is not recommended in areas that the spectrums are congested and likely interfere with existing WIFI and bluetooth devices. As a result, hostapd will not enable 40 MHz when it finds other channels are being used, like what is seen from the hostapd log below:

nl80211: New scan results available
nl80211: Received scan results (16 BSSes)
40 MHz affected channel range: [2397,2447] MHz
Neighboring BSS: 1c:fa:68:8e:a6:e0 freq=2412 pri=1 sec=5
Neighboring BSS: e0:05:c5:4c:e2:b6 freq=2427 pri=0 sec=0
Neighboring BSS: b0:48:7a:6a:9d:32 freq=2437 pri=6 sec=10
40 MHz pri/sec mismatch with BSS b0:48:7a:6a:9d:32 <2437,2457> (chan=6+) vs. <2412,2432>
20/40 MHz operation not permitted on channel pri=1 sec=5 based on overlapping BSSes
1
2
3
4
5
6
7
8
	
nl80211: New scan results available
nl80211: Received scan results (16 BSSes)
40 MHz affected channel range: [2397,2447] MHz
Neighboring BSS: 1c:fa:68:8e:a6:e0 freq=2412 pri=1 sec=5
Neighboring BSS: e0:05:c5:4c:e2:b6 freq=2427 pri=0 sec=0
Neighboring BSS: b0:48:7a:6a:9d:32 freq=2437 pri=6 sec=10
40 MHz pri/sec mismatch with BSS b0:48:7a:6a:9d:32 <2437,2457> (chan=6+) vs. <2412,2432>
20/40 MHz operation not permitted on channel pri=1 sec=5 based on overlapping BSSes

However, this is unrealistic in modern cities. You should be grateful the primary channel you choose has not been used already, let alone the additional one for 40 MHz. What can we do? We have to force hostapd to turn on 40 MHz anyway.

Now back to our forum, this option was introduced a while back when wifi n was new. Nowadays you have better options. If you really need more bandwith and you are in a congested environment it's probably better to go with 5Ghz radio on wifi ac and wifi 6 and whatever else instead than going off spec and spamming the 2.4Ghz frequency even more to try to squeeze out a little more on wifi n

1 Like

And don't forget that the main problem with enabling this option isn't that you aren't being neighborly.

The more serious issue why the standard disallows using a wide channel when there exists a narrow one beneath either halves is that you, who can "only" transmit when both sides are free may suffer from unlimited starvation due to waiting, thus lowering your QoS, see the dining philosophers problem:

In contrast, coexistence works correctly when you are sharing the same HT20 channel that someone else is using - you are statistically expected to receive a 50% fair share of the airtime/"bandwidth" in such a case.

It is recommended to upgrade all of your equipment to 5/6GHz. Lacking that, to get the most from 2.4GHz, I recommend that you get devices with the most number of spatial streams possible (usually that means 3 for n, or >=4 for ax).

To reduce outside interference, you can also sometimes play with shielding the antenna of your AP or client or decrease the TX power throughout your facility and hopefully disable legacy rates and even increase the basic rate somewhat.

2 Likes