Beta Asuswrt-Merlin 386.7 Beta is now available

[kernol]

... Basically you are enlarging (not in a clean way) the partition with 386.7, and reducing it back with 386.5 ...

As I recall - about 2 years ago - we had a similar issue on the RT-AC86U with a changed jffs partition layout introduced by Asus !
https://www.snbforums.com/threads/asuswrt-merlin-384-19-is-now-available.65801/

Anyway - pleased the problem has been properly identified - and trust it will be committed to institutional memory by Asus this time .

 

[Ersan]

After clean-upgrading my AC88U I'm no longer able to reach wireless devices connected to the 5GHz band.

Ping 5GHz->Wired OK
Ping Wired->5GHz OK
Ping Wired->Wired OK
Ping 5GHz->2.4GHz OK
Ping 2.4GHz->2.4GHz OK
Ping 5GHz->5GHz / Wired -> 5GHz / 2.4GHz -> 5GHz:

Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down

Edit: After rebooting the router twice it started working again, shrug.

 

[RMerlin]

So it was partition size/location causing the issues. When will beta 2 drop?

Probably in a few days, no established ETA. It will depend on when I've had time to go through the other reported issues from beta 1.

 

[jsbeddow]

As I recall - about 2 years ago - we had a similar issue on the RT-AC86U with a changed jffs partition layout introduced by Asus !
https://www.snbforums.com/threads/asuswrt-merlin-384-19-is-now-available.65801/

Anyway - pleased the problem has been properly identified - and trust it will be committed to institutional memory by Asus this time .

Really odd, as I am surprised that I seem to be the only one reporting issues with this 386.7 cycle (Alpha and Beta 1) on an RT-AC86U that may possibly be related to this newly discovered JFFS upgrade glitch, but I was surprised to see that my model isn't in the affected list.

Each time I attempt the move from 386.5_2 to any of the 386.7 versions, my currently installed amtm scripts still run, but something is very wrong with Entware, as no updates can be applied, and no re-installs or upgrades of the installed scripts can be completed (neither the normal "u" updates, or forced re-installs "uu" will succeed). I have tried formating JFFS on the 386.7 and starting over with the scripts (even after fully formating my USB attached SSD), and still no go on installing any scripts under those conditions. I can move back to 386.5_2 and everything still works: installs go fine, I can restore my backup JFFS partion and all is good again. The only thing that I haven't had time for is a full factory reset under 386.7 with manual input of all the settings, then a re-installation of all the amtm scripts.

I am attaching some screenshots in case anyone (perhaps @thelonelycoder ) can spot the source of my issues.

 

[L&LD]

Maybe wait for Beta 2/Release before trying a nuclear reset with manual installation and configuration. Don't forget to format the USB drive on a PC to NTFS before inserting it back into the router too.

 

[heysoundude]

Really odd, as I am surprised that I seem to be the only one reporting issues with this 386.7 cycle (Alpha and Beta 1) on an RT-AC86U that may possibly be related to this newly discovered JFFS upgrade glitch, but I was surprised to see that my model isn't in the affected list.

Each time I attempt the move from 386.5_2 to any of the 386.7 versions, my currently installed amtm scripts still run, but something is very wrong with Entware, as no updates can be applied, and no re-installs or upgrades of the installed scripts can be completed (neither the normal "u" updates, or forced re-installs "uu" will succeed). I have tried formating JFFS on the 386.7 and starting over with the scripts (even after fully formating my USB attached SSD), and still no go on installing any scripts under those conditions. I can move back to 386.5_2 and everything still works: installs go fine, I can restore my backup JFFS partion and all is good again. The only thing that I haven't had time for is a full factory reset under 386.7 with manual input of all the settings, then a re-installation of all the amtm scripts.

I am attaching some screenshots in case anyone can spot the source of my issues.

maybe the author of this (amtm/diversion - @thelonelycoder ) should be tagged in your post ^ so they can have a look?

 

[RMerlin]

Really odd, as I am surprised that I seem to be the only one reporting issues with this 386.7 cycle (Alpha and Beta 1) on an RT-AC86U that may possibly be related to this newly discovered JFFS upgrade glitch, but I was surprised to see that my model isn't in the affected list.

