What's new

Release Asuswrt-Merlin 386.11 is now available for AC models

  • 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!

Dirty updated my AC86U from 386.10, and now my openVPN performance at the client device is super slow or non-functional. The router's VPN status page shows the client device is connected and data (very slowly) flowing, but the performance is terrible. Anything I should try before factory reseting and reconfiguring the router?
 
I read thru this thread and most of the alpha version discussion, and saw mentions of 10% or 20% openVPN throughput reduction, but my reduction is way over 99%.
 
Been running stable for 24 days but just came across a repeatable issue with DDNS registration. Since the changelog mentions DDNS fixes, and my ISP supports IPv6 native, I'll post/report/ask.

When toggling DNS privacy protocol, the services restart and subsequent scripts leave DDNS dead and inactive. I discovered this because I switched back to ISP DNS from the adblock DoT servers to test some issues I was having.

You can see at the end of the logs it's not happy. It may say "Recover Time set 41" but it never restarts.

I can easily 'fix' the issue by simply hitting 'apply' on the DDNS tab, so it seems to be something with the way or timing during the services_restart.

Code:
Jun  9 06:22:27 RTAC86U rc_service: httpd 30979:notify_rc restart_wan_if 0;restart_stubby;restart_dnsmasq
Jun  9 06:22:27 RTAC86U custom_script: Running /jffs/scripts/service-event (args: restart wan_if)
...
...
Jun  9 06:22:27 RTAC86U rc_service: dhcp6c 26519:notify_rc restart_ddns
Jun  9 06:22:27 RTAC86U rc_service: waitting "restart_wan_if 0;restart_stubby;restart_dnsmasq" via httpd ...
...
Jun  9 06:22:27 RTAC86U wan: finish adding multi routes
Jun  9 06:22:29 RTAC86U ddns: WAN IP is empty.(10)
Jun  9 06:22:32 RTAC86U watchdog: start ddns.
Jun  9 06:22:32 RTAC86U rc_service: watchdog 1218:notify_rc start_ddns watchdog
Jun  9 06:22:32 RTAC86U rc_service: waitting "restart_wan_if 0;restart_stubby;restart_dnsmasq" via httpd ...
...
Jun  9 06:22:42 RTAC86U rc_service: dhcp6c 26761:notify_rc restart_ddns
Jun  9 06:22:42 RTAC86U rc_service: waitting "restart_wan_if 0;restart_stubby;restart_dnsmasq" via httpd ...
Jun  9 06:22:42 RTAC86U rc_service: skip the event: restart_ddns.
Jun  9 06:22:43 RTAC86U stubby[28994]: Read config from file /etc/stubby/stubby.yml
Jun  9 06:22:43 RTAC86U stubby[28994]: Stubby version: Stubby 0.4.2
Jun  9 06:22:43 RTAC86U custom_script: Running /jffs/scripts/service-event (args: restart dnsmasq)
Jun  9 06:22:43 RTAC86U custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
Jun  9 06:22:43 RTAC86U stubby[29073]: Read config from file /etc/stubby/stubby.yml
Jun  9 06:22:43 RTAC86U stubby[29073]: Stubby version: Stubby 0.4.2
...
Jun  9 06:22:44 RTAC86U custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun  9 06:22:44 RTAC86U ddns: WAN IP is empty.(9)
Jun  9 06:22:44 RTAC86U custom_script: Running /jffs/scripts/service-event (args: restart ddns)
Jun  9 06:22:44 RTAC86U ddns: WAN IP is empty.(9)
Jun  9 06:23:14 RTAC86U watchdog: start ddns.
Jun  9 06:23:14 RTAC86U rc_service: watchdog 1218:notify_rc start_ddns watchdog
Jun  9 06:23:14 RTAC86U custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun  9 06:23:14 RTAC86U ddns: IP address, server and hostname have not changed since the last update.
Jun  9 06:23:44 RTAC86U watchdog: start ddns.
Jun  9 06:23:44 RTAC86U rc_service: watchdog 1218:notify_rc start_ddns watchdog
Jun  9 06:23:44 RTAC86U custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun  9 06:23:44 RTAC86U ddns: IP address, server and hostname have not changed since the last update.
Jun  9 06:24:14 RTAC86U watchdog: start ddns.
Jun  9 06:24:14 RTAC86U rc_service: watchdog 1218:notify_rc start_ddns watchdog
Jun  9 06:24:14 RTAC86U custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun  9 06:24:14 RTAC86U ddns: IP address, server and hostname have not changed since the last update.
Jun  9 06:24:44 RTAC86U watchdog: start ddns.
Jun  9 06:24:44 RTAC86U rc_service: watchdog 1218:notify_rc start_ddns watchdog
Jun  9 06:24:44 RTAC86U custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun  9 06:24:44 RTAC86U ddns: IP address, server and hostname have not changed since the last update.
Jun  9 06:25:14 RTAC86U watchdog: start ddns.
Jun  9 06:25:14 RTAC86U rc_service: watchdog 1218:notify_rc start_ddns watchdog
Jun  9 06:25:14 RTAC86U custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun  9 06:25:14 RTAC86U ddns: IP address, server and hostname have not changed since the last update.
Jun  9 06:25:44 RTAC86U watchdog: start ddns.
Jun  9 06:25:44 RTAC86U rc_service: watchdog 1218:notify_rc start_ddns watchdog
Jun  9 06:25:44 RTAC86U custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun  9 06:25:44 RTAC86U ddns: IP address, server and hostname have not changed since the last update.
Jun  9 06:27:14 RTAC86U watchdog: DDNS Retry reach MAX.(0), DDNS Recover Time set 41

1686307445931.png
 
