Best Method for Periodic Automatic Channel Selection

Hey Guys -

I've been an avid LEDE / OpenWRT user for a while and currently use LEDE Kernel 4.14.105 on a Linksys WRT1900ACS. I live in a crowded neighborhood therefore there are many APs within range (as of writing 23 on 2.4Ghz & 20 on 5Ghz.) and I find my bandwidth and noise frequently fluctuate.

I'm therefore trying to find a package, script, or other method which would periodically scan both 2.4Ghz & 5Ghz network ranges then set each interface to the least used channel

The only thing I've found so far is this script which uses iw to scan for 2.4Ghz APs then set the specified interface to the best channel. I planned to run this on a schedule via cron, but haven't been able to get it to work in testing yet (Github issue pending). Also, unfortunately, it only supports 3 different 2.4Ghz channels.

Does anyone have suggestions for any other method that would work for this?

Thank You!

It does so for good reasons, because there are only three non-overlapping channels, see https://en.wikipedia.org/wiki/List_of_WLAN_channels#2.4_GHz_.28802.11b.2Fg.2Fn.2Fax.29 (the graphics in particular) for details.

2 Likes

It would be best to have a nice chat with your immediate neighbors about the issue. Tell them it would also solve their wifi problems as well. If they do not know how to, help them out.

If the chat works out, for your left neighbor, assist to set on channel 1, for your right neighbor, set to channel 11. Yourself, set to channel 6. These are so called “3” none over lapping channels. Don’t think of other channels as they will create more havoc.

At least, this will work out well on 2.4Ghz. 5Ghz should not be an issue as it has less barrier penetration and your premises should not have much impact, even on the same channel as your immediate neighbour; unless your walls are Italian pizza crust thin.

If still unclear, google “why channel 1,6,11”. Hope that helps.

1 Like

Further, try to reduce tx-power of all APs. :wink:
That hopefully should reduce interference.

Best way to handle situation:
Create a mesh. Then everyone can use every AP. :smiley: But still do the thinngs @sunnymonday is saying about the 3 channel thing.
If you are living in Europe, you have 13 channels. :smiley: But still 1,6,11 are the best channels.

In europe there actually are 4 such channels, but unless all devices support all of these channels sticking to the the set of 3 usable in the US seems better advice...

Only if there are devices incapable of using channel 13, but with the prevalence of iot devices the number of those seems to be growing...

There are different opinions...
You could set to 1,5,9,13. If you have a 802.11b channel bandwidth is 22 MHz. Furthermore, there no space between the channels. You move around and have multipath effects and
doppler effects... It is not given that wifi really sticks to this 20 MHz bandwidth. :stuck_out_tongue:

1 Like

The problem is that no one uses 1, 5, 9, 13 (instead of 1, 6, 11) - and you need cooperation from your neighbours to use a common channel plan and avoid interference (and as @PolynomialDivision already mentioned, 1, 5, 9, 13 isn't without issues either).

Could u maybe somehow jam the other channels until all properitary AP channel selection algorithms (like this Fritz!Box stuff) are switching either to channel 1,6 or 11?
With jamming you could use energy, or just send CTS frames with longest NAV that is possible on all other channels.
I have to Google if this was already done.

But could be some kind of not legal.

There is still a surrounding mystery for me about channel 13 though. At least two things I have noted are:

  • if you hit on the 40 than the 20/40mhz, the whole wireless simply crashes. ( most people like me would simply opt for the highest number. :stuck_out_tongue_winking_eye: )

  • if you have a repeater repeating on channel 13, some wireless client simply cannot detect the repeater’s SSID, or always be prompted with an incorrect wireless key when joining.

Even for devices sold through regular channels[1] in Europe it's not uncommon to find ones that don't allow channel 12/13 (either because they're incorrectly configured to a non-ETSI, predominantly FCC-, regdomain or because the vendor played it 'safe' by deploying a world roaming regdom (with the intersection of all, relevant to them, requirements, so the minimum overlap between the different rule sets)). This means that if you need to be compatible to large numbers of different and changing customers/ devices, you need to avoid relying on channel 12/ 13 in public facing networks.

[1] brick and mortar stores or regular (large) online shops, not ordered/ imported directly from China

1 Like

Thanks for the replies, guys -

Let me add some detail and notes if I may... I just did another survey and there are well over 20 2.4Ghz APs & ~20 5ghz ones as well. Attached are screenshots with details. Some appear greyed out, but because i took the screenshot only after a couple of seconds resuming the scan. I left it running while writing this and most became active again.

Also, I failed to mention that I use a couple of Amazon Cloud Cams in my house. Why's that matter? Because Cloud Cams cannot connect to OpenWRT/LEDE for some reason (unless something has changed in the past couple of months) I therefore have a 2nd AP at home running 2.4ghz only low power which is only for them, yet obviously makes noise. Different fixes for the cloud cams have been proposed, but none worked. Guess that's another post, though.

I understand the logic of asking neighbors to reconfigure, but that isn't very realistic IMO. It would be a huge ordeal to organize this and even the ones I know wouldn't have a clue how to set a channel. Even if they let me do it for them, it could take forever for them to find their passwords and such.

That's why I figured my best bet is to find a solution similar to what I posted about - plus - perhaps look into the issue to get the cams working with OpenWRT/LEDE again so I can strike that AP.

I understand the point about the overlapping channels - however - I don't see that as a reason they shouldn't be scanned, but that the formula used to calculate the best channel should take that information into account.

Example: In the below hypothetical scan (if all APs had same signal strength), the script as I understand it may tell me channel 6 would be the best if it only scans for 3 channels, but with overlapping, would it be?
- Channel 1: 3 APs
- Channel 3: 3 APs
- Channel 5: 10 APs
- Channel 6: 1 AP
- Channel 7: 4 APs

What do you guys think? I may take a shot at editing the script myself although more of a PowerShell guy. I still think that's my best realistic solution, though... besides ethernet :slight_smile:

Thanks

I would assume that this is more an issue of the WRT1900ACS, with its Marvel 88W8864/ mwlwifi radios, than a problem with OpenWrt itself (most likely different radios (QCA/ Mediatek) would not suffer from these problems while running OpenWrt).

1 Like

number of APs is more or less irrelevant, what matters is signal strength.

1 Like

In general this is an array sorting task, where:

  • Channel - Element ID
  • Noise level - Element value

Create a loop by BSSID to populate the array.
Take into account signal level and frequency width.
It looks pretty feasible.

I am of the strong opinion that having 4 slightly less well separated "channels" is better than having just 3 channels. :wink: This allows better spatial separation of APs on the same channel. But I admit that this is mostly academic, in reality I am quite happy that mostly I see 1, 6, 11 interspersed with the odd channel, and at least in areas with dense APs, slightly unfriendedly wider channels disturbing two of the recommended channels.

You are right, my argument should have been, that in real life neither of the two options is implemented, so we might as well aim for the better one, but running a wifi stumbler while traversing my city just demonstrated to me that 1, 6, 11 is already pretty well established.... This indicates to me that the device manufacturers are involved in biasing the automatic channel selection in that direction...