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.
Merlin did some adjustments right before building Beta 1 regarding utilization, so guess that made it disappear from a few models. Hope it can be fixed/reverted! :)
Channel utilisation was not working properly on wifi SoC that use the WL interface, only on the more modern interfaces that use DHD. It was permanently reporting 100%, therefore it was disabled from these unsupported wifi interfaces. The RT-AX86U uses different Wifi chips for the 2.4 GHz and the 5 GHz, only the 5 GHz is supported. That's why it's showing on the 5 GHz but not on the 2.4 GHz. This is working as intended.
 
Upgraded about 18 hours ago no major issues. My Google Home mini is about to be used as a hockey puck, but that has been slowly failing for more than a year (maybe it's like an Apple "undocumented feature"). Yup the 2.5Gbps LED is permanently lit but that's no biggie. Can't find that post where peeps were complaining about 2.5Gbps sync taking a long time on the GT-AX6000, but I've 3x 2.5Gbps device ports to play with now (1x Rockchip, 1x Realtek, 1x unknown) and none of them take more than about 2secs to sync.
 
Can anybody point me in the direction of resources to learn about the differences between 3004 and 3006 versions?
(are they linux kernel related? a move from k4.x to k6.x, for instance?)
 
Running fine on my AX86U router, though I haven't been able to load any newer firmware beyond FW_RT_AX86U_300438822525 on my AIMesh node as connected devices continually disconnect and reconnect and tend to stay on 2.4GHz rather than 5GHz. With the AIMesh node on 22525, client connect and remain connected at 5GHz without issue. I have tried every version and am not sure if others see similar behavior. My router and mesh node are ethernet backhauled.
 
@heysoundude, see below for one possible link.

 
Can anybody point me in the direction of resources to learn about the differences between 3004 and 3006 versions?
(are they linux kernel related? a move from k4.x to k6.x, for instance?)
In a nutshell, the newer 3006 versions enable the new "extended" or "Pro" features that Asus is introducing: configurable VLANs, etc.

For more details head over to the (mostly) Beta (referred to as 9.0.0.6 series), sometimes regular Release release versions (referred to as 3.0.0.6 series), over in the AsusWRT-Official release side of this forum, you will quickly find discussions of the various models and firmware that support these newer features.
 
Last edited:
This firmware hasn't been out for 24 hours yet. :confused: Do you have a USB drive attached to the router? Monitor the size of the networkmap process using top.
Thanks. Had the same issue on alpha so that’s where I got 20% day. Not happening on 388.2.

No USB. no scripts. Minimum changes from defaults. New / clean setup on 388.2

Turned up logging and noticed a load of channel related errors on 5G so I changed from fixed channel (36) to auto on 5G and rebooted and it looks to have resolved the issue.

Will monitor it.

The errors spamming my log were these - made it obvious there was something not right with my 5G wifi

Code:
Jul 27 22:41:38 acsd: eth6: Selecting 5g band ACS policy
Jul 27 22:41:38 acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info
Jul 27 22:41:41 acsd: eth6: Selecting 5g band ACS policy
Jul 27 22:41:41 acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info
Jul 27 22:41:44 acsd: eth6: Selecting 5g band ACS policy
Jul 27 22:41:44 acsd: acs_init_run(1111): acs_start eth6 cannot select chanspec with the wrong info
Jul 27 22:41:47 acsd: eth6: Selecting 5g band ACS policy
 
Last edited:
Can anybody point me in the direction of resources to learn about the differences between 3004 and 3006 versions?
(are they linux kernel related? a move from k4.x to k6.x, for instance?)
Updating the Linux kernel is impossible on these routers, the kernel they ship with is the only kernel they will ever run as it's tied to Broadcom's SDK.
 
Bruh... just loaded the alpha... LOL.
 
But those watchdog spamming events are the first time I'm seeing them.
It means the router isn't aware that your DDNS is up to date, so it gets re-started by the watchdog. What's in your ddns-start script?
 
It means the router isn't aware that your DDNS is up to date, so it gets re-started by the watchdog. What's in your ddns-start script?

Code:
 inadyn --once -f "/jffs/inadyn.conf" -e "/sbin/ddns_custom_updated 1" --continue-on-error "/sbin/ddns_custom_updated 1"

Haven't change it from the latest stable.

Edit - and I can confirm that the A record on cloudflare is correctly and successfully updated.

Edit 2 - even if I comment that inadyn line, ddns-start keeps being called every 30 seconds with my IP as arg
 
Last edited:
Edit 2 - even if I comment that inadyn line, ddns-start keeps being called every 30 seconds with my IP as arg
This is normal. If your ddns update does not set the ddns_updated nvram to 1, then the watchdog is going to call it again. This is what the "-e "/sbin/ddns_custom_updated 1"" parameter is for, it sets the variable to 1 to inform the watchdog that the update was completed.

What's the content of ddns_updated?

Code:
nvram get ddns_updated

Also, try enabling debugging in inadyn to confirm it does not exit with an error (some providers can incorrectly return a "200 OK" but contain an error message, which will confuse inadyn). Add this:

Code:
--loglevel=debug

Then review the content of syslog after the next update.
 
Channel utilisation was not working properly on wifi SoC that use the WL interface, only on the more modern interfaces that use DHD. It was permanently reporting 100%, therefore it was disabled from these unsupported wifi interfaces. The RT-AX86U uses different Wifi chips for the 2.4 GHz and the 5 GHz, only the 5 GHz is supported. That's why it's showing on the 5 GHz but not on the 2.4 GHz. This is working as intended.

And what about the RT-AX58U? From what I could tell, 2.4 GHz utilization does report accurately and not stuck at 100% like the RT-AX86U
 
And what about the RT-AX58U? From what I could tell, 2.4 GHz utilization does report accurately and not stuck at 100% like the RT-AX86U
I haven't tested that specific model. The reports of invalid values were all happening on wl-based radios, so I assumed that all wl-based radios were equally affected. It's possible that the RT-AX58U, being based on a newer SDK, might properly support it even on that older API. I will need to confirm that.
 
This is normal. If your ddns update does not set the ddns_updated nvram to 1, then the watchdog is going to call it again. This is what the "-e "/sbin/ddns_custom_updated 1"" parameter is for, it sets the variable to 1 to inform the watchdog that the update was completed.

What's the content of ddns_updated?

Code:
nvram get ddns_updated

Also, try enabling debugging in inadyn to confirm it does not exit with an error (some providers can incorrectly return a "200 OK" but contain an error message, which will confuse inadyn). Add this:

Code:
--loglevel=debug

Then review the content of syslog after the next update.
Thanks for the help and explanation.
nvram var has the value of 1, which is correct.

Regarding debug mode, I've reviewed the logs line by line and everything is correct. It returns a 200 OK https response, with no error attached.
It also compares my IP with the IP on that cloudflare hosted domain, and it sees that they both are the same.
Then, the nvram var is correctly populated with 1. Process completed, everything went fine, and then, after 30 seconds, ddns watchdog is called again.

@RMerlin I just sent you a pm (for the sake of private log content) with a pastebin link with the unfiltered logs. For me, everything's ok.
 
Last edited:
Thanks for the help and explanation.
nvram var has the value of 1, which is correct.

Regarding debug mode, I've reviewed the logs line by line and everything is correct. It returns a 200 OK https response, with no error attached.
It also compares my IP with the IP on that cloudflare hosted domain, and it sees that they both are the same.
Then, the nvram var is correctly populated with 1. Process completed, everything went fine, and then, after 30 seconds, ddns watchdog is called again.

@RMerlin I just sent you a pm (for the sake of private log content) with a pastebin link with the unfiltered logs. For me, everything's ok.

Also noticed the same behaviour since alpha 388.4 alpha1 even if ddns_updated was set at 1.
I disabled custom ddns for now and changed to single server entry with no issues.
 
Status
Not open for further replies.

Similar threads

Sign Up For SNBForums Daily Digest

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