The issue for the affected models was they were moved to a new SDK, which didn't build the correct partition table. This is why I know which exact models were affected in addition to the reported RT-AX86U.

The RT-AC86U SDK hasn't changed, so it's definitely not affected by the same issue. The JFFS partition size is the same with 386.5_2 and 386.7 beta 1.

admin@RT-AC86U-4B70:/tmp/home/root# cat /proc/mtd | grep mtd9
mtd9: 02f00000 00020000 "misc2"

admin@RT-AC86U-4B70:/tmp/home/root# cat /proc/mtd | grep mtd9
mtd9: 02f00000 00020000 "misc2"

Based on your error message, the problem is your default search path is not correct, and you have a script trying to call "sh" without specifying the full search path. This causes the wrong sh executable to be launched (the Broadcom utility instead of the Ash shell).

 

[L&LD]

@RMerlin, that is interesting to know about the move to a newer SDK.

I didn't know that happened with Asus routers (I thought they stayed at their shipped SDK, somewhat like their CFE version).

Is this something that has happened regularly before? Is this a one-off for these specific models?

Or, should we be expecting more of this in the future?

Just thinking about the future and how cautious we should be when new SDK - firmware is released.

 

[RMerlin]

Is this something that has happened regularly before? Is this a one-off for these specific models?

It's rare, but it happened in the past. The RT-N66U went from SDK 5 to SDK 5.110, and then SDK 6.34 (as 5.110 has a lot of wifi issues with it).

Asus also experimented with moving the RT-AC87U from SDK 6.37 to SDK 7.xx, but dropped the project as it introduced a number of issues.

In the RT-AX86U/AX68U/AXE11000/AC68U_V4 it's a fairly minor update however, but Asus added it as a new SDK rather than patch on top of the existing SDK for these models. I don't know the reason for the SDK change or why it was done in parallel - maybe they needed both SDKs for a transition period. In doing so the new SDK was missing a patch that was present on the older SDK, which they reapplied, and sent me updated files with the patch applied.

 

[jsbeddow]

The issue for the affected models was they were moved to a new SDK, which didn't build the correct partition table. This is why I know which exact models were affected in addition to the reported RT-AX86U.

The RT-AC86U SDK hasn't changed, so it's definitely not affected by the same issue. The JFFS partition size is the same with 386.5_2 and 386.7 beta 1.

admin@RT-AC86U-4B70:/tmp/home/root# cat /proc/mtd | grep mtd9
mtd9: 02f00000 00020000 "misc2"

admin@RT-AC86U-4B70:/tmp/home/root# cat /proc/mtd | grep mtd9
mtd9: 02f00000 00020000 "misc2"

Based on your error message, the problem is your default search path is not correct, and you have a script trying to call "sh" without specifying the full search path. This causes the wrong sh executable to be launched (the Broadcom utility instead of the Ash shell).

Thanks, I appreciate the reply and suggestions. Glad to hear it cannot be the jffs issues that affect the limited set of newer models.

I still find it odd that everything works fine under 386.5_2, and it breaks moving to any 386.7 version. On top of that, I have never tinkered with modifications to the (search) paths, so if that was done, it was done by one of the amtm scripts that I use. I suspect I will have to do a full reset to fix this.

 

[AlFreid]

Did a dirty upgrade from 386.5_2 to 386.7 beta 1 - RT-AX58U main router, RT-AX68U AIMesh node. So far had three random restarts - rock solid before. Main reason to try beta was that RT-AX68U as AIMEsh node kept dropping 5GHZ band after few days no matter what config setting I tried.

Log:

