Asus RT-AX86U error: acs_start eth7 cannot select chanspec with the wrong info

[superdeleted]

My AXE11000 just started giving me this same error. There was a firmware push I noticed a few days ago wondering if that would be the start of it. This keeps having my internet seeming;y lock up and drop for a few minutes and then it'll reconnect. I know I had auto select off but when I went and checked it just now after finding this post I saw it was back on auto (which is discerning, esp if the firmware update did that?) so goiong to put it back onto my selection and see if it fixes this .

 

[Aplon]

Same here with GT-AXE11000
I have many drops every single day

 

[ColinTaylor]

Same here with GT-AXE11000
I have many drops every single day

This thread was discussing persistent messages in the system log. Nobody mentioned anything about having "drops". Are you sure you have the same problem? Did you try any of the suggestions from earlier in this thread?

 

[Aplon]

This thread was discussing persistent messages in the system log. Nobody mentioned anything about having "drops". Are you sure you have the same problem? Did you try any of the suggestions from earlier in this thread?

YES, same error
until the router drops the connection.
the suggestion to fix the channel did not help.

you can see the comment above mine with the same problem.

 

[ColinTaylor]

you can see the comment above mine with the same problem.

Ah, I see. So it's the internet connection that's dropping not the Wi-Fi connection. That symptom wasn't mentioned in the original discussion. It sounds like you have two separate problems.

Can you post the complete unedited system log for us to examine? Are you also using AiMesh nodes? Have you tried different firmware versions or done a factory reset?

 

[Aplon]

Ah, I see. So it's the internet connection that's dropping not the Wi-Fi connection. That symptom wasn't mentioned in the original discussion. It sounds like you have two separate problems.

Can you post the complete unedited system log for us to examine? Are you also using AiMesh nodes? Have you tried different firmware versions or done a factory reset?

Yes, I have TUF-AX5400 in another room.
logs from General Log ?

it's only
Jul 27 15:06:35 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info
Jul 27 15:06:38 acsd: eth7: Selecting 5g band ACS policy

same hundreds times until the internet connection down

 

[ColinTaylor]

Yes, I have TUF-AX5400 in another room.
logs from General Log ?

it's only
Jul 27 15:06:35 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info
Jul 27 15:06:38 acsd: eth7: Selecting 5g band ACS policy

same hundreds times until the internet connection down

Yes the General Log. Can we see as many messages as possible prior to the internet going down and up until just after the internet connection is restored.

 

[Qbcd]

I have the exact same issue, getting this error every few seconds:

Aug 20 13:44:33 acsd: eth7: Selecting 5g band ACS policy
Aug 20 13:44:33 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info

It's entirely related to AiMesh. I have an AX86U as my main router and an XT8 as the node. When I remove the XT8, the error goes away. When I re-add it, it comes back. On the AX86U, I have selected both my 2.4GHz and 5GHz channels, so nothing is on Auto. I do have SmartConnect enabled though, I need it to stay on unfortunately. On the XT8 node, I can't control any channels. So my guess is the error refers to the XT8, not the main router, i.e. the XT8 is having trouble with its own auto channel select.

This just randomly started happening, it wasn't an issue before, maybe a firmware update did it. I've tried rebooting the entire AiMesh, and removing and re-adding the node, neither helped. I haven't factory reset the main router, but I really don't want to redo all of my settings again.

It doesn't seem to have any effect on performance, everything still works fine, other than the usual bugs of DFS channel selection that I won't go into here. The only thing that seems to have changed is that 160MHz doesn't work anymore. If I set 160 MHz or 20/40/80/160 on Channel 100 (the node doesn't support the lower ones), it just doesn't work, it immediately makes Channel 124 unavailable for 30 minutes and that's that, and again I'm pretty sure that's related to the XT8, probably the same bug that's causing the repeating error in system log. I hope Asus fixes it.

I think with AiMesh, pairing things that weren't designed to be paired together, like in my case a dual-band AX86U main with a tri-band XT8 node, will often result in bugs. Asus QC is definitely not great.

Edit: Weirdly what fixed it was when I set the 5 GHz channel in the main AX86U router to Auto. It automatically selects Channel 100 which is what I want anyway, so it's fine for now. But it still won't do 160 MHz, even if I force 160, it just does 80. I don't know why, it used to do 160, but it doesn't want to anymore.

 

[Qbcd]

Just curious, does anyone running Merlin have this issue? I wonder if it'll be fixed by running Merlin.

 

[fre_]

Just curious, does anyone running Merlin have this issue? I wonder if it'll be fixed by running Merlin.

I'm on Merlin (firmware 3004.388.4) and can confirm the same error occurs.
I'm using a RT-AX86U as router in a network with 2 nodes (AiMesh) which are both XT12.
They also run on Merlin, same version.

Don't know if it has something to do with it, but I'm experiencing random reboots, which started since the last firmware update. I did already a factory reset, without improvement.
Just changed my log-level to 'debug' and 'all' so it captures more info which I plan to share here when the next reboot happens.

 

