[Beta 382] Asuswrt-Merlin 382.2 Beta is now available

[eclp]

@john9527 ...

What am I doing wrong?

ASUSWRT-Merlin RT-AC88U 382.2-beta2 Mon Jan  1 18:45:15 UTC 2018
xxxx@RT-AC88U-A5:/tmp/home/root# nvram get dhcp_staticlist

xxxx@RT-AC88U-A5:/tmp/home/root# cat /jffs/nvram/dhcp_staticlist
cat: can't open '/jffs/nvram/dhcp_staticlist': No such file or directory

 

[rtn66uftw]

Just for info can you compare the output of the following two commands after ssh to the router

nvram get dhcp_staticlist

cat /jffs/nvram/dhcp_staticlist

nvram get dhcp_staticlist

gave the same results as the content stored in nvram-restore-xxx.sh

cat /jffs/nvram/dhcp_staticlist 
cat: can't open '/jffs/nvram/dhcp_staticlist': No such file or directory

I don't have nvram folder under /jffs/. I don't have any custom scripts in /jffs/ either

Thanks!

 

[Treadler]

resetting to factory defaults results in the daylight savings time ends being set to month 1 (should be month 11) on my AC68U.

Yes, this has always been my experience. A reset obviously blows away any custom DST settings.

 

[hotsauce2007]

Got 100% in both cpu and core 1 keeps jumping for the 100% for the first time with this new FW

 

[Vishnu Rao]

Looks like over clocking is broken with this beta on a RT-AC68U

Steps:
upgraded to 382 beta 2
Factory restet
Configured to desired settings
Login via ssh
nvram get clkfreq reports 800,666

nvram set clkfreq=1200,800 (previously working stetting with 380.xx release)

nvram commit
reboot

After reboot, still reads 800,666.

Anyone else see this?

 

[JMB64]

Looks like over clocking is broken with this beta on a RT-AC68U

Steps:
upgraded to 382 beta 2
Factory restet
Configured to desired settings
Login via ssh
nvram get clkfreq reports 800,666

nvram set clkfreq=1200,800 (previously working stetting with 380.xx release)

nvram commit
reboot

After reboot, still reads 800,666.

Anyone else see this?

The new boot loader prevents overriding clock settings in the NVRAM now.

 

[RMerlin]

lost much needed ability to upload own cert via the GUI no love!

That feature wasn't removed.

With the changes in nvram handling (I think the character limits apply to all models, not just the AC86.... @RMerlin - can you verify this is correct?) the DHCP assignments may be truncated or just aborted if they exceed the limit. I haven't yet had the opportunity to try some test cases with my restore code.

Nvram length validation is indeed enforced for all models. This was added by Asus to protect against buffer overruns caused by overly large nvram settings. The limit is 2500 for dhcp_staticlist if I remember correctly.

Stealth mode (disable all LEDs) does not seem to work despite factory reset. (RT-AC88U Rev. A5, 382.2.beta2 )

Works for me. Which LED remains lit?

 

[RMerlin]

I don't have nvram folder under /jffs/.

The RT-AC86U is the only model with jffs-stored nvram.

Looks like over clocking is broken with this beta on a RT-AC68U

Overclocking through nvram hasn't been supported for a few years now. The value from the bootloader gets copied to nvram at boot time.

 

[eclp]

Works for me. Which LED remains lit?

WAN LED (No. 4)

 

[Netbug]

hi merlin,

when i was on version 380.69 and below when i rebooted router the ssl certificate stayed the same so when accessing web gui it showed green (https), i did full router reset and upgraded to 382.2 beta, every time i reboot router a new certificate seems to be created so i get the not secure in browser, i use mac and added certificate to my keychain like i always have before and it shows green until router is rebooted and a new one seems to be generated, is this a bug or some change?

i don't access router from WAN just lan and via openvpn. The setting i'm talking about is administration > system > local access config.

thank you,

 

[DonnyJohnny]

hi merlin,

when i was on version 380.69 and below when i rebooted router the ssl certificate stayed the same so when accessing web gui it showed green (https), i did full router reset and upgraded to 382.2 beta, every time i reboot router a new certificate seems to be created so i get the not secure in browser, i use mac and added certificate to my keychain like i always have before and it shows green until router is rebooted and a new one seems to be generated, is this a bug or some change?

i don't access router from WAN just lan and via openvpn.

thank you,

I have that issue before. I suspect the Let's Encrypt cert is being use and regenerating on daily basic. However due to the invalid ddns, the cert is considered not very secure. You need to disable that by going to ddns page to regenerate a cert like you previously did for the older firmware. Under Import/Persistent Auto-generated,
Generate a new certificate (yes)

I didn't test it with using existing cert (without generating cert), maybe you can try and tell me if they work.

 

[Netbug]

