Beta Asuswrt-Merlin 386.7 Beta is now available

[RMerlin]

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

A good portion of that code is open sourced. I just need to better understand at which location in the code they toggle the nvram content to see if I could change that behaviour.

I can certainly see cases where someone might want to disable the logo but not the status leds. One workaround I could do is when I set the led state in setup_leds() is to first save the aurargb state, and reapply it at the end of the function.

 

[bluepoint]

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

Its definitely worth a try. Whenever addons/entware behaves with errors, most of the time the drive is failing.

 

[RMerlin]

A good portion of that code is open sourced. I just need to better understand at which location in the code they toggle the nvram content to see if I could change that behaviour.

I can certainly see cases where someone might want to disable the logo but not the status leds. One workaround I could do is when I set the led state in setup_leds() is to first save the aurargb state, and reapply it at the end of the function.

Sigh. It would help if I was actually studying current code rather than accidentally reviewing 386.5 alpha 2 code. For some reason my gt-ax11000 build folder wasn't synced up.

The aurargb_enable value is actually set by me in 386.7, it's something I changed a few weeks ago. I just need to remove that code that I added, and that nvram will stay put... That should solve the option found on the System page. It won't affect the hardware button, which seems fine by me - someone using that button might really want to fully disable or re-enable all lights.

EDIT: So, the revised behaviour that I just tested on my GT-AXE11000, regarding the System option to disable LEDs:

- If AuraRGB is enabled, then enabling/disabling LEDs will also control AuraRGB
- If AuraRGB is disabled, then enabling/disabling LEDs will not touch AuraRGB, leaving it off in both modes

This is actually the original behaviour before the 386.6 changes, and seems the most intuitive to me.

 

[Kabouter Plop]

rgb is always such an headache, with Asus i wish some one would take there software and just fix the bugs like a moded armoury crate rather then openrgb that causes issues like chipset fan spinning down upon scanning for rgb

 

[alan6854321]

EDIT: So, the revised behaviour that I just tested on my GT-AXE11000, regarding the System option to disable LEDs:

- If AuraRGB is enabled, then enabling/disabling LEDs will also control AuraRGB
- If AuraRGB is disabled, then enabling/disabling LEDs will not touch AuraRGB, leaving it off in both modes

This is actually the original behaviour before the 386.6 changes, and seems the most intuitive to me.

The LED behaviour on my AX86S is really weird...

When I reboot it, they all (except WPS) come on as expected.
If I press the button or use the 'Disable LEDs' UI setting, they all go off.

But after that I can't get them all on again no matter if I use the button or the UI
It seems random, often all LEDs apart from the two WIFI ones come on.
Other times it's the four ethernet ports that remain off.
Occasionally, it's the WAN light that remains off.

But the only way I found to get them all back is to reboot again.

No big deal as I usually leave them on all the time anyway, I was just playing around and discovered it.

 

[Labdoc]

