Control Channel on 2.4GHz

[eddiez]

It's not, but radio waves follow specific laws of physics as far as aware, so it can be deduced that in any given situation, there will be an optimum setup and some less than optimum setups; the only thing open to opinion is what one person might prefer over another. I have assumed that everyone would want to have the best possible wi-fi signal in as much of their premises as possible, so if that is the case, opinion doesn't enter into the argument as all one has to do as far as I can see is know how to configure the router to give best performance. It is that which I am trying to establish with this discussion, i.e., should we stick with channels 1, 6 & 11 to avoid overlap or not and if so, why doesn't the "Auto" setting in the router follow that procedure?

Radio waves do, but the environment in which they travel isn't black & white. So as long as you exclude this environment , the laws of physics are straightforward. But none of us are sitting on the plains...

 

[TheLyppardMan]

Radio waves do, but the environment in which they travel isn't black & white. So as long as you exclude this environment , the laws of physics are straightforward. But none of us are sitting on the plains...

Exactly - so that's why we need to know the best way to set up our devices given the situation many of us are in, i.e., in close proximity to neighbouring transmissions. That is where the relevance or not of using channels 1, 6 or 11 is fundamental and to which I am trying to obtain an answer.

 

[TheLyppardMan]

Which confirms what I thought and therefore begs the question, why doesn't the auto feature on some routers, including ASUS, follow this procedure or at least, give us the option to force it to do so? I think I'll raise a support ticket with ASUS and link to this thread. I'll post any reply I receive, which should be interesting.

Well, I thought the reply from ASUS might shed some light on this, but as you can see, it doesn't:-
"Unfortunatelly , merlin is a third party firmware that we don't know the capabilities of, and installing such firmware will voind the warranty.
Should you have any further questions, please do not hesitate to get back in touch with us."

When I tried to point out that "I understand that the Merlin alternative firmware is just a clone of the ASUS stock firmware with a few extra additions" and "I assume the feature for auto choosing the channels is therefore the same in the Merlin alternative as in the ASUS version (in fact, one of the replies to my thread [post #16] indicated that they thought that part of the code was closed source and couldn't be modified). So on that basis, can you provide an answer to my query please," I received the following additional reply, "Unfortunately that is not our forum, and we solve each case individually.
Since the firmware is Merlin, we can't offer support for it.
What I can recommend is that you use only official Asus firmware."

Assuming the code for channel selection is actually the same with Merlin and stock firmware, the only way we will stand any chance of getting a definitive answer on this subject is if someone who is using the ASUS stock firmware raises a support query with ASUS as then they will have no excuse not to give a proper explanation. Is anyone up for it?

 

[MichaelCG]

The right answer here is the turn off your 2.4GHz and use 5GHz. The issues you are raising about 2.4GHz in general are not new....these are the same issues that have been discussed for years...and years....and years....stupid and/or mis-informed people running on oddball/non-optimal channels....poor vendor implementations for "auto"....as well as you are completely ignoring the fact that there is a world outside of the USA that does actually have access to some of the higher channels that may provide much needed flexibility.

I see no point in trying to fix a vendors "auto" implementation in 2.4GHz other than maybe having them default to extremely low power to limit the distance the airwaves are fouled.

 

[TheLyppardMan]

The right answer here is the turn off your 2.4GHz and use 5GHz. The issues you are raising about 2.4GHz in general are not new....these are the same issues that have been discussed for years...and years....and years....stupid and/or mis-informed people running on oddball/non-optimal channels....poor vendor implementations for "auto"....as well as you are completely ignoring the fact that there is a world outside of the USA that does actually have access to some of the higher channels that may provide much needed flexibility.

I see no point in trying to fix a vendors "auto" implementation in 2.4GHz other than maybe having them default to extremely low power to limit the distance the airwaves are fouled.

The trouble is so many devices (roughly 90% in my case) still work only on 2.4GHz, so turning it off is not an option in the foreseeable future. If this problem has been known for a long time, it begs the question why the various router manufacturers haven't modified their products to make the most of a less-than-ideal situation. It also means that an auto setting that doesn't do its job properly is worse than pointless.

 

[MichaelCG]

This "auto" issue you are talking about has been around since WiFi has been around. I have yet to own a WiFi AP/Router over the past 15'ish years that implements auto in any meaningful manner. Even the Cisco router my company provides for me stinks at it and I had to have our network guys pin it to Channel6 so it would stop being stupid on Channel 5 or 9. Trying to make "auto" actually useful requires time, software, and resources they aren't willing to throw at a commodity consumer device. If you want a somewhat useful "auto" function that mostly works....go buy one of the big boy enterprise solutions that actively monitors the airspace and makes adjustments on the fly. They exist...but you will pay dearly for it compared to a consumer grade device. And even those aren't perfect and sometimes cause more issues than they solve.

So if you are stuck to 2.4GHz due to device compatibility, about your only option is to really work to move the AP as close to the clients as possible and turn the power way down.

A bit surprised by your 90% estimate....I am down to I think two 2.4GHz only devices (old webcam & old laptop) finally....well....as long as you don't count my Sonos that is. I "think" everything else of mine supports 5GHz...although many still tend to end up on the 2.4GHz. Lucky for me I am in not in an extremely dense area and my performance is not horrible.

 

