Beta Asuswrt-Merlin 3004.388.4 beta is now available

[maghuro]

Beta 3 - seeing strange behavior on my 5ghz wireless.
On main router, both 2.4g and 5g wireless are up. On my aimesh node, only the 2.4g comes up. Tried with different bandwidth and channels, and same behavior.

HOWEVER, on guest wifi 1 (which is propagated on aimesh nodes), both 2.4g and 5g are up on both main and aimesh router. But only on guest network.
On regular wifi, on the aimesh node, only the 2.4 shows up.

Edit - screenshot attached

 

[TheLyppardMan]

While copying those files is fine for backup purposes I would strongly discourage people from restoring nvram variables that way because it bypasses the router's API and cache. It's possible you will corrupt the other nvram variables. You should use the official API, nvram set. For example:

nvram set custom_clientlist="$(cat custom_clientlist.txt)"
nvram commit

I don't understand what the code you have provided actually does, so would you mind expanding on this a bit please? In particular, I don't understand how it knows where to find the backup and what is the meaning of ="$(cat custom_clientlist.txt)"

 

[garysteel]

Help.. like my post previously.. 2 xt12’s one wired backhaul… when i update man xt12 unit to this beta all ok.. i then update the node , it updates but everything that links through it dies… i have to revert to 388.2.2 for the node and all works again.

Why is this happening with these beta’s i cannot even access the xt12 node to check operation mode.. do ‘t really want to disconnect.. factory reset and hard wire clise to main unit on a whim as its a ball ache.. any i sight welcome

Thx

Beta 3 finally resolves the issue with the node.

 

[octopus]

Updated my two roters and working fine.

Still mounting my ssd-disk remains unmounted have to manually turn it off/on to munt it.

Tested @Jeffrey Young suggestion without any success

echo "- - -" > /sys/class/scsi_host/host0/scan --> where <n> is the host number.

May  5 07:05:17 kernel: usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd

Aug 16 11:13:25 kernel: usb 2-1: USB disconnect, device number 2
Aug 16 11:13:25 kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Aug 16 11:13:25 kernel: sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR drive

Aug 16 11:13:31 kernel: usb 2-1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
Aug 16 11:13:31 kernel: scsi host0: uas
Aug 16 11:13:31 kernel: scsi 0:0:0:0: Direct-Access     CT250MX5 00SSD1           0    PQ: 0 ANSI: 6
Aug 16 11:13:31 kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB)
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Write Protect is off
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Aug 16 11:13:31 kernel:  sda: sda1
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Attached SCSI disk

Thank you for beta3!

 

[STRUZZIN]

All AX58U are working great so far!
Thank You

 

[MDM]

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).

Can confirm it is fixed now!
But a weird thing is, newer saw it blink as showing activity, all other do...

 

[Jeffrey Young]

Updated my two roters and working fine.

Still mounting my ssd-disk remains unmounted have to manually turn it off/on to munt it.

Tested @Jeffrey Young suggestion without any success

echo "- - -" > /sys/class/scsi_host/host0/scan --> where <n> is the host number.

May  5 07:05:17 kernel: usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd

Aug 16 11:13:25 kernel: usb 2-1: USB disconnect, device number 2
Aug 16 11:13:25 kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Aug 16 11:13:25 kernel: sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR drive

Aug 16 11:13:31 kernel: usb 2-1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
Aug 16 11:13:31 kernel: scsi host0: uas
Aug 16 11:13:31 kernel: scsi 0:0:0:0: Direct-Access     CT250MX5 00SSD1           0    PQ: 0 ANSI: 6
Aug 16 11:13:31 kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB)
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Write Protect is off
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Aug 16 11:13:31 kernel:  sda: sda1
Aug 16 11:13:31 kernel: sd 0:0:0:0: [sda] Attached SCSI disk

Thank you for beta3!

Have you tried another USB key?

Your logs says the key is seen. Just not mounted. I had understood that the box did not see your key at all hence why the command to start another hotplug scan.

I had a key that would, every so often, just unmount it self. If your key is seen, but not mounted, try this;

mkdir /mnt/key1 && mount /dev/sda1 /mnt/key1

and see if your key gets mounted.

Still thinking it just might be your key as no one else has committed on this issue.

 

[ColinTaylor]

I don't understand what the code you have provided actually does, so would you mind expanding on this a bit please? In particular, I don't understand how it knows where to find the backup and what is the meaning of ="$(cat custom_clientlist.txt)"

See post #431 and here for more context. custom_clientlist.txt is the name of the backup file you created, if you simply copied the original file it will still be called custom_clientlist. If that backup file is not in the current working directory you need to use the full pathname instead, e.g. /mnt/sda1/Backups/custom_clientlist

 

[harry]

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:

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:

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:

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.

so far great. amazone stick doesn't connect to guest 2 though but works treat on G1. previously wasn't connecting to G1. other than that totally awesome

 

[ZeustheAsus]

What is it about betas that you guys levitate towards, just like being on the bleeding edge? Or that smooth an experience with RMerlin + beta no reason not to?

Just curious

just went from 3.0.0.4 official to latest 388.2 stable (non-ROG, nice to be done with the IMO tacky and bloated gaming UI)

 

[Ripshod]