[Qbcd]

I'm on Merlin (firmware 3004.388.4) and can confirm the same error occurs.
I'm using a RT-AX86U as router in a network with 2 nodes (AiMesh) which are both XT12.
They also run on Merlin, same version.

Don't know if it has something to do with it, but I'm experiencing random reboots, which started since the last firmware update. I did already a factory reset, without improvement.
Just changed my log-level to 'debug' and 'all' so it captures more info which I plan to share here when the next reboot happens.

That's a similar setup to mine, AX86U main with an XT8 node. I think the issue is with manual 5GHz channel selection on the AX86U with tri-band nodes. I set it to Auto and since then have not seen the error, and luckily it uses the channel I want it to use anyway - channel 100. Because the XT8 doesn't support the lower channels for backhaul, only 100-140.

 

[fre_]

That's a similar setup to mine, AX86U main with an XT8 node. I think the issue is with manual 5GHz channel selection on the AX86U with tri-band nodes. I set it to Auto and since then have not seen the error, and luckily it uses the channel I want it to use anyway - channel 100. Because the XT8 doesn't support the lower channels for backhaul, only 100-140.

My 5 Ghz channel selection was also on manual mode when the error occurred, it was on channel 132.
I just changed it to Auto with 160 MHz enabled, DFS unchecked.
It took channel 36. I can see now that on the previous channel 132, there is a HiddenSSID, probably from the XT12 wireless backhaul I suppose.

At the moment, the error (acs_start eth7 cannot select chanspec etc ...) is gone.
I will keep an eye on it more closely now.

 

[BAM]

I have the exact same issue, getting this error every few seconds:

Aug 20 13:44:33 acsd: eth7: Selecting 5g band ACS policy
Aug 20 13:44:33 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info

It's entirely related to AiMesh. I have an AX86U as my main router and an XT8 as the node. When I remove the XT8, the error goes away. When I re-add it, it comes back. On the AX86U, I have selected both my 2.4GHz and 5GHz channels, so nothing is on Auto. I do have SmartConnect enabled though, I need it to stay on unfortunately. On the XT8 node, I can't control any channels. So my guess is the error refers to the XT8, not the main router, i.e. the XT8 is having trouble with its own auto channel select.

This just randomly started happening, it wasn't an issue before, maybe a firmware update did it. I've tried rebooting the entire AiMesh, and removing and re-adding the node, neither helped. I haven't factory reset the main router, but I really don't want to redo all of my settings again.

It doesn't seem to have any effect on performance, everything still works fine, other than the usual bugs of DFS channel selection that I won't go into here. The only thing that seems to have changed is that 160MHz doesn't work anymore. If I set 160 MHz or 20/40/80/160 on Channel 100 (the node doesn't support the lower ones), it just doesn't work, it immediately makes Channel 124 unavailable for 30 minutes and that's that, and again I'm pretty sure that's related to the XT8, probably the same bug that's causing the repeating error in system log. I hope Asus fixes it.

I think with AiMesh, pairing things that weren't designed to be paired together, like in my case a dual-band AX86U main with a tri-band XT8 node, will often result in bugs. Asus QC is definitely not great.

Edit: Weirdly what fixed it was when I set the 5 GHz channel in the main AX86U router to Auto. It automatically selects Channel 100 which is what I want anyway, so it's fine for now. But it still won't do 160 MHz, even if I force 160, it just does 80. I don't know why, it used to do 160, but it doesn't want to anymore.

Thanks @Qbcd, I found your suggestion whilst searching for this error.
I added an ax55 node to my ax86s today and was experiencing a few Wi-Fi drops along with hundreds of log errors.

Changed my 5ghz channel back to Auto and the logs are now clear and so far, no disconnects.

 

[geoffroyg]

I got rid of the error message by uncheking Enable 160 Mhz, and fixe control channel.
Hope this helps

 

[HarryMuscle]

I'd like to add myself to the people who are having this issue. Unfortunately, I can't use Auto for the channel selection because I'm in a very crowded WiFi environment and only certain channels work decently. Also I already had Enable 160 MHz unchecked but I'm still getting this message appearing every few seconds in my log and like others have mentioned that WiFi seems to drop occasionally which I'm assuming is related. Can anyone think of anything else to try?

 

[HarryMuscle]

I got rid of the error message by uncheking Enable 160 Mhz, and fixe control channel.
Hope this helps

Did the messages come back? Strangely I have the exact same settings (160 MHz disabled and a fixed channel selected) but I'm getting these messages along with WiFi drops.

 

[HarryMuscle]

In case anyone is still dealing with this issue ... based on some NVRAM value comparisons it looks like the culprit is:

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:

nvram set acs_ifnames=

Hope this helps someone.

EDIT: it seems the issue is more complicated since the acs_ifnames NVRAM key gets changed by cfg_server process after a reboot and/or at other times. Bit more details about this can be found here: https://www.snbforums.com/threads/t...anspec-with-the-wrong-info.87604/#post-875637

 

[hash70]

