In the Traffic Classification Tab of the QoS area, when hovering over any label on the right-side, the tooltip always says undefined.
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
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.
Tools > Other Settings
Wan: Use local caching DNS server as system resolver (default: Yes)
Shouldn't it be turned off as default ?
Ok.RT-AC86U is not the RT-AC68U - totally different architecture. RT-AC68U only has 64 KB max.
Thanks.Code:nvram show
/proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
Mar 21 00:41:31 kernel: blog_death_by_timeout: bad timeout value=18446744073709541616, extra_jiffies=30000, idle_jiffies=40000
Another question:
#!/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."
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
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.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.:
but the blog errors never seemed to cause the UI to lock up in prior firmware versions (although not 100% sure).Code:Mar 21 00:41:31 kernel: blog_death_by_timeout: bad timeout value=18446744073709541616, extra_jiffies=30000, idle_jiffies=40000
Router: RT-AX88U
No. The default is how Asuswrt-Merlin has always been working, while disabling that will revert to how the stock firmware works.
Interesting!
Can this affect DNSEC validation (if enabled)?
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.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!