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.

RMerlin

Asuswrt-Merlin dev
Staff member
Asuswrt-Merlin 3004.388.4 beta is now available. Note that starting with this release, the version numbering scheme was changed to better illustrate that this is based on the 3.0.0.4 code (versus 3.0.0.6 that would be 3006.102.x). Also as mentionned a few months ago, the RT-AX56U is no longer supported as of this release. The last three 388.x releases for that model were already based on unreleased code as Asus never moved that model to the 388 codebase. They have now officially added that model to their End of Life list recently.

August 15th, 2023: Beta 3 is now available. Changes since beta 2:
Code:
a58ac601af (HEAD -> master, origin/master) Updated documentation
afab150ab6 rc: Samba was getting restarted twice in a row in wan_up() due to duplicate code
987521103d qca-ar3k-fw: Added missing bluetooth firmware for XT12
8df077d52f rc: move ovpn nvram reset to init_nvram() to better match upstream
8745bb4eae rc: update ntpd sync events to reflect upstream changes to ntpclient sync events
3a5ea653f6 rc: restart DDNS on WAN interface going up again as before 23588 merge
9e01e85092 shared: ping_target_with_size() child should exit once done
a184dacb11 rc: fix bad merge
d0db77362e Bumped revision to beta 3
3616499f54 HND5.04: fix missing ethctl userspace tool
e401469c2b rc: mount WAN interface before adjusting its MTU


August 4th, 2023: Beta 2 is now available. Changes since beta 1:
Code:
78a92dc997 (HEAD -> master, origin/master) rc: reverted ddns IP check to upstream method; fixed a few bad code merges
6a31004700 rc: re-harmonize with upstream, fixing a few bad merged sections
a6a9a8fd38 rc: reset attempt counter on successful custom DDNS update
3a9f7a5598 rc: set ddns WAN unit variable on successful custom DDNS update
c013705bf1 httpd: only skip querying channel utilization on non-dhd SoC if on SDK 5.02L07P2
3d1c9bf151 Bumped revision to beta 2

Changes since 388.3/388.2_2:

Code:
3004.388.4 (xx-xxx-xxxx)
  - NOTE: In preparation for the new 3.0.0.6 codebase, the version
          string will now start with 3004 or 3006 to match with
          upstream.

  - NOTE: The RT-AX56U is no longer supported, as Asus has put it
          on End-of-Life status, and the previous Asuswrt-Merlin
          388 releases for that model were all based on untested
          code.

  - NEW: Display channel utilisation for supported platforms on the
         Wireless Log page.
  - UPDATED: Merged GPL 388_23588.
  - UPDATED: curl to 8.1.2.
  - UPDATED: OpenVPN to 2.6.5.
  - UPDATED: openssl to 1.1.1u.
  - UPDATED: tor to 0.4.7.13.
  - CHANGED: FTP server will now only support strong ciphers
             in TLS mode.
  - FIXED: QOS Classification showing no Upload data on some
           WAN configurations.
  - FIXED: Radio temperature graphs weren't updating
  - REMOVED: Ethernet port status from the Tools Sysinfo page
             (as this is redundant with Asus' own display
             now available on the networkmap page).


Downloads are here.
Changelog is here.
 
Last edited:
Known issues:
  • Custom DDNS would get constantly re-run (issue related to Dual WAN support, fixed in beta 2)
  • Various Ethernet issues such as WAN failing to connect on boot on newer models (missing ethctl userspace tool, fixed in beta 3)
 
Last edited:

- Answer: QoS. @dave14305
After some debugging, I found that the culprit was QoS. Not sure if QoS only, or FlexQoS.
Between reboots (after upgrading firmware), I had a couple of seconds - in that time, I uninstalled one by one the scripts.
Then I watched closely the logs, and I saw some fail regarding QoS. I then disabled QoS, waited for one more restart, and now it's working flawlessly.

I'm not sure if it's related with QoS or FlexQoS script, which I have installed (and now disabled, because QoS is also disabled), but it did the trick.

Can someone help me debugging and enable ONLY QoS (without FlexQoS) and see if something happens? If not, then install FlexQoS and see if something happens?

Thanks.
 
Last edited:
And happy to see there are plans for (eventual) 3.0.0.6 based releases!
I'm just keeping my options open at this time, as I knew that a future switch to it would require changes to the update process, so I went ahead with the change with this release.

There is no decision made yet regarding 3006_102 as I have yet to see that code to evaluate the efforts involved in supporting it.
 
I'm just keeping my options open at this time, as I knew that a future switch to it would require changes to the update process, so I went ahead with the change with this release.

There is no decision made yet regarding 3006_102 as I have yet to see that code to evaluate the efforts involved in supporting it.

Does 3006_102 include guest network pro and VLAN?
 
Succussfully updated 388.4_alpha1 to 3004.388.4_beta1.
Took a few minutes, no major issues observed...

Will take 50min run and then whole reboot
 
Made a whole system reboot just in case.

Everything performs well.
Hope the 160Mhz woild stick, so far so good.
 
Had to try the latest, of course, thank you very much Merlin *smile*. Looking really good, don't see any problems. Got 3 hours on it since I rebooted after the flash. Very nice so far.
 