I have that issue before. I suspect the Let's Encrypt cert is being use and regenerating on daily basic. However due to the invalid ddns, the cert is considered not very secure. You need to disable that by going to ddns page to regenerate a cert like you previously did for the older firmware. Under Import/Persistent Auto-generated,
Generate a new certificate (yes)

I didn't test it with using existing cert (without generating cert), maybe you can try and tell me if they work.

Im talking about administration > system. I don't use let's encrypt certificate, i don't access router via wan as not secure, i use openvpn so dont need a lets encrypt certificate, that setting only appeared in rt-ac68u since 382.2 for rt-ac68u to my knowledge.

I tried what you said generated a new one under ddns settings, it generated a new one, i added it to keychain, showed secure (green) rebooted router and says insecure again (red), i checked the certificate and each reboot generates a new certificate i also find it odd the expiry date is random first one generated expires 4 jan 2028 generated another and expiry is 15th feb 2027.

Previously i would just change from http to https under administration > system > local access config apply settings and that was it, add certificate to keychain and when rebooting it would keep same certificate. cheers.

 

[StefanoN]

Looks like over clocking is broken with this beta on a RT-AC68U

Steps:
upgraded to 382 beta 2
Factory restet
Configured to desired settings
Login via ssh
nvram get clkfreq reports 800,666

nvram set clkfreq=1200,800 (previously working stetting with 380.xx release)

nvram commit
reboot

After reboot, still reads 800,666.

Anyone else see this?

Hi
With the previous version of rmerlin firmware and this beta I follow this note (see at the end of page) : https://support.nvpn.net/Knowledgeb.../how-to-setup-with-merlin-asus-based-firmware

 

[skeal]

I reset both routers to factory defaults. My ac68u and ac3100 both have 382.2 Beta2. I now have no more problems. Everything running perfect. I use https:// access with the lets encrypt and obscure port. I have had no scans to that port yet at all. HTTPS shows secure connection. This is awesome. Thanks @RMerlin job well done!

 

[metadethrax]

I too am using Oppose, definitely something fishy going on there. Did you factory reset after upgrading to 382? Or dirty flash? (Ie. no reset)

Restored factory settings. BTW, newest official branch, 384, it's a big improvement. Gigabit speeds on PPPoE are now around 700 Mbps with Ai Protection enabled. Still not as it used to be (900+ Mbps), but definitely a step forward.

 

[skeal]

I use 382.2 Beta2 and have discovered after flashing few times that resetting to factory defaults is absolutely a must to get proper operation. I also use a QOS restart command through ssh and I'm golden!

service restart_qos

 

[charlie2alpha]

Interesting, after @metadethrax 's mention of a 384 branch I checked a bit, there seem to be 384 releases for the RT-AC86U and RT-AC68U at least at ASUS' support site. No GPLs yet though. The most interesting thing from the release notes of the 68U is this:

Bug fixed
- Fixed NAT throughput drop issue.
- Fixed network map abnormal responsed time issues
- Fixed client list issues.
- Fixed AiCloud smart sync issue.

I guess that fixes the hardware acceleration which is known to be broken at least for PPPoE connections and affects me too, yesterday my RT-AC56U hit for the first time ever 100% CPU usage while downloading.

 

[gffmac]

Looks like over clocking is broken with this beta on a RT-AC68U

Steps:
upgraded to 382 beta 2
Factory restet
Configured to desired settings
Login via ssh
nvram get clkfreq reports 800,666

nvram set clkfreq=1200,800 (previously working stetting with 380.xx release)

nvram commit
reboot

After reboot, still reads 800,666.

Anyone else see this?

I have my 1ghz overclock set in scripts service-start and service-stop, im nearly 2 hours after reboot and its still sticking, bogoMIPS reporting 1998. Ill keep an eye on it.

 

[skeal]

This thread seems to be about over clocking. I have a question. After increasing the clock frequency in this method outlined above do you get a significant increase in performance? How does it affect OVPN performance? Are there any problems with ram usage? Thanks I know very little about this topic and would like to learn.

 

[Nagy Imre]

RT-AC88U
Verzió 3.0.0.4.384.10007 2018/01/0245.7 MBytes

ASUS RT-AC88U Firmware version 3.0.0.4.384.10007
New feature
AiMesh: An innovative new router feature that connects multiple ASUS routers to create a whole-home WiFi network. Refer to https://www.asus.com/aimesh/ for more detail.

Security fixed
- Fixed XSS vulnerability. Thanks for Joaquim's contribution.
- Fixed LAN RCE vulnerability. An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program
- Fixed remote code execution vulnerability. Thanks to David Maciejak of Fortinet's FortiGuard Labs

Bug fixed
- Fixed NAT throughput drop issue.
- Fixed high CPU loading issue.
- Fixed network map abnormal responded time issues
- Fixed client list issues.
- Fixed AiCloud smart sync issue.
- Fixed USB 3.0 issue. To get full USB 3.0 speed, please disable "reducing USB 3.0 interference".