Release Asuswrt-Merlin 386.14 is now available for AC models

[banger]

Well the traffic statistics have emptied after a reboot 2 days ago. :|

 

[Snoopotic]

Hi,
due to a coincidence that since I have updated to .14 on my ac88u has repeatedly connection issues and I am still analysing (seems the ipsec server was crashing constnatly until it crashes the router - butt need more facts)
I found out that watchdog is constantly runnng ddns-start custom script alhough "/sbin/ddns_custom_uüdated 1" is called... So anyopne knows what is calling watchdog to do this?

Oct 11 13:56:11 tackaman watchdog: start ddns.
Oct 11 13:56:11 tackaman ddns: update CUSTOM , wan_unit 0
Oct 11 13:56:11 tackaman ddns: Clear ddns cache.
Oct 11 13:56:11 tackaman custom_script: Running /jffs/scripts/ddns-start (args: 146.52.my.ip)
Oct 11 13:56:16 tackaman ddns-start: IPv4:146.52.156.135 tunnelbroker.net update response: nohost
Oct 11 13:56:16 tackaman ddns: Completed custom ddns update
Oct 11 13:56:16 tackaman ddns-start: DynDNS success!
Oct 11 13:56:45 tackaman watchdog: start ddns.
Oct 11 13:56:45 tackaman ddns: update CUSTOM , wan_unit 0
Oct 11 13:56:45 tackaman ddns: Clear ddns cache.
Oct 11 13:56:45 tackaman custom_script: Running /jffs/scripts/ddns-start (args: 146.52.my.ip)
Oct 11 13:56:49 tackaman ddns-start: IPv4:146.52.156.135 tunnelbroker.net update response: nohost
Oct 11 13:56:49 tackaman ddns: Completed custom ddns update
Oct 11 13:56:49 tackaman ddns-start: DynDNS success!
Oct 11 13:57:18 tackaman watchdog: start ddns.
Oct 11 13:57:18 tackaman ddns: update CUSTOM , wan_unit 0
Oct 11 13:57:18 tackaman ddns: Clear ddns cache.
Oct 11 13:57:18 tackaman custom_script: Running /jffs/scripts/ddns-start (args: 146.52.my.ip)
Oct 11 13:57:22 tackaman ddns-start: IPv4:146.52.156.135 tunnelbroker.net update response: abuse
Oct 11 13:57:22 tackaman ddns: Completed custom ddns update
Oct 11 13:57:22 tackaman ddns-start: DynDNS success!
....

 

[banger]

Well the traffic statistics have emptied after a reboot 2 days ago. :|

Switching off and on again brings it back to life. Hmm

 

[Yota]

I still don't see what exactly is the added value of 386.14 over 386.13.

Reasons:

- GPL 386_52805 may contain many important security fixes, but since there is no update log from Asuswrt, we don't know for now.
- "Unusually smooth GUI for an RT-AC68U variant" -- Tech9
- The HTTPS self-signed certificate has been redesigned. Now the router creates a root certificate by default, and then the root certificate issues the HTTPS certificate of the web interface. This root certificate can be imported into the AP router running 386.14, so the same root certificate can be used to issue different web interfaces. For families who manage multiple routers, they only need to trust one root certificate in their browser.
- Removing Wifi Radar seems more like a security improvement to me, removing an outdated and unmaintained component to avoid future attack vectors.

 

[Tech9]

Everyone has own reasons and own choices. In my opinion inconveniences outweigh the potential benefits.

 

[banger]

My android phone had difficulty logging on the 5ghz today, reboot of router sorted.

 

[bibikalka]

Have AC86U and AC68U running 386.14 as AiMesh setup. Started to get a bunch of issues with long reconnect times on the AC68U AiMesh node after this type of message:

Nov  3 17:16:51 MISC: wifi upstream is connected, and disconnected from CAP.

Tried to downgrade AC68U to 386.12 and 386.13. In both cases the router would bridge to a wired client, but will no longer work as an AiMesh node. Tried to restore prior saved nvram config files - still did not help to get AiMesh operation back. Attempted to add the reset AC68U with 386.13 as a new node with a cable - the process failed at ~80+%.

Had to upgrade AC68U back to 386.14, and then it did configure successfully as the AiMesh node.

So ended up where I started. The only hope is that the freshly reconfigured AiMesh node will somehow have fewer disconnect issues.

Update: The issues are the same after the full AiMesh node refresh on 386.14 - fairly frequent (several times per day) disconnects with the same MISC message. Will probably try to revert to 386.13_x when I have a spare moment.

 

[banger]

Does WPS work on this firmware?

 

[Pitchounet]

I have one question. I'm looking for why i have regular deconnexion, so i check a little all. I've seen that i could only renew let's encrypt via router mode only. Why isn't it accessible to ap mode too?

 

[banger]

Does the scheduled reboot also reboot the AImesh nodes?

 

[visortgw]

Does the scheduled reboot also reboot the AImesh nodes?

No, you need to do that manually from AiMesh tab within web UI by selecting Reboot System.

 

[banger]

No, you need to do that manually from AiMesh tab within web UI by selecting Reboot System.

Many thanks.

 

[NoLight]

No, you need to do that manually from AiMesh tab within web UI by selecting Reboot System.

My aimesh with wired back-haul node does reboot with the scheduler.

 

[banger]

Interesting.

 

[Tech9]

One final release with current Asuswrt security patches will be nice. Hopefully Asus provides whatever is needed.

 

[RMerlin]

386.14_2 is now available.

386.14_2 (17-Nov-2024)
  - UPDATED: OpenVPN to 2.6.12.
  - CHANGED: Enabled Netfilter queue support for SDK6/SDK7
             devices (patch by HiHat)
  - FIXED: Security issues in AiCloud (backports from Asus)
  - FIXED: CVE-2024-2511, CVE-2024-4741, CVE-2024-5535 &
           Implicit rejection for RSA PKCS#1 in openssl
           (backport from Ubuntu by RSDNTWK)

 

[bennor]

386.14_2 is now available.

@RMerlin, just an FYI. In the RT-AC68U_386.14_2.zip file for the RT-AC68U there was the change log for the 3006 firmware (Changelog-3006.txt) in addition to the change log for 386. Checked the RT-AC68U_386.14_0.zip file and it didn't have a change log for the 3006 firmware, just the one for the 386.x firmware.

 

[RMerlin]

@RMerlin, just an FYI. In the RT-AC68U_386.14_2.zip file for the RT-AC68U there was the change log for the 3006 firmware (Changelog-3006.txt) in addition to the change log for 386. Checked the RT-AC68U_386.14_0.zip file and it didn't have a change log for the 3006 firmware, just the one for the 386.x firmware.

Probably a consequence of the fact that this firmware is built differently. Two separate firmwares get compiled (RT-AC68U and RT-AC68U_V4), then they get merged together. The merge step probably included all available changelogs at the same time.

 

[Pitchounet]

I hope it will solve my tiring regular little wifi deconnections

 

[jsbeddow]

I hope it will solve my tiring regular little wifi deconnections

No change in GPL or wireless code, so highly unlikely, only placebo effects (from rebooting) only.