Everything's smooth, except this. I'm having this log entry spamming every minute or so. It didn't happen on latest stable.
Note - IP and domain hidden for obvious reasons.
Any thoughts?
Code:
Jul 27 01:55:03 GT-AX6000 watchdog: start ddns.
Jul 27 01:55:03 GT-AX6000 ddns: update CUSTOM , wan_unit 0
Jul 27 01:55:03 GT-AX6000 ddns: Clear ddns cache.
Jul 27 01:55:03 GT-AX6000 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX)
Jul 27 01:55:03 GT-AX6000 inadyn[27641]: In-a-dyn version 2.10.0 -- Dynamic DNS update client.
Jul 27 01:55:03 GT-AX6000 inadyn[27641]: Guessing DDNS plugin 'default@cloudflare.com' from 'cloudflare.com'
Jul 27 01:55:03 GT-AX6000 rc_service: watchdog 2856:notify_rc stop_aae
Jul 27 01:55:03 GT-AX6000 rc_service: watchdog 2856:notify_rc start_mastiff
Jul 27 01:55:03 GT-AX6000 rc_service: waitting "stop_aae" via watchdog ...
Jul 27 01:55:03 GT-AX6000 custom_script: Running /jffs/scripts/service-event (args: stop aae)
Jul 27 01:55:03 GT-AX6000 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 27 01:55:03 GT-AX6000 inadyn[27641]: Update forced for alias my.domain, new IP# XX.XX.XX.XX
Jul 27 01:55:04 GT-AX6000 custom_script: Running /jffs/scripts/service-event (args: start mastiff)
Jul 27 01:55:04 GT-AX6000 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 27 01:55:04 GT-AX6000 Mastiff: init
Jul 27 01:55:10 GT-AX6000 inadyn[27641]: Updating cache for my.domain
Jul 27 01:55:10 GT-AX6000 ddns: Completed custom ddns update
 
Does the potentially unexpected fatal signal have anything to do with the watchdog events?

Jul 26 22:28:02 rc_service: watchdog 2689:notify_rc stop_aae
Jul 26 22:28:02 rc_service: watchdog 2689:notify_rc start_mastiff
Jul 26 22:28:02 rc_service: waitting "stop_aae" via watchdog ...
Jul 26 22:28:03 Mastiff: init
Jul 26 22:28:27 kernel: potentially unexpected fatal signal 11.
Jul 26 22:28:27 kernel: CPU: 1 PID: 3286 Comm: dcd Tainted: P O 4.19.183 #1
Jul 26 22:28:27 kernel: Hardware name: GTAXE16000_2GB (DT)
Jul 26 22:28:27 kernel: pstate: 80030010 (Nzcv q A32 LE aif)
Jul 26 22:28:27 kernel: pc : 000000000002a110
Jul 26 22:28:27 kernel: lr : 000000000002a2ac
Jul 26 22:28:27 kernel: sp : 00000000ff82f060
Jul 26 22:28:27 kernel: x12: 00000000000a3120
Jul 26 22:28:27 kernel: x11: 00000000f69fda88 x10: 0000000000083794
Jul 26 22:28:27 kernel: x9 : 0000000000000000 x8 : 0000000000000003
Jul 26 22:28:27 kernel: x7 : 0000000000000072 x6 : 00000000f69fd860
Jul 26 22:28:27 kernel: x5 : 0000000000000037 x4 : 000000000000069e
Jul 26 22:28:27 kernel: x3 : 0000000000000000 x2 : 00000000f69fda88
Jul 26 22:28:27 kernel: x1 : 000000000000000d x0 : 0000000000000000
Jul 26 22:28:33 rc_service: watchdog 2689:notify_rc stop_aae
Jul 26 22:28:33 rc_service: watchdog 2689:notify_rc start_mastiff
Jul 26 22:28:33 rc_service: waitting "stop_aae" via watchdog ...
Jul 26 22:28:34 Mastiff: init
Jul 26 22:29:04 rc_service: watchdog 2689:notify_rc stop_aae
Jul 26 22:29:04 rc_service: watchdog 2689:notify_rc start_mastiff
Jul 26 22:29:04 rc_service: waitting "stop_aae" via watchdog ...
Jul 26 22:29:05 Mastiff: init
 
GT-AX6000 still has issue introduced with alpha1 where 2.5 GB LAN LED remains lit when LEDs are disabled. Not a big deal, but rather just following up after beta1 install...
 
Can anyone guide me on where I find the domain key and fullchain cert files after the update?

it used to be in this location:
"jffs/.le/DDNSDomain/domain.key"
"jffs/.le/DDNSDomain/fullchain.cer"

But now I can't seem to find jffs/.le/ directory after the update.
 
Nvm, it's still in the same location, just can't be seen in WinSCP anymore? (A hidden directory?)

/jffs/.le/It also now lists my DDNS as DDNSNAME_ecc. Not sure where the _ecc came from, but seems I got my answer for now...
 
AX86U Pro. For 2.4 Utilization is not shown in the formatted display as in the alpha1 version. In Wireless Log dump it shows real value
 
I can also confirm GT-AX6000 has issue with 2.5G LAN LED remaining lit when LEDs are disabled.
But LED is Off if link is down (PC shutdown).

BTW Utilization works well for the GT-AX6000.

And for now (7+ h) my phone POCO F3 (MIUI 14 - Android 13), hasn't dropped from WiFi as it did before (160 MHz enabled). No WiFi settings helped...
All other clients do not drop (AC or AX), including my LapTop AX210 card at full speed.
 
Last edited:
AX86U Pro. For 2.4 Utilization is not shown in the formatted display as in the alpha1 version. In Wireless Log dump it shows real value
That's normal. The 2.4 GHz radio of that router does not support reporting channel utilization.

Does the potentially unexpected fatal signal have anything to do with the watchdog events?
dcd crashes has been present in Asuswrt for years. Trend Micro can't be bothered fixing it.
 
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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