What's new

Beta Asuswrt-Merlin 3004.388.4 beta is now available

  • 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!

Status
Not open for further replies.
Had one weird issue this morning when my upload speeds were halved on my AX86U Pro, thought it may have been my ISP. But after a couple of reboots, it's back to normal.
 
Hi all. Just upgraded my AX86U to beta 2 and getting the following message continuously in the logs:

Aug 6 19:37:23 acsd: eth7: Selecting 5g band ACS policy
Aug 6 19:37:23 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info

This was a dirty upgrade from 388.2. Any ideas? Everything seems to be working ok.
 
Loaded beta 2... For me the same issues at beta 1. DHCP not resolved from provider error. Every other firmware works perfectly except these 2 betas. Unplug and plug back in WAN cable resolves the problem. On a soft or unplug reboot the issue returns. Tried everything including the ASUS reccomendation of changing DHCP frequency from aggressive to continuous. Still dosen't work.

CC
same issue on Roger's internet on AX88PRO in Toronto. backed out to 388.2.2
 
what model router are you using? From what version did you upgrade from (and was it factory or Merlin)? All working flawless on my AX88U pro.
GT-AXE 16000 up from beta 1, latest stock, and 388.2 Tried all 3 with a factory reset on each install. Same DHCP error. Every other firmware does not have this problem only the 2 new betas. I am not alone on this.

CC
 
Hi all. Just upgraded my AX86U to beta 2 and getting the following message continuously in the logs:

Aug 6 19:37:23 acsd: eth7: Selecting 5g band ACS policy
Aug 6 19:37:23 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info

This was a dirty upgrade from 388.2. Any ideas? Everything seems to be working ok.
yep. I had exact same issue after upgrading. the other impact was ram memory was slowly increasing.

the fix (for me) was to change wifi settings on 5g and switch from fixed channel to auto. After this no issue. I have left mine on auto but you can try switching back to fixed channel
 
GT-AXE 16000 up from beta 1, latest stock, and 388.2 Tried all 3 with a factory reset on each install. Same DHCP error. Every other firmware does not have this problem only the 2 new betas. I am not alone on this.

CC
There's been no change to the DHCP client.

What's the content of your system log during the boot and during these failed lease attempts? Also, what's the content of your firewall following the reboot after it failed to obtain a new DHCP lease?

Code:
iptables -L -vn
 
Last edited:
I just restored JFFS partition backup.
That writes some settings too. I.E. images of dhcp clients. So it will be no FULL reset and you may get some troubles with.
 
Updated my RT AX3000 to 388.4 beta2. Everything is working perfectly except the DDNS update issue which was not there in 388.2. DDNS is working after the system reboot but not updating the IP in the running system if the lease is renewed by the ISP.
 
My AX86U worked without problems on beta1 for about 5 days, after which the day before yesterday I updated it to beta2. And today I found that only 43 MB of free RAM remained. The scMerlin script shows that 467 MB is used and 400 MB of RAM is cached by the system. This is normal? On all previous firmwares I've used, the RAM cache never exceeded 150MB, even after a week or more.
Despite this, the router continues to work normally without using the swap file.
 
Haven't noticed any unusual RAM usage on my AX86U Pro, currently sitting at 499MB used and 525MB free.
 
My AX86U worked without problems on beta1 for about 5 days, after which the day before yesterday I updated it to beta2. And today I found that only 43 MB of free RAM remained. The scMerlin script shows that 467 MB is used and 400 MB of RAM is cached by the system. This is normal? On all previous firmwares I've used, the RAM cache never exceeded 150MB, even after a week or more.
Despite this, the router continues to work normally without using the swap file.
It's normal, and varies depending on disk activity.
1000033353.jpg
 
Last edited:
I thought I'd look into this so repeated your steps. While not as extreme as your error the Web page does throw a 404 error and locks the gui for 10-15 seconds.
AX88U though with the same beta.
Same 404 error here on a RT-AX68U (signature not updated)
 
There's been no change to the DHCP client.

What's the content of your system log during the boot and during these failed lease attempts? Also, what's the content of your firewall following the reboot after it failed to obtain a new DHCP lease?

Code:
iptables -L -Vn

I will set it up again and get the info requested. This is the first time I am completly stumped on whats going on.

Charlie
 
There's been no change to the DHCP client.

What's the content of your system log during the boot and during these failed lease attempts? Also, what's the content of your firewall following the reboot after it failed to obtain a new DHCP lease?

Code:
iptables -L -Vn
I am on the latest stock version, can I just do a dirty upgrade or do I need a factory reset?

Charlie
 
388.4 Beta 2 installed over Beta1 on my GT-AXE11000. Three AiMesh units, 1x GT-AX6000, 2x RT-AX86U, 2.5Gb ethernet back-haul connected to the AXE11000. The 2x AX86U's updated via the GUI panel from Beta1 to Beta2.
The GT-AX6000 though wouldn't accept the ID & PW as correct for this setup. Tried dropping the AX6000 from AiMesh and reinstalling still wouldn't accept the ID & PW. Manual reset (hold WPS & Power on/off) and back into the AiMesh still a no-go.
What worked...had to connect my laptop via ethernet cable to one of the four 1Gbe GT-AX6000 ports, then it accepted the ID & PW, converted from Beta1 to Beta2. Never a weirdness like this firmware updating a AiMesh unit ever since that function became available. Earned a drink of Scotch later in the evening...
 
388.4 Beta 2 installed over Beta1 on my GT-AXE11000. Three AiMesh units, 1x GT-AX6000, 2x RT-AX86U, 2.5Gb ethernet back-haul connected to the AXE11000. The 2x AX86U's updated via the GUI panel from Beta1 to Beta2.
The GT-AX6000 though wouldn't accept the ID & PW as correct for this setup. Tried dropping the AX6000 from AiMesh and reinstalling still wouldn't accept the ID & PW. Manual reset (hold WPS & Power on/off) and back into the AiMesh still a no-go.
What worked...had to connect my laptop via ethernet cable to one of the four 1Gbe GT-AX6000 ports, then it accepted the ID & PW, converted from Beta1 to Beta2. Never a weirdness like this firmware updating a AiMesh unit ever since that function became available. Earned a drink of Scotch later in the evening...
I've experienced many devices over the years that refused to connect as AiMesh node using wifi only. Wired connection, even if only temporary to establish connection, is always most reliable.
 
Last edited:
Status
Not open for further replies.

Similar threads

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