Getting the same errors on my rt-ax86u after updating to 388.5 from 388.4,going to do a dirty flash bck to 388.4

 

[Qbcd]

Do we have a solution for this yet? I have an AX86U main + two AX86U nodes now. If I use a fixed channel, I get this error after about a day or two. But worse than that, when the error happens, it bumps me off of my preferred channel 100. I used to get around this by using Auto, which auto selected channel 100 and stayed on it forever - but lately it's been bumping me off of it - even though the channel is still clear and there are no DFS events.

So now the Auto workaround doesn't work, and the manual selection doesn't work. And I really need to use channel 100 because the power limit of it is much higher, so I get a much better connection to my nodes, it's also completely interference-free.

So this bug has now actually ruined my home network. I'm thinking of buying an AX89X for the main router hoping that would fix it, but it may not. Any suggestions at all? I've tried setting it to auto and then manual as suggested in the other thread in the Merlin section, and that didn't fix it. @HarryMuscle's solution there using a script seems promising, but I have no idea how to do it.

 

[Igor]

AX68U, fw 3004.388.6_2: "acs_start eth6 cannot select chanspec with the wrong info"
I saw the problem a day later and only after looking at the log today. Rebooting the router helped me. Log:

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C wlceventd: wlceventd_proc_event(831): eth6: Radar detected

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: cm_updateChanspec call wl_chanspec_changed_action

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server:
event: wl_chanspec_changed_action_a101 of eid(1) of cfgs(1073)

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: ! handling event in static chan case: (5g_1)wl1_chanspec:136u / (5g_2)wl2_chanspec:

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: current chansp(unit0) is 1001

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: current chansp(unit1) is d986

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: dump exclchans:

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: old wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: new wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: valid wl0_acs_excl_chans:

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: old wl1_acs_excl_chans:

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: new wl1_acs_excl_chans:0xd088,0xd986

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: valid wl1_acs_excl_chans:

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server:
 wl_chanspec_changed_action: Need to restart acsd due current 5G chanspec is un-available, (cur_5g=d986), static5G=1

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C cfg_server: reset acs_ifnames as eth6

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C rc_service: cfg_server 1073:notify_rc restart_acsd

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C acsd: eth6: Selecting 5g band ACS policy

Sat Mar 16 16:07:45 2024;10.8.0.2; <13>Mar 16 16:07:46 RT-AX68U-92A0-522207D-C acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info

Sat Mar 16 16:07:48 2024;10.8.0.2; <13>Mar 16 16:07:49 RT-AX68U-92A0-522207D-C acsd: eth6: Selecting 5g band ACS policy

Sat Mar 16 16:07:48 2024;10.8.0.2; <13>Mar 16 16:07:49 RT-AX68U-92A0-522207D-C acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info

Sat Mar 16 16:07:51 2024;10.8.0.2; <13>Mar 16 16:07:52 RT-AX68U-92A0-522207D-C acsd: eth6: Selecting 5g band ACS policy

Sat Mar 16 16:07:51 2024;10.8.0.2; <13>Mar 16 16:07:52 RT-AX68U-92A0-522207D-C acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info

Sat Mar 16 16:07:54 2024;10.8.0.2; <13>Mar 16 16:07:55 RT-AX68U-92A0-522207D-C acsd: eth6: Selecting 5g band ACS policy

Sat Mar 16 16:07:54 2024;10.8.0.2; <13>Mar 16 16:07:55 RT-AX68U-92A0-522207D-C acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info

Sat Mar 16 16:07:55 2024;10.8.0.2; <30>Mar 16 16:07:56 RP-AX58-B528-522207D-R hostapd: wl1.1: IEEE 802.11 driver had channel switch: freq=5200, ht=1, vht_ch=0x0, he_ch=0x0, offset=-1, width=2 (40 MHz), cf1=5190, cf2=0

Sat Mar 16 16:07:55 2024;10.8.0.2; <14>Mar 16 16:07:56 RP-AX58-B528-522207D-R kernel: CFG80211-ERROR) wl_dfs_cac_notify_status :

Sat Mar 16 16:07:55 2024;10.8.0.2; <12>Mar 16 16:07:56 RP-AX58-B528-522207D-R kernel: In wl_dfs_cac_notify_status chanspec 0xd926 DFS state 0

Sat Mar 16 16:07:57 2024;10.8.0.2; <13>Mar 16 16:07:58 RT-AX68U-92A0-522207D-C acsd: eth6: Selecting 5g band ACS policy

Sat Mar 16 16:07:57 2024;10.8.0.2; <13>Mar 16 16:07:58 RT-AX68U-92A0-522207D-C acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info[

[skip]

Sun Mar 17 09:27:02 2024;10.8.0.2; <13>Mar 17 09:27:04 RT-AX68U-92A0-522207D-C acsd: eth6: Selecting 5g band ACS policy

Sun Mar 17 09:27:02 2024;10.8.0.2; <13>Mar 17 09:27:04 RT-AX68U-92A0-522207D-C acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info
/CODE]