What's new

[Beta] Asuswrt-Merlin 384.10 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I'm going to do a nvclear reconfigure from scratch again and configure only one single openvpn client until this is fixed.
 
I am facing 3 issues, since beta 1 :
- on web UI on AC68U in AP mode the link with other AC68U (in router mode) is displayed as broken with red cross while it is actualy connected and working.
- that was already reported but DST time (for France at least) is not correct.
- in dual wan mode (wan+eth) you can't set it to load balance, your choice is not recorded.
 
RT-AC86U with 384.10 Beta 2: I am seeing random disconnects and reconnects from one of my client VPN's from my work laptop (Wired connections). Only thing near the times of occurrence are DCD Crashes right before the events, but not for every DCD Crash. I started seeing these starting with 384.10 Beta 1, but they are more of a nuisance than anything of concern - just recording it here.

I am going to "start from scratch" and see if it clears up.
 
Not from me.
Code:
nvram show
On AC86U via nvram show I have the similar 128k for NVRAM
size: 66700 bytes (64372 left)
or
size: 66631 bytes (64441 left)
The sum is equal to the total size of NVRAM from Tools page
ac86u-nvram.PNG
 
On AC86U via nvram show I have the similar 128k for NVRAM
size: 66700 bytes (64372 left)
or
size: 66631 bytes (64441 left)
The sum is equal to the total size of NVRAM from Tools page
View attachment 16629

RT-AC86U is not the RT-AC68U - totally different architecture. RT-AC68U only has 64 KB max.
 
Cleared NVRam Cache, formatted jffs,

No other scripts at all, no openvpn clients,
NVRAM usage 52000 / 65536 bytes
With one openvpn client+cert (no other scripts)
NVRAM usage around ~57000 / 65536 bytes
With two openvpn clients+certs: (no other scripts)
NVRAM usage 62604 / 65536 bytes

That is a roughly ~5000 kb increase per opvn, exact size as the openvpn certificate authority.
Cache does not go down after disabling the second client, even after rebooting.
After deleting the certificate and rebooting Nvram showed:
NVRAM usage 62587 / 65536 bytes
Update: After formatting jffs again, NVRAM usage 62607 / 65536 bytes
I suspect trying more than 2 clients/ certs went over the nvram limits previously.
I was not able to to start a second client even within the NVRam limit.

It's a bug, as those key/certs should only end up on /jffs, not in nvram. I tracked it down to a section of code of the web server that was writing to nvram any parameter it received but didn't recognize as part of an indexed parameter. I just need to ensure the fix does not create any new problem.
 
Tools > Other Settings
Wan: Use local caching DNS server as system resolver (default: Yes)

Shouldn't it be turned off as default ?

Anyone noticing a difference ?
 
Tools > Other Settings
Wan: Use local caching DNS server as system resolver (default: Yes)

Shouldn't it be turned off as default ?

No. The default is how Asuswrt-Merlin has always been working, while disabling that will revert to how the stock firmware works.
 
RT-AC86U is not the RT-AC68U - totally different architecture. RT-AC68U only has 64 KB max.
Ok.
Now it's clear, the your post about NVRAM don't releted to my post about kernel panic ...
 
Code:
nvram show
Thanks.

Another question:
Hot to monitor Active connections from Tools/Sysinfo page?
Connections 3111 / 300000 - 612 active
First one is
Code:
/proc/sys/net/netfilter/nf_conntrack_count
Second is
Code:
cat /proc/sys/net/netfilter/nf_conntrack_max
But how to get third (612 active)?
 
For some reason, web UI became unresponsive after running 384.10 beta 2 for two days. Even reaching the login page took a long time. I only have the Skynet script loaded and tested temporarily disabling it but it didn't help. Only restarting the router restored WebUI speed. Normal web browsing was unaffected. I still have blog_death_by_timeout errors, e.g.:
Code:
Mar 21 00:41:31 kernel: blog_death_by_timeout: bad timeout value=18446744073709541616, extra_jiffies=30000, idle_jiffies=40000
but the blog errors never seemed to cause the UI to lock up in prior firmware versions (although not 100% sure).

Router: RT-AX88U
 
384.10 Beta 3 is now available. This release contains a couple of changes surrounding OpenVPN key/certs management, which should notably reduce nvram usage. The issue where key/certs would sometimes be left in nvram is fixed, and the unused key/cert var names are no longer wasting nvram space either, saving a few hundred bytes of nvram. Please make sure no new issue was introduced surrounding management of key/certs.