Jun 15 05:04:09 ntpd: Initial clock set
Jun 15 05:04:09 rc_service: ntpd_synced 2992:notify_rc restart_diskmon
Jun 15 05:04:09 disk_monitor: Finish
Jun 15 05:04:09 start_ddns: update WWW.ASUS.COM update@asus.com, wan_unit 0
Jun 15 05:04:09 disk_monitor: be idle
Jun 15 05:04:09 start_ddns: Clear ddns cache.
Jun 15 05:04:09 start_ddns: Start Inadyn(10).
Jun 15 05:04:09 inadyn[3012]: In-a-dyn version 2.9.1 -- Dynamic DNS update client.
Jun 15 05:04:09 inadyn[3012]: /etc/inadyn.conf:3: unexpected token '='
Jun 15 05:04:09 inadyn[3012]: Parse error in /etc/inadyn.conf
Jun 15 05:04:09 inadyn[3012]: Error code 74: Missing .conf file
Jun 15 05:04:10 httpd: Succeed to init SSL certificate...80
Jun 15 05:04:14 cfg_server: event: wl_chanspec_changed_action
Jun 15 05:04:14 cfg_server: skip event due no re
Jun 15 05:04:16 kernel: SHN Release Version: 2.0.2 d2ff630
Jun 15 05:04:16 kernel: UDB Core Version: 0.2.20
Jun 15 05:04:16 kernel: sizeof forward pkt param = 192
Jun 15 05:04:16 BWDPI: fun bitmap = 47f
Jun 15 05:04:20 kernel: Archer TCP Pure ACK Enabled
Jun 15 05:04:20 rc_service: udhcpc_wan 2904:notify_rc stop_samba
Jun 15 05:04:20 rc_service: udhcpc_wan 2904:notify_rc start_samba
Jun 15 05:04:20 rc_service: waitting "stop_samba" via udhcpc_wan ...
Jun 15 05:04:20 Samba_Server: smb daemon is stopped
Jun 15 05:04:21 cfg_server: event: wl_chanspec_changed_action
Jun 15 05:04:21 dhcp_client: bound 68.4.152.190/255.255.248.0 via 68.4.152.1 for 86400 seconds.
Jun 15 05:04:21 cfg_server: skip event due static chan: wl1_chanspec:36/80/wl2_chanspec:0
Jun 15 05:04:42 crond[1998]: time disparity of 2163299 minutes detected
Jun 15 05:04:46 wlceventd: wlceventd_proc_event(505): eth6: Auth 940:0D:5F:49:B1, status: Successful (0)
Jun 15 05:04:46 wlceventd: wlceventd_proc_event(534): eth6: Assoc 940:0D:5F:49:B1, status: Successful (0)
Jun 15 05:06:33 wlceventd: wlceventd_proc_event(534): eth6: Assoc 5E:A3:9B:79:3A:C4, status: Successful (0)
Jun 15 05:06:36 wlceventd: wlceventd_proc_event(534): eth6: Assoc E6:C70:B3:B2:24, status: Successful (0)
Jun 15 05:06:37 wlceventd: wlceventd_proc_event(534): eth6: Assoc 7E:9C:47:29:20:20, status: Successful (0)

 

[Zirescu]

Beta 1 appears to have resolved my constant issues with DNS over TLS on my RT-AC86U!! Usually within an hour of enabling it I'd loose most DNS resolution and have to disable it again. So far 24 hours and no problems. Hopefully it stays working after release. thx

Apparently I jinxed it - dropped off last evening. Had to disable and enable it again to restore functionality. My wife thought I had blocked her Internet (lol).

 

[RMerlin]

I still find it odd that everything works fine under 386.5_2, and it breaks moving to any 386.7 version. On top of that, I have never tinkered with modifications to the (search) paths, so if that was done, it was done by one of the amtm scripts that I use. I suspect I will have to do a full reset to fix this.

I remember that particular issue was discussed in the past in the Add-ons sub-forum.

You shouldn't need a factory default reset to fix that. At the very least I would suggest you reinstall Entware.

 

[Damit1]

So for the first time, my syslog got flushed with kernel COMSOLE entries and devices have kicked out of WiFi.
For a minute, SSID is gone and then back.
Anything known related maybe with latest GPL?

Thank you

 

[dave14305]

Thanks, I appreciate the reply and suggestions. Glad to hear it cannot be the jffs issues that affect the limited set of newer models.