I finally had a chance to update my AC68U from 386.10 to 386.11, and the update pushed the nvram allocation up to the space limit (65536 bytes), so I did a reset which got the initial usage down to ~56000 bytes. After completing most of the configuration, usage went up to ~58000 bytes which is still leaves plenty of margin.
 
I finally had a chance to update my AC68U from 386.10 to 386.11, and the update pushed the nvram allocation up to the space limit (65536 bytes), so I did a reset which got the initial usage down to ~56000 bytes. After completing most of the configuration, usage went up to ~58000 bytes which is still leaves plenty of margin.
Did you run the script clear_vpnclients.sh as indicated in the 386.11 change log directions?
- CHANGED: Reduce max OpenVPN clients to 2 for RT-AC68U and
DSL-AC68U due to lack of NVRAM on these two
models. Note that existing settings are not
automatically removed, you must run the following
command over SSH to remove them from nvram and
the /jffs/openvpn/ directory:

clear_vpnclients.sh

A backup will be saved in /jffs/openvpn_backup.tgz.
 
Strange behaviour of Transmission with 386.11. With previous 386.10 and Tramsmission 3.00-19 all worked like a charm for years.
15 days ago I updated RT-AC66U B1 firmware to 386.11. Transmission still working fine until some days ago when amtm updated it to 4.0.3-2.
From now on I'm not able to start it at all (see pse related post HERE).
It seems from a @abir1909 post, seems that the only solution is to downgrade firmware to 386.10.
 
Last edited:
Strange behaviour of Transmission with 386.11. With previous 386.10 and Tramsmission 3.00-19 all worked like a charm for years.
15 days ago I updated RT-AC66U B1 firmware to 386.11. Transmission still working fine until some days ago when amtm updated it to 4.0.3-2.
From now on I'm not able to start it at all (see pse related post HERE).
It seems from a @abir1909 post, seems that the only solution is to downgrade firmware to 386.10.
AX86U i am on 388.1 with transmission 4.0.3-2 and it's working. once updated to 388.2_2 it stopped working.
 
Hello.

I love Asus Merlin, and I always try to keep up to date on firmware versions.
But.. I need 3 openvpn servers, not just 2.
Beside of the obvious answer of reverting back to the previous firmware version... is there any way to enable a third openvpn server by script?
Thank you.
 
Welcome to the forums @Drock128.

The only reliable way is to buy a new router, bonus: no script needed. :)
 
Hello.

I love Asus Merlin, and I always try to keep up to date on firmware versions.
But.. I need 3 openvpn servers, not just 2.
Beside of the obvious answer of reverting back to the previous firmware version... is there any way to enable a third openvpn server by script?
Thank you.
IIRC you have to run the "removal script" to delete those existing entries. If that's the case, flash back to a previous version of the firmware (which should restore all 5), then re-upgrade to this version of the firmware. Then either don't run the removal script or edit it so it only deletes VPN4 and VPN5, perhaps?
 
IIRC you have to run the "removal script" to delete those existing entries. If that's the case, flash back to a previous version of the firmware (which should restore all 5), then re-upgrade to this version of the firmware. Then either don't run the removal script or edit it so it only deletes VPN4 and VPN5, perhaps?
The firmware is hardcoded for a fixed number of clients. The script merely clears unused variables, you are still limited to two clients.
 
Sluggish after upgrade, then again after 20 hours on 86U - had to fall back to 10. Be aware.
I'm about to ditch .11 and try .10. .11 was giving me too many problems. I had to redo the installation twice, and even after that, I was rebooting twice a day mainly because of unbound but also scribe. The latest round was when I tried to enter a AiMesh node to the system. Unbound became very unhappy. I got it working after a couple of reboots, but then I could not log into the CLI, and various clients could not connect. Enough already. Others have reverted back to .10, so I think I will do the same, and wait to see if a future .12 is better.
 
I'm about to ditch .11 and try .10. .11 was giving me too many problems. I had to redo the installation twice, and even after that, I was rebooting twice a day mainly because of unbound but also scribe. The latest round was when I tried to enter a AiMesh node to the system. Unbound became very unhappy. I got it working after a couple of reboots, but then I could not log into the CLI, and various clients could not connect. Enough already. Others have reverted back to .10, so I think I will do the same, and wait to see if a future .12 is better.
What you should do if you want to see the problem solved, is to try the official Asus firmware and see if the problem replicates there.

If it does, you can send a report from the WebGUI and attach logs.

The report feature is under "Administration/Feedback" - describe what you did and what the problem is- in the free-text field, and remember to check "attach logs" so they can use it to problem-solve.

In that way, hopefully Asus will correct the mistake and the fix will make its way to the GPL firmware and subsequently Merlin's firmware, which uses the GPL firmware.
 
AC68U dirty upgrade to 386.11 from 386.7, all okay except VPN Server: clients connect just fine, but no internet or LAN access, it is like the kill switch is on. Factory Reset and same issue. Any ideas?
Thank you,
 
If you factory reset and then used a backup config file, you negated the factory reset you performed.
 
Thx L&LD. I just reset and manually configured, same result. VPN clients connect with no problem, and clients even show the correct VPN IP, but there is no data throughput. It is so close to working...

I can switch Android client 3.3.4 to another AC68U VPN on 386.7 and no problem at all. For some reason the AC68U 386.11 VPN is not getting data through. Any other ideas? I use mostly default settings on VPN as I have done for years and the AC68U's have been solid workhorses.

Note: Actually the test unit in this case is a AC68P that I went from 386.7 to 386.11 but I think for most purposes it acts like a AC68U.

Thank you in advance for any other ideas! Would be great to bring my other AC68U's up to 386.11, but need to get this VPN issue straightened out.
 

Latest threads

Sign Up For SNBForums Daily Digest

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