It is also now possible to remove a key/certs by clearing its field, rather than having to remove the file in /jffs/openvpn/ .

The following script will clear up your nvram:

Code:
#!/bin/sh

echo "Removing unused cert/key from nvram..."

for i in 1 2 3 4 5
do
    nvram unset vpn_crt_client$i\_ca
    nvram unset vpn_crt_client$i\_extra
    nvram unset vpn_crt_client$i\_crt
    nvram unset vpn_crt_client$i\_key
    nvram unset vpn_crt_client$i\_crl
    nvram unset vpn_crt_client$i\_static
done

for i in 1 2
do
    nvram unset vpn_crt_server$i\_ca
    nvram unset vpn_crt_server$i\_dh
    nvram unset vpn_crt_server$i\_ca_key
    nvram unset vpn_crt_server$i\_extra
    nvram unset vpn_crt_server$i\_client_crt
    nvram unset vpn_crt_server$i\_crl
    nvram unset vpn_crt_server$i\_crt
    nvram unset vpn_crt_server$i\_key
    nvram unset vpn_crt_server$i\_static
    nvram unset vpn_crt_server$i\_client_key
done

nvram commit

echo "done."

The Firefox stalls when using https with a router-generated certificate should also be resolved now (looks like an old Firefox bug came back when they added TLS 1.3 support), a workaround has been implemented - you might need to re-generate your router certificate.

Code:
314329e5c2 Updated documentation
99c64f99f8 Bumped revision to beta 3
a45ceea61c libvpn: allow erasing a key/cert by providing an empty one
2204f05a5e libvpn: resetting to default wasn't clearing client extra CA certificate
58c2fda137 shared: remove indexed vpn_crt_* entries from default nvram settings
708ee2bb7c httpd: webui: display client's bandwidth on wireless log page
c4583ee465 httpd: do not link with libletsencrypt when OpenSSL 1.1.x is enabled due to mismatched openssl versions
61380ae127 httpd: add emailAddress attribute to generated certificate
7225891383 (rtax88) Merge with 384_5640 GPL
7dbff248a1 webui: Classification page fixes: hide filters on empty list, remove undefined class popup in non-aQoS mode
 
For some reason, web UI became unresponsive after running 384.10 beta 2 for two days. Even reaching the login page took a long time. I only have the Skynet script loaded and tested temporarily disabling it but it didn't help. Only restarting the router restored WebUI speed. Normal web browsing was unaffected. I still have blog_death_by_timeout errors, e.g.:
Code:
Mar 21 00:41:31 kernel: blog_death_by_timeout: bad timeout value=18446744073709541616, extra_jiffies=30000, idle_jiffies=40000
but the blog errors never seemed to cause the UI to lock up in prior firmware versions (although not 100% sure).

Router: RT-AX88U
Further to this post: at no point did I enable HTTPS. I have also now upgraded to 384.10 Beta 3 with no immediate ill effects on my RT-AX88U and will keep an eye on it long term.
 
Just updated to beta3 and working fine. Clean client and server certs and have 2988 more bytes.
Now 57491/65536=8045 bytes free.
Uptime 0 days 0 hours 22 minute(s) 34 seconds

Thanks!
 
Flashed RT-AC86U From 384.10_Beta2 to Beta3. Factory reset and manually reconfigured settings

As with Beta 1 & 2 all appears hunky dory


Sent from my iPad using Tapatalk
 
RT-AC88U [Access Point] dirty flash from beta 2 to beta 3 as smooooth as silk.

Was looking for an update for my RT-AX88U currently running beta 2 (5640 version). Could have swarn that there was a beta 3 of it in the test build section this morning, but when I went back to download it, only beta 2 was there. Did I imagine that? lol.
 
Interesting!
Can this affect DNSEC validation (if enabled)?

To clarify, this option only affects resolution queries generated BY the router. It has no effect at all on DNS queries generated by your LAN clients. So what it would mostly affect, for example, is name resolution from your VPN clients, Download Master, WAN connections that use PPTP such as Beeline, etc...

Was looking for an update for my RT-AX88U currently running beta 2 (5640 version). Could have swarn that there was a beta 3 of it in the test build section this morning, but when I went back to download it, only beta 2 was there. Did I imagine that? lol.

Might be an issue with Sourceforge's mirrors, because the file is visible for me.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top