What's new

Temporary Loss Of WiFi And Log Full Of "acs_start eth7 cannot select chanspec with the wrong info"

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

HarryMuscle

Senior Member
I updated my RT-AX86U router and RT-AX86S node to 388.4 a few days ago and did a full factory reset and reconfigure. Yesterday I lost WiFi ability for about 20 minutes (devices would error out trying to connect). Today I finally got a chance to check the router log and it's full of the following messages:
Code:
Nov 13 14:51:58 acsd: eth7: Selecting 5g band ACS policy
Nov 13 14:51:58 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info

Unfortunately yesterday's 20 minutes WiFi outage was no longer in the logs because I'm getting the above messages every few seconds. Is this a known bug? There was a thread about this earlier this year (https://www.snbforums.com/threads/a...ot-select-chanspec-with-the-wrong-info.85364/) but I wanted to start one in the Merlin section since in my case I'm getting this issue running the Merlin firmware.

If this was just a log message issue I wouldn't care so much but it seems to be related to the WiFi cutting out (in that thread others mention losing WiFi also).

Anyone have any suggestions on how to resolve this? The other thread mentions that some had success with setting 5G WiFi to auto channel selection but that won't work for me due to the crowded WiFi environment I'm in. Also I've already disabled the Enable 160 MHz option mentioned in that thread too.

Thanks,
Harry
 
Last edited:
It's an issue with the control channel and channel width on 5-Ghz. Set it to auto and 80 wide. If set for auto, select a channel. Once you are stable, you can configure as you like.
 
It's an issue with the control channel and channel width on 5-Ghz. Set it to auto and 80 wide. If set for auto, select a channel. Once you are stable, you can configure as you like.
That's the thing, it's already set to 80 MHz wide and a specific channel is selected but I'm getting this issue. Unfortunately using auto channel is not an option for me since only one channel is actually usable in my crowded environment but auto never chooses it.
 
Yep, change to auto. The problem will clear. Wait an hour or so and then you can select a channel and all will be well. A few of us went through this.
 
You need to change the setting as described. Turning it off and on will not resolve the issue.
 
You need to change the setting as described. Turning it off and on will not resolve the issue.
Sorry, I meant if I follow your instructions does that only fix the issue until a reboot or power outage and after said reboot or power outage you once again need to switch the channel to auto and then afterwards to a specific channel, or do these steps fix the issue permanently?
 
Fortunately, once you do this it will not come back as the result of a restart of any kind
 
Fortunately, once you do this it will not come back as the result of a restart of any kind
Interesting, that means that it must be a NVRAM value causing the issue which is weird because when you first confige the router the 5G channel starts out as Auto. I'll have to follow your steps and compare before and after NVRAM values to see what the actual issue might be for curiosity sake.
 
Based on some NVRAM value comparisons it looks like the culprit is:
Apache config:
acs_ifnames
which by default is prepopulated with the 5GHz WiFi interface and changing the channel to Auto and then back to a preset channel clears this NVRAM value. You can also do so by running the following command via SSH:
Code:
nvram set acs_ifnames=
Hope this helps someone.
 
Fortunately, once you do this it will not come back as the result of a restart of any kind
Thanks for your help with this. Just one more question, do you use any AiMesh nodes? The other thread mentions that some people only started having this issue after adding a node which got me wondering if the incorrect NVRAM value mentioned above gets set incorrectly when a node gets added.
 
... auto channel is not an option for me since only one channel is actually usable in my crowded environment but auto never chooses it.
Just a fleeting notion: assume most other wifi's in your vicinity are using "auto channel"; thus one being "vacant" may well be for a reason, so "jumping on that void" /could/ be a can of worms for you. How well does it behave when you let /it/ make the channel decisions?
 
I have two nodes. I use a fixed channel as I don't want to be part of a wave of changes, a known problem with auto channel.
 
I have two nodes. I use a fixed channel as I don't want to be part of a wave of changes, a known problem with auto channel.
It definitely is related to having a node. I did some more testing and using your work around fixes the issue even after a router reboot, but if you reboot the node, the issue comes back. So unfortunately it's not really a solution cause every time the node reboots you have to change the channel to Auto and then back to a preset channel.
 
I've never seen that and have restarted both my nodes multiple times. My nodes run Asus firmware with my router running Merlin
 
If the selected channel is within DFS, perhaps service would be delayed on the newly-booted node while the channel is being cleared and it's thus switched to Auto automatically to alleviate that wait time. If so, it would be nice for the system to switch back as well, automatically.

Can't rely on the master to sound the DFS "all clear" because it might have a sufficiently-different view of the world.
 
I live near an airport. No DFS for me. I have experimented with DFS, it is a mess that is not worth the frustration for me. It is faster yet too many issues
 
I've never seen that and have restarted both my nodes multiple times. My nodes run Asus firmware with my router running Merlin
I'm getting some strange results. The first time when I tried the "change to auto then change back to set channel" fix I was able to reboot but now when I reboot even the router the issue comes back.

I've been able to track it down to cfg_server setting the acs_ifnames NVRAM key to "eth7" (even though both 2.4 GHz and 5 GHz WiFi settings are set to a specific channel) and then calling the restart_acsd event. Fortunately that means the event can be interrupted with the service-event script and the acs_ifnames NVRAM key can be set to nothing before acsd actually starts. That's what I did and so far no matter what reboots things are looking good.

It makes sense that this is related to having nodes because the whole issue is started by cfg_server which apparently is responsible for communicating with nodes.
 
You are the first I've seen report the issue on 2.4 GHz. I wonder what Merlin things about this?
 
Use the following to get a base for what you're currently running now.


Afterward, flash the latest Alpha firmware for your router and test.

This may have already been fixed. 388.4 is 'old news' today. ;)


Click the 'Pre-beta test builds' link for the Alpha versions of your model. Be sure to sort by date and get the 2nd, Alpha 1.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top