Beta Asuswrt-Merlin 386.7 Beta is now available

[SomeWhereOverTheRainBow]

I can't test it because my GT-AX11000 has no RGB. Can you see before and after the reboot what is the current value for aurargb_disable?

nvram get aurargb_enable

after reboot

GT-AX11000-9600:/tmp/home/root# nvram get aurargb_enable
1

still working

 

[RMerlin]

@RMerlin

Same IP assignments in Guest #2 is still present in Beta1, it seems cosmetic as they are leased the right IP's according to Network map and the DHCP lease entries. These guest clients are manually assigned IP's in the DHCP server.View attachment 41760

RT-AX88U

Still can't reproduce it. Please send me a PM with the output from the following commands:

Think I found it. Indexing error introduced recently when a fix was applied for invalid arp entries, didn't happen here because I don't have additional clients connected as non-guest on the same radio.

 

[RMerlin]

after reboot

GT-AX11000-9600:/tmp/home/root# nvram get aurargb_enable
1

still working

Did you disable it before the reboot?

 

[SomeWhereOverTheRainBow]

Did you disable it before the reboot?

I can see. Haven't messed with it overall. Hold tight.

 

[SomeWhereOverTheRainBow]

Did you disable it before the reboot?

After reboot..... with LED off....

GT-AX11000-9600:/tmp/home/root# nvram get aurargb_enable
1

 

[SomeWhereOverTheRainBow]

@RMerlin here is disabled

GT-AX11000-9600:/tmp/home/root# nvram show | grep aura
size: 85680 bytes (45392 left)
aurargb_enable=1
aurargb_val=255,0,0,1,0,0
aurasync_enable=1
aurasync_set=0
aurasync_val=

 

[SomeWhereOverTheRainBow]

@RMerlin

here is enabled:

nvram show | grep aura
size: 85680 bytes (45392 left)
aurargb_enable=1
aurargb_val=255,0,0,1,0,0
aurasync_enable=1
aurasync_set=0
aurasync_val=

identical

 

[RMerlin]

@RMerlin here is disabled

GT-AX11000-9600:/tmp/home/root# nvram show | grep aura
size: 85680 bytes (45392 left)
aurargb_enable=1
aurargb_val=255,0,0,1,0,0
aurasync_enable=1
aurasync_set=0
aurasync_val=

So for some reason either that variable gets reset back to 1, or the change doesn't get written to flash. What happens if you manually disable it?

nvram set aurargb_enable=0

nvram commit
reboot

 

[SomeWhereOverTheRainBow]

So for some reason either that variable gets reset back to 1, or the change doesn't get written to flash. What happens if you manually disable it?

nvram set aurargb_enable=0

nvram commit
reboot

So the nvram variable disables it. so does the GUI, but using the GUI doesn't change the nvram variable away from 1 to 0. However, Your option changes disables LED when the nvram is set to 0 over ssh and reboot.

 

[SomeWhereOverTheRainBow]

@RMerlin , the same must be said for those who have the value set to zero already. i.e. enabling it in the gui turns it on, but doesnt change the nvram variable to 1 like it should if the value is already set to zero.

 

[SomeWhereOverTheRainBow]

@RMerlin ironically the lights on the front are still turned on when the RGB is disabled (however when i disable in the gui the front lights turn off and the RGB is off, if i turn on the front lights turn on yet the RGB is off). Are we sure we are dealing with all the variables at play?

 

[SomeWhereOverTheRainBow]

Let's recap for those not paying attention.

On my GTAX11000

GUI does not change the NVRAM value toggling the option even across reboots (but somehow the front lights and rgb are disabled across reboots.)

Changing the nvram value from 1 to 0 manually disable the RGB lights after reboot without changing the front lights across reboots. Value remains zero after reboots.

Setting the value to 1 changes the RGB back to ON after reboot.

 

[RMerlin]

All: The issue causing corruption for the JFFS partition on the RT-AX86U has been found, and a fix provided by Asus has been tested with success.

However, the following models were also affected by the same issue: RT-AX68U, GT-AXE11000, and possibly the RT-AC68U_V4 (unconfirmed on that one).

If you have any of these three models, and you are running either 386.7 Alpha 1 or Beta 1, I strongly recommend that you take the following steps:

1) Make a backup of your settings and JFFS partition (same page where you can make a backup of your settings)
2) When Beta 2 comes out, after flashing it, reformat your JFFS partition
3) After the reboot with reformat, restore your JFFS backup, and reboot again.

If the device fails to boot with Beta 2, then do a factory default reset. After booting and configuring your basic settings (wifi/password/etc...) then format JFFS, reboot, then re-import both settings and JFFS, and reboot.

The issue is related to the layout of the flash partitions which had changed. The fix will restore the original partition layout, however there is a strong chance that this can lead to JFFS corruption if you were running with the incorrect partition layout, hence the need to use a jffs backup.

 

[RMerlin]

Let's recap for those not paying attention.

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.

 

[alan6854321]

@RMerlin -what about those of us who upgraded from the last release and didn't have any problems with the jffs partition?

Are we OK to just leave things be?
(Running a RT-AX86S)

 

[kernol]

@RMerlin -what about those of us who upgraded from the last release and didn't have any problems with the jffs partition?

Are we OK to just leave things be?
(Running a RT-AX86S)

I did not have the JFFS problem on my RT-AX86U when first applying Beta1 [see my prior post] - but in the days that followed I grew "uncomfortable" with the Beta [log issues and some periodic wireless weirdness] - so I decided to revert to 386.5_2 [the best firmware I've ever used since climbing aboard the Merlin Bus 4+ years ago].

That's when I hit the JFFS corrupted trick - would not mount even if it was still there - so had to format JFFS and restore from my 386.5_2 backups taken before I first applied the Beta.

Having arrived back at 386.5_2 - I went on to clear nvram and fully reset the main router - and then restored both my 386.5_2 settings and JFFS.
Rock steady stability ever since with clean logs .

My sympathies to the Maestro - some curved balls thrown into the mix by Asus - but about to be back on track as always {ThumbsUp}.

 

[XIII]

asuswrt LTS edition

What’s that?

(I know what LTS usually stands for, but not in this context)

 

[JohnSmith]

Do you have the same IP's in your guest #2 clients as shown in the wireless log?

As a matter of fact I do. It shows they are all the same IP addresses, but when I go to "Guest Network | YazFi" tab (as I use the YazFi addon), the area "Connected guests" shows the IP addresses with MAC addresses associated to each IOT device, and they are all different.

 

[RMerlin]

Are we OK to just leave things be?
(Running a RT-AX86S)

You should also follow these instructions even if things seem fine. A corrupted filesystem might not exhibit problems right away.

o I decided to revert to 386.5_2 [the best firmware I've ever used since climbing aboard the Merlin Bus 4+ years ago].

That's when I hit the JFFS corrupted trick

That's how I actually finally managed to reproduce it. Downgrade, seemed ok, re-upgraded - partition failed to mount.

Re-downgraded - bootloop that required a factory default reset to recover the device.

Basically you are enlarging (not in a clean way) the partition with 386.7, and reducing it back with 386.5 (which means losing anything written in the enlarged section). The first one is more likely to just fail to mount, but the latter is more likely to lead to corrupted content or flat out failure to boot (like Quicksilver or myself).

 

[DiGz_Au]

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