This might be useful to someone else who loses access to the config page at 192.168.1.1.
I was running 386.7_beta1 on an RT-AX88U following a dirty upgrade from the alpha fw. The router config was accessed at 192.168.1.1. Next, I tried to reset to factory defaults using the WPS button (https://www.asus.com/support/FAQ/1039078). When this finished, I could not get into the config page at 192.168.1.1. I was trying from a pc with static address 192.168.1.1 and a cable in ethernet port 4. No ping response either. The Asus discovery utility showed nothing, and an attempted Asus firmware restore also failed to find the router.

On another computer, I noticed that there was a wifi signal detected at 192.168.50.1. So, I reset the static IP on the first computer to 192.168.50.2, subnet 255.255.255.0 and tried logging into the router at 192.168.50.1.

It worked!

The only other change that seemed necessary was to turn off all the protections in the Edge browser I was using in Win 10 to access the router settings.

BTW, I did a factory reset from the GUI and it maintained the 192.168.50.1 (I expected it to reset to 192.168.1.1). So, I had to change that in the GUI to the usual default

I have no idea whether the failure of the WPS button reset was due to the beta FW, my clumsy fingers or some other issue. However, I am delighted to not have a bricked router.

 

[Gary_Dexter]

This might be useful to someone else who loses access to the config page at 192.168.1.1.
I was running 386.7_beta1 on an RT-AX88U following a dirty upgrade from the alpha fw. The router config was accessed at 192.168.1.1. Next, I tried to reset to factory defaults using the WPS button (https://www.asus.com/support/FAQ/1039078). When this finished, I could not get into the config page at 192.168.1.1. I was trying from a pc with static address 192.168.1.1 and a cable in ethernet port 4. No ping response either. The Asus discovery utility showed nothing, and an attempted Asus firmware restore also failed to find the router.

On another computer, I noticed that there was a wifi signal detected at 192.168.50.1. So, I reset the static IP on the first computer to 192.168.50.2, subnet 255.255.255.0 and tried logging into the router at 192.168.50.1.

It worked!

The only other change that seemed necessary was to turn off all the protections in the Edge browser I was using in Win 10 to access the router settings.

BTW, I did a factory reset from the GUI and it maintained the 192.168.50.1 (I expected it to reset to 192.168.1.1). So, I had to change that in the GUI to the usual default

I have no idea whether the failure of the WPS button reset was due to the beta FW, my clumsy fingers or some other issue. However, I am delighted to not have a bricked router.

192168.50.1 has always been the default for all ASUS routers, AFAIK

 

[capncybo]

192168.50.1 has always been the default for all ASUS routers, AFAIK

I'm not so sure that is 100% true (from my vague memory) I thought the RT-AC68U (and likely some older models) had actually defaulted to: 192.168.1.1

 

[mistercoffee1]

Older models (AC68 and N66 and others) use 192.168.1.1.

 

[capncybo]

Older models (AC68 and N66 and others) use 192.168.1.1.

Good to know I'm not going completely senile, LOL

 

[laracroftonline]

Older models (AC68 and N66 and others) use 192.168.1.1.

my AC5300 also had 192.168.1.1 as default adress.

 

[jsbeddow]

Its definitely worth a try. Whenever addons/entware behaves with errors, most of the time the drive is failing.

@thelonelycoder , @RMerlin
This is on my main router, the RT-AC86U.

Well, that was fun: I did try reinstalling my amtm scripts once again, startring with Entware, on a alternative simple USB flash drive. That also didn't work under 386.7 (beta1), as I still see a fast scroll off the screen to the effect of "Address is invalid....xxx........etc...", then "Entware (aarch64) install failed" when the amtm menu comes back.

So I decided to do a full factory reset this morning under 386.7, and manual input of all settings (no settings were restored from backup files): full wipe of jffs, full wipe and reformatting of the attached (main, SSD based) USB storage. I started fresh in amtm, "fd" utility to ext4 with journaling (one partition), and on to creating a (5GB) swap file after one more reboot cycle. So far so good, but no, not really: this still fails to install Entware from within amtm with exactly the same error as before.

OK, lets try a downgrade to 386.5_2: immediate success, no problems at all installing any amtm utilities. I still can't believe I am the only one seeing this!? I'm starting to wonder if nearly everyone else has moved on to newer (and less problematic) routers. I guess I will have to do as @L&LD suggested, wait this one out until we see a full final release of 367.7 and then wait just a bit more to see if anyone else runs into this problem.

 

[ColDen]

@thelonelycoder , @RMerlin
This is on my main router, the RT-AC86U.

Well, that was fun: I did try reinstalling my amtm scripts once again, startring with Entware, on a alternative simple USB flash drive. That also didn't work under 386.7 (beta1), as I still see a fast scroll off the screen to the effect of "Address is invalid....xxx........etc...", then "Entware (aarch64) install failed" when the amtm menu comes back.

So I decided to do a full factory reset this morning under 386.7, and manual input of all settings (no settings were restored from backup files): full wipe of jffs, full wipe and reformatting of the attached (main, SSD based) USB storage. I started fresh in amtm, "fd" utility to ext4 with journaling (one partition), and on to creating a (5GB) swap file after one more reboot cycle. So far so good, but no, not really: this still fails to install Entware from within amtm with exactly the same error as before.

OK, lets try a downgrade to 386.5_2: immediate success, no problems at all installing any amtm utilities. I still can't believe I am the only one seeing this!? I'm starting to wonder if nearly everyone else has moved on to newer (and less problematic) routers. I guess I will have to do as @L&LD suggested, wait this one out until we see a full final release of 367.7 and then wait just a bit more to see if anyone else runs into this problem.

I am still using my old thrusty +3 years old Kingston DataTraveller 16Gb USB drive with my +3 years old RT-AC86C:

I am running it as-is (no cooling fan) and did not experience the multiple reported operating temperature issues, therefore I am considering myself as one of the lucky owners (crossing fingers) but do know that it is not the case for many other ones.

As previously mentionned by other users, the one with barely no issues rarely reply nor comment about it whem others are reporting significant issues with their router (similar to happy car owners). Accordingly I am assuming that there are more "happy" owners than "unhappy" ones out there. I do not mean by that that I may not have potential issues with my router that I have not experienced so far (like the nvram odd behaviour currently investigated in the "My experience with the RT-AC86C" thread) but simply that I did not ran in such scenario so far.

So good luck and sincerely hope that you will manage to address/fix your issues soon.

 

[RMerlin]

I'm not so sure that is 100% true (from my vague memory) I thought the RT-AC68U (and likely some older models) had actually defaulted to: 192.168.1.1

The switch to 192.168.50.0/24 only happened a few years ago, and I'm not sure if the change was enabled for all models or just a few specific ones (you'd have to check the target.mak build profile in the source code and look for the LAN50 setting).

 

[Eric Lieb]

The switch to 192.168.50.0/24 only happened a few years ago, and I'm not sure if the change was enabled for all models or just a few specific ones (you'd have to check the target.mak build profile in the source code and look for the LAN50 setting).