What is it about betas that you guys levitate towards, just like being on the bleeding edge? Or that smooth an experience with RMerlin + beta no reason not to?

Alphas and Betas have to be fully tested. Being the only network user at my property I'm willing to suffer a few losses to help everyone gain. A project like this needs support, and not just financially. I'm also able to try to replicate problems to try and find a cause, and I can do that without upsetting anyone else.

TL;DR Why not?

 

[MDM]

Beta (alfa) has the newer WiFi driver that solved a ton of issues to me!

 

[ZeustheAsus]

Beta (alfa) has the newer WiFi driver that solved a ton of issues to me!

Can you elaborate, curious!

you were having issues with the latest stable RMerlin, and the beta fixed stuff for you? what the use case?

Alphas and Betas have to be fully tested. Being the only network user at my property I'm willing to suffer a few losses to help everyone gain. A project like this needs support, and not just financially. I'm also able to try to replicate problems to try and find a cause, and I can do that without upsetting anyone else.

TL;DR Why not?

makes sense, I thought lots of users here that chime in on betas require stability though (for tons of clients and/or family not bickering lol)

--

at first I thought something wrong with ethernet connection in the wall with my ps5, but googling realized in standby mode it defaults to 100mbps and when powered up the yellow indicator on that ethernet port (warning!) goes away and get full gigabit. phew! thats pretty cool visibility on the main menu dashboard

 

[MDM]

Can you elaborate, curious!

you were having issues with the latest stable RMerlin, and the beta fixed stuff for you? what the use case?

Nothing to do with Merlin, the drivers are in the GPLs...

And for me it was the 100/160 stability (les false positive, except on thunder ) and clients connection.

 

[Kyjiep]

What is it about betas that you guys levitate towards, just like being on the bleeding edge? Or that smooth an experience with RMerlin + beta no reason not to?

Just curious

just went from 3.0.0.4 official to latest 388.2 stable (non-ROG, nice to be done with the IMO tacky and bloated gaming UI)

Often alpha and beta versions are no less stable than stable releases. In addition, they are the fastest to fix shortcomings and bugs that are present in stable releases, yes, they happen there too. For example, static entries in the ARP, that didn't work in 388.2 - 388.2_2, which for me and many other people was an important flaw, fixed in 388.4 alpha.

 

[ZeustheAsus]

Nothing to do with Merlin, the drivers are in the GPLs...

And for me it was the 100/160 stability (les false positive, except on thunder ) and clients connection.

thanks- in any case, onto greener pastures with this RMerlin (stable or beta) over official fw it seems ya?

Perhaps I'll dive into 'beta land' at end of day

 

[MDM]

thanks- in any case, onto greener pastures with this RMerlin (stable or beta) over official fw it seems ya?

Perhaps I'll dive into 'beta land' at end of day

For me, several Merlin only options is a must!
For others, it is individual...

 

[rwheaton1]

Updated XT12 first then GT-AX11000 Pro. Everything seems to be working.

 

[Dedel66]

amazone stick doesn't connect to guest 2

Amazon stick is connecting here to all guestnets (2.4 and 5.0).

 

[alan6854321]

@RMerlin - There is a problem with Beta3, it keeps restarting the DDNS server every 30 seconds.

I loaded it up this morning and it's been running fine for around 8 hours.
Then I thought I'd test a problem that Beta3 should fix (no DDNS update on WAN reconnect) so I unplugged my WAN connection, waited a few minutes and reconnected.

The WAN came back with the same IP address, so it wasn't a very good test, but ever since then it has been restarting DDNS every 30 seconds with a watchdog timeout every 5 minutes.

Sample from syslog below.

Aug 16 16:49:55 watchdog: start ddns.
Aug 16 16:49:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:50:25 watchdog: start ddns.
Aug 16 16:50:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:50:55 watchdog: start ddns.
Aug 16 16:50:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:51:25 watchdog: start ddns.
Aug 16 16:51:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:51:55 watchdog: start ddns.
Aug 16 16:51:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:52:25 watchdog: start ddns.
Aug 16 16:52:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:52:55 watchdog: start ddns.
Aug 16 16:52:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:53:25 watchdog: start ddns.
Aug 16 16:53:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:53:55 watchdog: start ddns.
Aug 16 16:53:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:54:25 watchdog: DDNS Recover Time reached, recover DDNS Retry.
Aug 16 16:54:25 watchdog: start ddns.
Aug 16 16:54:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:54:55 watchdog: start ddns.
Aug 16 16:54:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:55:25 watchdog: start ddns.
Aug 16 16:55:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:55:55 watchdog: start ddns.
Aug 16 16:55:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:56:25 watchdog: start ddns.
Aug 16 16:56:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:56:55 watchdog: start ddns.
Aug 16 16:56:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:57:25 watchdog: start ddns.
Aug 16 16:57:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:57:55 watchdog: start ddns.
Aug 16 16:57:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:58:25 watchdog: start ddns.
Aug 16 16:58:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:58:55 watchdog: start ddns.
Aug 16 16:58:55 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:59:25 watchdog: DDNS Recover Time reached, recover DDNS Retry.
Aug 16 16:59:25 watchdog: start ddns.
Aug 16 16:59:25 ddns: IP address, server and hostname have not changed since the last update.
Aug 16 16:59:55 watchdog: start ddns.