[Preview 384/NG] Asuswrt-Merlin 384.5 early test builds

[XIII]

Upgraded my RT-AC86U from 384.4_2 to 384.5 Alpha 1.

I still have the issue that I can neither connect to the router (via https://192.168.1.1:8443 or https://router.asus.com:8443) or the internet via IPSec VPN (as on 384.4_2 but not 384.4).

On top of that I now have the same issues with OpenVPN.

How can I investigate this further?

 

[skeal]

Upgraded my RT-AC86U from 384.4_2 to 384.5 Alpha 1.

I still have the issue that I can neither connect to the router (via https://192.168.1.1:8443 or https://router.asus.com:8443) or the internet via IPSec VPN (as on 384.4_2 but not 384.4).

On top of that I now have the same issues with OpenVPN.

How can I investigate this further?

When I updated my AC3100 my network members would drop and pop back up again at random. I know this is not your issue but by resetting to factory defaults and reconfigured manually worked for me. I was shocked that this was needed as I jumped from 384.4_2 to 384.5 alpha 1.

 

[Treadler]

384.5 alpha no issues thus far.
Wifi scheduling survives a reboot even. Woo hoo!
Happy.

 

[HuskyHerder]

I still have the issue that I can neither connect to the router ... or the internet via IPSec VPN

On top of that I now have the same issues with OpenVPN.

I only tried IPSec and I was also unable to connect to the router. I have not checked OpenVPN yet.

* I did a full default and it did not help with regard to the IPSec VPN.

 

[skeal]

I only tried IPSec and I was also unable to connect to the router. I have not checked OpenVPN yet.

* I did a full default and it did not help with regard to the IPSec VPN.

I have both a ovpn server and ovpn client and all is well.

 

[penguin22]

Was having some strange issues on 384.4_2, so loaded 384.5, including a wipe of JFFS due to DNSCrypt no longer loading, and all is functioning well.

I'm aware that high memory utilization is fine, but wonder at what point it is considered too much? With AB-Solution (incl. pixelserv & dnsmasq), Skynet, dnscrypt, and OpenVPN running, I'm steady at 93% utilization. Is there a point where clients may notice network issues from paging to swap, etc.?

 

[visortgw]

Was having some strange issues on 384.4_2, so loaded 384.5, including a wipe of JFFS due to DNSCrypt no longer loading, and all is functioning well.

I'm aware that high memory utilization is fine, but wonder at what point it is considered too much? With AB-Solution (incl. pixelserv & dnsmasq), Skynet, dnscrypt, and OpenVPN running, I'm steady at 93% utilization. Is there a point where clients may notice network issues from paging to swap, etc.?

I typically run around 90% RAM utilization with AC-Solution, pixelserv, Skynet, and two (2) OpenVPN servers. I have a 1 GB swap configured, and I have not experienced swap induced degradation. In fact, swap rarely appears to be used. (RT-AC68U with 384.5 alpha 1).

 

[mikelees2]

Ok I was about to wipe my router to attempt to get the wireless survey back and see if I can login with the mobile app and found something that is just nuts. I shut off the router and removed the USB storage and rebooted the router to wipe it and checked the wireless survey and it worked without the USB and the mobile app would not find the router at all. With the USB mounted the survey does not work and the mobile app finds the router but wont log in. Now I ask myself do I wipe the router or not. Never seen this before.

 

[skeal]

Ok I was about to wipe my router to attempt to get the wireless survey back and see if I can login with the mobile app and found something that is just nuts. I shut off the router and removed the USB storage and rebooted the router to wipe it and checked the wireless survey and it worked without the USB and the mobile app would not find the router at all. With the USB mounted the survey does not work and the mobile app finds the router but wont log in. Now I ask myself do I wipe the router or not. Never seen this before.

I would classify this as weirdness and a reset and manual config will likely fix it.

 

[Deleted member 22229]

I would classify this as weirdness and a reset and manual config will likely fix it.

Maybe not. A few builds back i could not get the tool page on Merlin firmware to completely load. Then i noticed it worked perfect as long as there was at least one wired device plugged into the router. No wired device (WiFi only) the page was broke. Strange indeed Merlin fixed it.

 

[mikelees2]

I would classify this as weirdness and a reset and manual config will likely fix it.

Yes I'm going to take the plunge when the kids go to sleep tonight. I just hope it works this time and I don't end up with a paper weight.

 

[JSinFCVA]

Preview builds of 384.5 are now available in the Test Builds folder. These builds will be occasionally refreshed.

No support will be provided for these.

Very good news for me. Went from 384.3 R0 --> 384.5 A1 and all the issues I was having with 384.4 on my AC86U are now resolved. GUI screens are all good. Both Radios activated properly. Settings from 384.3 were preserved. Client Map screens are updating correctly, not refreshing every few seconds with bogus data. Hate to say it, but 384.4 was badly broken for me and unusable. 384.5 looks like a winner so far. Kudos RMerlin !!

 

[scjr]

Very good news for me. Went from 384.3 R0 --> 384.5 A1 and all the issues I was having with 384.4 on my AC86U are now resolved. GUI screens are all good. Both Radios activated properly. Settings from 384.3 were preserved. Client Map screens are updating correctly, not refreshing every few seconds with bogus data. Hate to say it, but 384.4 was badly broken for me and unusable. 384.5 looks like a winner so far. Kudos RMerlin !!

That’s awesome!

 

[FreshJR]

I believe the 1.0.2.9 CFE update causes T-Mobile AC-1900 routers to revert to TM firmware (at least on non Merlin firmware)

More importantly than that, I am not sure if the CFE update potentially disables recovery mode!!

Maybe put a warning for T-Mobile AC-1900 users.

If recovery mode is disabled with these cfe changes then TM routers are essentially semi bricked their as they won't even be able to use any WRT firmware. (Vanilla ASUS isn't really the greatest IMO)

--
I doubt it removes recovery mode, so this warning is most likely moot.

 

[Odkrys]

Is there anyone who is having httpd crash problem ?
I am suffering quite often in the start page. (index.asp)
Watchdog do restart_httpd immediately, so that is not a big problem but it is a bit annoying.
I suspect get_ethernet_ports as the cause.

I am testing without the function for a day, and it seems to be fine (removed in router_status.asp)

 

[RMerlin]

Maybe put a warning for T-Mobile AC-1900 users.

I have never listed the TM-AC1900 as being supported, and always told people they were doing it at their own risks when modding their TM-AC1900 to flash my firmware. I don't want to start adding warnings for every unsupported models, it would just never end...

One thing that I discovered last night however is that Asus has made changes to the whole RT-AC68U family in the closed-source firmware validation code, affecting more than just the TM-AC1900. Still trying to get more information, but preliminary findings indicate that if you flash the latest 384_206xx firmware from Asus (or 384.5 alpha which is based on it), you can no longer flash back to older versions (I don't know how much older is prevented however).

As I said, still trying to find out more information, but Asus isn't (for obvious reasons) very communicative to that effect.

 

[scjr]

One thing that I discovered last night however is that Asus has made changes to the whole RT-AC68U family in the closed-source firmware validation code, affecting more than just the TM-AC1900. Still trying to get more information, but preliminary findings indicate that if you flash the latest 384_206xx firmware from Asus (or 385.5 alpha which is based on it), you can no longer flash back to older versions (I don't know how much older is prevented however).

As I said, still trying to find out more information, but Asus isn't (for obvious reasons) not very communicative to that effect.

Sounds like it’s best to wait until we hear more, before flashing 384.5? Thanks for the update, Eric.

384.4_2 working great here.

 

[RMerlin]

Sounds like it’s best to wait until we hear more, before flashing 384.5? Thanks for the update, Eric.

This is specific to the RT-AC68U and its variants (I experienced it on the RT-AC66U_B1), as I didn't experience any issue while doing tests on my RT-AC88U.

Note that this isn't entirely new. The RT-AC68U has always had a version validation check in place, people were already limited to firmware releases newer than 3.0.0.4.380_1031 (can't remember for sure which of my firmware matches that, it's probably 380.60). I believe at the time this was to prevent RT-AC68U HW revision C1 owners from flashing an older firmware release, which wasn't compatible and would crash the router. It's possible the minimal version was raised again for the same reason.

 

[skeal]

The new alpha 1 is working real well on my ac3100! The only issue I see so far is the connections tab under system logs not working correctly and that's it for me. Great work @RMerlin !

 

[RMerlin]

The only issue I see so far is the connections tab under system logs not working correctly and that's it for me.

Asus made some low-level changes to better secure the httpd server against running unwanted programs, which means the Connection page is no longer compatible. The issue has already been addressed on my local development tree by reverting that page to Asus' own implementation, and implementing the missing name resolution feature to the existing System Log -> Netstat. That page uses the more secure netools service that Asus implemented a while ago.