Ya I hate that switch since I have some devices that set their own static IP. I always forget to revert it back to the 192.168.1.0/24

 

[thelonelycoder]

Well, that was fun: I did try reinstalling my amtm scripts once again, startring with Entware, on a alternative simple USB flash drive. That also didn't work under 386.7 (beta1), as I still see a fast scroll off the screen to the effect of "Address is invalid....xxx........etc...", then "Entware (aarch64) install failed" when the amtm menu comes back.

What IP address do you use for the router and what did you set aside as pixelserv-tls IP?

So I decided to do a full factory reset this morning under 386.7, and manual input of all settings (no settings were restored from backup files): full wipe of jffs, full wipe and reformatting of the attached (main, SSD based) USB storage. I started fresh in amtm, "fd" utility to ext4 with journaling (one partition), and on to creating a (5GB) swap file after one more reboot cycle. So far so good, but no, not really: this still fails to install Entware from within amtm with exactly the same error as before.

I just did exactly that on my RT-AC86U. The only exception is that I created the swap file after setting up Entware and Diversion.
I see no reason that this would change the outcome for you as this router has plenty of memory for a regular Entware and Diversion installation without the immediate need to have a swap file.

Anyway, all above went well, except the initial pixelserv-tls certificate creation. I might have to look into this:

Can't load /root/.rnd into RNG
4146819072:error:2406F079:lib(36):func(111):reason(121):NA:0:Filename=/root/.rnd

This has to do with openssl having not created the file /root/.rnd during the process.
Re-generating the CA certs in ep worked.

 

[FTC]

Running the beta since Sunday on all my routers and haven't seen any issues. Also, no problems running pixelserv -tls and diversion.

This is great news. anyone else can confirm pixelserv-tls/diversion problems with RT-AX88 are gone with this beta ?

 

[jsbeddow]

What IP address do you use for the router and what did you set aside as pixelserv-tls IP?

I just did exactly that on my RT-AC86U. The only exception is that I created the swap file after setting up Entware and Diversion.
I see no reason that this would change the outcome for you as this router has plenty of memory for a regular Entware and Diversion installation without the immediate need to have a swap file.

Anyway, all above went well, except the initial pixelserv-tls certificate creation. I might have to look into this:

Can't load /root/.rnd into RNG
4146819072:error:2406F079:lib(36):func(111):reason(121):NA:0:Filename=/root/.rnd

This has to do with openssl having not created the file /root/.rnd during the process.
Re-generating the CA certs in ep worked.

Thanks for looking into this, but I believe that the "address" being referred to in my error seems to be in relation to a physical/hex address on the USB drive, not an IP address, as I have (for at least a year or so) switched to Diversion-Lite, thus no Pixelserve IP reservation takes place. That being said, I always setup all of my routers to use a LAN IP following the older convention of 192.168.1.1, not the default for this model of 192.168.50.1.

At this point, I have gone through this exercise so many times I am fairly certain that I have tried at least once to go through the installation of Diversion (with Entware) or just Entware first, prior to making a swap file, yet it fails every time for me under any version of 386.7, even after performing a very thorough "clean" reset/format and re-install. The error that I see when going through this process with just the Entware install scrolls off the screen very fast, but is similar (but perhaps not identical) to this one when I try to install Diversion first: (this screenshot is from an early exercise, when I wasn't doing a true new installation, just a forced re-install)

Out of curiosity, was your test done on a similarly reset RT-AC86U, also runnning 386.7 Beta 1? As a reminder, I have no problems doing any of these installs on exactly the same router, and same USB drive (Ugreen enclosure SSD), as long as I am using 386.5_2.

 

[RMerlin]

The LED behaviour on my AX86S is really weird...

This is because the RT-AX86U and RT-AX86S share the same base model, however the RT-AX86S uses different network interfaces for wifi, so currently the commands to turn the LEDs on are sent to the wrong interfaces. Should be fixed in beta 2.

 

[Damit1]

Help!
These CONSOLE entries are flooding the syslog.

Jun 17 01:01:08 kernel: CONSOLE: 103101.238 wl0: wlc_ampdu_recv_addba_resp: Failed. status 1 wsize 0 policy 1
Jun 17 01:52:15 kernel: CONSOLE: 194745.715 wlc_rrm_recv_bcnrep: channel :155, duration: 100, frame info: 0, rcpi: 183,rsni: 19, bssid d4:5d:64:a0:8e:54, antenna id: 0, parent tsf: 1830949891
Jun 17 01:52:15 kernel: CONSOLE: 194745.715 wlc_rrm_recv_bcnrep: channel :155, duration: 100, frame info: 0, rcpi: 218,rsni: 35, bssid 24:4b:fe:09:d8:c4, antenna id: 0, parent tsf: 318767188

Yesterday it got any devices connected out of the network.
Anyone know it?
First time those CONSOLE entries are show up, in 386.5_2 and previously were not show up.