[dlandiss]

Trying to make "auto" actually useful requires time, software, and resources they aren't willing to throw at a commodity consumer device

It is hard to believe that an "Auto" function that could only switch to 1, 6, or 11 would be too hard to program. After all, in the US it already knows to not use 12, 13 and 14, doesn't it?

 

[john9527]

This is purely an educated guess, and I haven't had the opportunity to test it...but some brave soul could try

nvram set wl0_acs_excl_chans=0x1002,0x1003,0x1004,0x1005,0x1007,0x1008,0x1009,0x100a
nvram commit
service restart_wireless

If you try this, check the value of wl0_acs_excl_chans after the restart, it may get reset during the restart.

 

[RMerlin]

This is purely an educated guess, and I haven't had the opportunity to test it...but some brave soul could try

nvram set wl0_acs_excl_chans=0x1002,0x1003,0x1004,0x1005,0x1007,0x1008,0x1009,0x100a
nvram commit
service restart_wireless

If you try this, check the value of wl0_acs_excl_chans after the restart, it may get reset during the restart.

There's a good chance these might be overwritten by the firmware too.

 

[john9527]

There's a good chance these might be overwritten by the firmware too.

Yes....that's what I meant when I said 'restart'.

 

[sfx2000]

There's a good chance these might be overwritten by the firmware too.

Depending on the WiFi chipset, might just be ignored, using the chip's built-in RTOS...

 

[RMerlin]

Depending on the WiFi chipset, might just be ignored, using the chip's built-in RTOS...

That setting controls Broadcom's own ACSD daemon.

 

[TheLyppardMan]

This is purely an educated guess, and I haven't had the opportunity to test it...but some brave soul could try

nvram set wl0_acs_excl_chans=0x1002,0x1003,0x1004,0x1005,0x1007,0x1008,0x1009,0x100a
nvram commit
service restart_wireless

If you try this, check the value of wl0_acs_excl_chans after the restart, it may get reset during the restart.

Does this go in the services-start file? At the moment, I have the following in that file:-

#!/bin/sh
cru a lightsoff "0 22 * * * /jffs/scripts/ledsoff.sh"
cru a lightson "0 7 * * * /jffs/scripts/ledson.sh"

# make sure WPS is set to off after reboot
if [ "$(nvram get wl0_wps_mode)" != "disabled" ] || [ "$(nvram get wps_enable)" != "0" ] || [ "$(nvram get wps_enable_x)" != "0" ];then
sleep 5
logger "WPS has been disabled by $0"
nvram set wl0_wps_mode=disabled
nvram set wps_enable=0
nvram set wps_enable_x=0
nvram commit
service restart_wireless
fi

 

[john9527]

I just had the opportunity to test the wl0_acs_excl_chans on my fork. The setting held after the restart of the wireless. Unfortunately, I can't tell if it makes a difference, since the regular Auto setting selects channel 6 for me.

@TheLyppardMan
I was originally thinking to test it just via ssh/telnet. If you want to try via your script, just add the nvram set command before the 'nvram commit' in your services-start.

 

[RMerlin]

I just had the opportunity to test the wl0_acs_excl_chans on my fork. The setting held after the restart of the wireless. Unfortunately, I can't tell if it makes a difference, since the regular Auto setting selects channel 6 for me.

Did you restart the acsd daemon? I'm not sure if it gets restarted with the wireless services.

 

[john9527]

Did you restart the acsd daemon? I'm not sure if it gets restarted with the wireless services.

I didn't, but from the pid it looks like it restarted. I'm in the middle of recording a couple of TV shows (stressing the hell out of MediaBridge), so I'll explicitly kill it and restart it again in a couple of hours (it doesn't appear to have a separate service call defined).

 

[TheLyppardMan]

I just had the opportunity to test the wl0_acs_excl_chans on my fork. The setting held after the restart of the wireless. Unfortunately, I can't tell if it makes a difference, since the regular Auto setting selects channel 6 for me.

@TheLyppardMan
I was originally thinking to test it just via ssh/telnet. If you want to try via your script, just add the nvram set command before the 'nvram commit' in your services-start.

Unfortunately it didn't work - it changed to channel 2 and when I rebooted again it changed to channel 3.

 

[john9527]

Unfortunately it didn't work - it changed to channel 2 and when I rebooted again it changed to channel 3.

hmmm....if you login to the router and do
nvram get wl0_acs_excl_chans

does it show the modified value?

EDIT: It may be that ASUS locked this parameter down, along with things like country code in the later firmware.

 

[RMerlin]

At least that nvram setting still exist within the acsd binary:

merlin@ubuntu-dev:~/asuswrt/release/src/router/acsd_arm$ strings acsd | grep acs_excl_chans
acs_excl_chans

 

[TheLyppardMan]

hmmm....if you login to the router and do
nvram get wl0_acs_excl_chans

does it show the modified value?

EDIT: It may be that ASUS locked this parameter down, along with things like country code in the later firmware.

Can you tell me exactly how to do that as I'm still learning about this stuff? I would have to put the extra line of code back in as well as I've since removed it, but it will have to wait until tomorrow as the kids are using the Internet at the moment and won't be too pleased if it starts being interrupted.