I still find it odd that everything works fine under 386.5_2, and it breaks moving to any 386.7 version. On top of that, I have never tinkered with modifications to the (search) paths, so if that was done, it was done by one of the amtm scripts that I use. I suspect I will have to do a full reset to fix this.

See if any profile files are modifying your PATH unintentionally. And any extra sh binaries. Entware should link to /bin/sh.

/usr/bin/find / -name profile* -exec /bin/grep -HE "\bPATH *=" {} +
/usr/bin/find / -name sh -exec ls -l {} +

 

[jsbeddow]

I remember that particular issue was discussed in the past in the Add-ons sub-forum.

You shouldn't need a factory default reset to fix that. At the very least I would suggest you reinstall Entware.

Well, that was worth a shot, but didn't succeed: I did another round of first formatting the jffs partition, wipe and format of the attached USB SSD drive (first as NTFS on Windows, then as ext4 with journaling from the amtm fd utility). Same results: I can't even get amtm to install Entware (or Diversion with Entware), as it fails every time with "Entware (aarch64) install failed".

I know this isn't directly your (@RMerlin) problem, and I should probably be posting this in the Add-Ons subforum (with attention @thelonelycoder ), but just wanted to report back my results.

 

[bluepoint]

Well, that was worth a shot, but didn't succeed: I did another round of first formatting the jffs partition, wipe and format of the attached USB SSD drive (first as NTFS on Windows, then as ext4 with journaling from the amtm fd utility). Same results: I can't even get amtm to install Entware (or Diversion with Entware), as it fails every time with "Entware (aarch64) install failed".

I know this isn't directly your (@RMerlin) problem, and I should probably be posting this in the Add-Ons subforum (with attention @thelonelycoder ), but just wanted to report back my results.

Have you tried using a different SSD or USB drive?

 

[RMerlin]

Thanks for the test, I will see tomorrow if I can (blindly) reproduce it on my own GT-AX11000, by monitoring the nvram state. My initial guess is that the nvram is applied, but not written back to flash before the reboot.

Aura RGB state will be tied to the separate option to enable/disable LEDs on the System page. At boot time when the router enables/disables LEDs following that setting, it will also toggle the state of AuraRGB to follow itself. That means currently you can't disable AuraRGB while keeping all LEDs enabled, for instance.

admin@GT-AX11000-2470:/tmp/home/root# nvram get aurargb_enable
1
admin@GT-AX11000-2470:/tmp/home/root# nvram set aurargb_enable=0
admin@GT-AX11000-2470:/tmp/home/root# nvram get aurargb_enable
0
admin@GT-AX11000-2470:/tmp/home/root# service restart_leds

Done.
admin@GT-AX11000-2470:/tmp/home/root# nvram get aurargb_enable
1

I'm not sure if it will be possible to decouple the two. Part of the implementation is mine, but other portions are based on backend code from Asus. I'd have to do more investigation.

 

[jsbeddow]

Have you tried using a different SSD or USB drive?

No, I suppose it is worth a try. Odd though, as I switched to a "real" SSD to avoid issues with cheap flash drives failing (which I have had happen in the past).

 

[SomeWhereOverTheRainBow]

Aura RGB state will be tied to the separate option to enable/disable LEDs on the System page. At boot time when the router enables/disables LEDs following that setting, it will also toggle the state of AuraRGB to follow itself. That means currently you can't disable AuraRGB while keeping all LEDs enabled, for instance.

admin@GT-AX11000-2470:/tmp/home/root# nvram get aurargb_enable
1
admin@GT-AX11000-2470:/tmp/home/root# nvram set aurargb_enable=0
admin@GT-AX11000-2470:/tmp/home/root# nvram get aurargb_enable
0
admin@GT-AX11000-2470:/tmp/home/root# service restart_leds

Done.
admin@GT-AX11000-2470:/tmp/home/root# nvram get aurargb_enable
1

I'm not sure if it will be possible to decouple the two. Part of the implementation is mine, but other portions are based on backend code from Asus. I'd have to do more investigation.

@RMerlin , I can already tell you the decoupling would have to mainly be done upstream by Asus. This seems to be their intended behavior. I tested it earlier today on stock and can confirm the behaviors are identical.