Changing 2.4GHz wireless channel off of 'auto' causes both 2.4 and 5 GHz channels to de-activate

Installing and Using OpenWrt
1

This is OpenWrt 19.07.1 running on a Linksys WRT3200ACM. The only reason I use OpenWrt is for the VPN client, so all my connected devices are behind my VPN provider.

I was reading that having an interface's channel set to 'auto' merely picks the first available channel, rather than intelligently selecting the least crowded channel. I was troubleshooting some Sonos issues, and the first thing I wanted to do was try to find less-congested channels for these devices (which run on 5GHz). So I used my Mac's network scan to recommend better channels.

Armed with that information, if I go into LUCI and do Network -> Wireless, select 'Edit' for the device configuration corresponding to the 2.4GHz, 5.0GHz, or both radios, and switch the 'channel' dropdown from 'auto' to any specific channel, things break horribly.

For example, if I switch the 5.0 radio's channel from Auto to 136 and hit "Save & Apply", a 30 second "Waiting for configuration to get applied..." countdown lapses, followed by a "Failed to confirm apply within 30s, waiting for rollback.." message that never goes away. End result: The changes are not applied.

If I futz around with LUCI to force this change, OR if I do it manually by ssh-ing onto the router and tell it:

uci set wireless.radio0.channel='144'
uci commit
reboot

... then neither radio comes up and I have to connect via ethernet to revert the channels back to 'auto' to fix the problem.

For example, here is my wireless config before I try to change just the 5.0GHz channel off of 'auto':

[Screenshot removed by admin to avoid unwanted dataspill]

And here it is after I've changed it to 136:

[Screenshot removed by admin to avoid unwanted dataspill]

If anyone has any suggestion on how I can manually specify the channel for 2.4 and 5.0, without taking down both wifi radios, I would appreciate it. Thanks!

2

Update to latest?

It should do that and then scan for best channels.

802.11ac is your best choice in that regard.

This is very common in a lot of routers. Not much you can do about it. Just pick a channel - don't use auto.

All DFS channels require at least 60-120 seconds to settle in, maybe longer. It might not work = back to non DFS channels for best results/reliability. Pick a channel - don't use auto. Give the radio a minute to start up.

You have to apply unchecked. Click the arrow to the right of "apply and save'. And then click "apply unchecked".

HTH

3

@goffredo is moving away from auto channel and trying to force a channel, read carefully.

4

I would recommend you try to make your changes with a wired connection, this will prevent you being disconnected from WiFi and should allow you to complete Save & Apply procedure without getting kicked off from WiFi while changes are being saved & applied.

From there, you will likely get a better handle on things, just a thought...

5

Yeah sorry I was tired. I just get so triggered by the 3200 and its poorly implemented WLANs. Such a tragedy.

OTOH looks like that is the least of his worries if he is still running 19.07.1

  • Another trick is to delete any unused SSID's
  • delete and redo any SSID's that aren't working (ie. one might be set to auto and another on the same radio might not be = conflicted or corrupt config = it stops working)
  • I have seen the EA8300 shuffle MACs around when adding new SSID's and this causes the radios to stop working and/ or clients get confused. (it happened on radio 2, channel 36 for me)
  • if you create a SSID and it doesn't seem to work but you know the settings look good try a reboot to reinitialize the radios or one of those fancy UCI commands.
  • last but not least if you can't get a corrupted configuration to work it might be time for a factory reset.
6

Wow, thanks for all the prompt and in-depth advice!

I know it may be disappointing to you guys, but upgrading the firmware, buying a new router, and playing around for days on end with settings are way more trouble that I'm willing to commit to. As a retired mobile software developer, those days are behind me. I'd rather be outside on the boat or hiking with my dogs.

To fix the Sonos dropouts, I ran one of my Sonos devices on Ethernet. Just having one device on ethernet allows me to use "SonosNet 2.0 wireless network ("Boost" mode)" instead of just normal wifi. I guess this SonosNet business is a Sonos-proprietary mesh protocol that is designed from the ground up to be for steaming music through a house. I dunno. But it worked, the drop-outs are gone and I don't have to fuss with my channels. Nothing to do with OpenWrt of course, but in the very off chance that someone else stumbles across this issue, that's what worked for me.

1 Like
7

Try channel 36.
The commentary about DFS is accurate. Trying a non-DFS channel will rule out a bunch of other issues that can get in your way.

1 Like
9

As far as I remember there were WRT wifi bug fixes in later releases.
I would upgrade to 19.07.7, to get these.
The WRT platform has some builtin wifi issues, but 19.07.7 is at least not worse than 07.1