Tim Storey
Occasional Visitor
RT-AX68U
"Firmware upgrade unsuccessful" message and returned to 386.3_2
"Firmware upgrade unsuccessful" message and returned to 386.3_2
Thanks! I will test. maybe you need to write a script for it.It also means if your Internet connection goes down, your router will have no way of noticing it, and it won't make any attempt at reconnecting.
Dirty upgrade of RT-AX88U and RT-AX56U from 386.3_2 to 386.4. Works well, IPv4 and IPv6 via Mullvad VPN app with Wireguard on Win 11x64.After a long wait, the new version of Asuswrt-Merlin is now available.
Typically this means not enough free memory: remove USB devices and reboot - do the update immediately after boot - should then work.RT-AX68U
"Firmware upgrade unsuccessful" message and returned to 386.3_2
I checked all these points and it seems they are correctThe way WAN monitoring works is a bit similar to how Windows itself does. The router will try to resolve the hostname found in dns_probe_host, and make sure it matches one of the addresses found in dns_probe_content.
So for this to work, you need to ensure that:
1) Your router has working nameservers. That means on the WAN page you need to have DNS set to either automatic, or having at least one valid DNS configured. People who leave it to manual and keep both DNS1 and DNS2 empty will have issues - you MUST have at least one valid DNS configured
2) Some people (probably mostly IPv6 enabled users), make sure DNS Rebind is disabled on the WAN page, as some users have found it interferes with the test
3) Don't use a firewall/blacklist/whatever to block access to dns.msftncsi.com
4) People who used any kind of trick to prevent testing with dns.msftncsi.com in the past, these tricks no longer work, as monitoring MUST be working for the WAN state to be properly reported. So if you used any other kind of trick to prevent accessing this server, remove that trick.
So far 386.4 is working well on my RT5300After a long wait, the new version of Asuswrt-Merlin is now available. 386.4 merges with GPL 386_45958 (plus a number of security fixes backported from newer code), updates various components, and also adds support for the RT-AX86S (uses the same firmware as the RT-AX86U).
The highlights of this release;
- Merges with GPL 386_45958.
- Adds support for the RT-AX86S (uses the same firmware as the RT-AX86U).
- HND firmware now include both the kernel module and userspace tool for Wireguard. There is no built-in support for Wireguard at this time, these are only included for end-user or third party usage. Asus is still working on their own implementation, which isn't available yet.
- OpenVPN server now supports IPv6, both for incoming connections, and for routing access to the LAN clients over IPv6. Note however that redirecting IPv6 Internet traffic through your server is not supported.
- Component updates: curl 7.79.1, vsftpd to 3.0.5, openssl to 1.1.1m, wget to 1.21.1, nettle to 3.7.3, dnsmasq 2.86, openvpn 2.5.5, tor 0.4.5.11, miniupnpd 2.2.3-git 20211017, inadyn 2.9.1 and amtm 3.2.2.
- jitterentropy-rngd was replaced by haveged. Haveged is more resource-intensive, but it works properly under older 2.6.x kernels.
- dnsmasq was reverted back to using nettle for its DNSSEC crypto handling (since openssl support never got mainlined and was increasingly problematic to support)
- miniupnpd now uses the real public IP address instead of any potentially (double-)NATed address for the WAN.
- Reworked DHCP hostname support to use Asus's own implementation.
- A couple of various bugfixes
Please review the Changelog for complete details.
Notes:
Please keep posts in this thread on this specific release. This thread will be locked after a few weeks once the release feedback has died down.
- 386.4 uses the new DHCP hostname implementation from Asus (your entries will automatically be converted to the new format on first boot). This means however that reverting to a previous firmware version will lose all of your defined static lease hostnames, so backup your configuration before upgrading if you expect you might need to downgrade afterward.
Downloads are here.
Changelog is here.
Post the output from the following commands by running them from your router:I checked all these points and it seems they are correct
nslookup dns.msftncsi.com
nvram get dns_probe_host
nvram get dns_probe_content
Known issue generally caused by pixelserv-tls (or any other addon that adds a custom network interface), which causes the TrendMicro dcd daemon to crash. Nothing I can do about it, you will have to uninstall pixelserv-tls.Dirty upgrade from 386.3_2 to 386.4 and all seems ok, except for the following in the system log, which keeps repeating every 5-30 minutes;
@figorrI checked all these points and it seems they are correct
Points 1 & 2 seems Ok.
View attachment 38180
Regarding to point 3)
I thought maybe Skynet is doing something weird ... so ...
a) I added dns.msftncsi.com to the Skynet whitelist. With no luck
b) So then ... I disabled Skynet. And still no luck
c) I disabled DNS-over TLS. Nothing changed
d) I changed DNS Server 1 and DNS Server 2 to Google Servers. And the "Internet Status" stills shows as disconnected.
@scott420 had a similar issue by updating from alpha 2 to beta 3 (as it shows in Beta post #461 )
One more strange thing ...
If I use the Asus App it is also showing that Internet Status is Disconnected ... although I have internet connection.
View attachment 38182
Is successfully resolving the hostname sufficient?The way WAN monitoring works is a bit similar to how Windows itself does. The router will try to resolve the hostname found in dns_probe_host, and make sure it matches one of the addresses found in dns_probe_content.
for me it showed up in my earlier dirty flash as:Known issue generally caused by pixelserv-tls (or any other addon that adds a custom network interface), which causes the TrendMicro dcd daemon to crash. Nothing I can do about it, you will have to uninstall pixelserv-tls.
It should be, tho I haven't tried to analyze the entire wan monitoring code path. Make sure the resolution works from the router itself however, not from your LAN.Is successfully resolving the hostname sufficient?
Jan 2 11:27:26 RT-AX88U-0B10 rstats[1206]: Problem loading /mnt/Scripts/Traffic history/tomato_rstats_0c9d92030b10.gz. Still trying...
Jan 2 11:42:26 RT-AX88U-0B10 rstats[1206]: Problem loading /mnt/Scripts/Traffic history/tomato_rstats_0c9d92030b10.gz. Still trying...
Jan 2 11:57:26 RT-AX88U-0B10 rstats[1206]: Problem loading /mnt/Scripts/Traffic history/tomato_rstats_0c9d92030b10.gz. Still trying...
That's from Traffic Monitoring, not Traffic Analyzer.Seeing this in the log.
I currently have Traffic Analyzer turned off as I don't use it.
Code:Jan 2 11:27:26 RT-AX88U-0B10 rstats[1206]: Problem loading /mnt/Scripts/Traffic history/tomato_rstats_0c9d92030b10.gz. Still trying... Jan 2 11:42:26 RT-AX88U-0B10 rstats[1206]: Problem loading /mnt/Scripts/Traffic history/tomato_rstats_0c9d92030b10.gz. Still trying... Jan 2 11:57:26 RT-AX88U-0B10 rstats[1206]: Problem loading /mnt/Scripts/Traffic history/tomato_rstats_0c9d92030b10.gz. Still trying...
Got itThat's from Traffic Monitoring, not Traffic Analyzer.
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!