OpenVpn server not starting on AC68U since 384.15

[jopoegar]

On my AC-68U the OpenVpn server does not start at boot since the update to 384.15. The same on 384.16. I can start the server by hand on the configpage. After downgrading to 384.14_2 the server starts again on boot and everything works fine. Any idea what is the cause and what I can do about it.

 

[bbunge]

On my AC-68U the OpenVpn server does not start at boot since the update to 384.15. The same on 384.16. I can start the server by hand on the configpage. After downgrading to 384.14_2 the server starts again on boot and everything works fine. Any idea what is the cause and what I can do about it.

Same issue on my two AC68U's. Was able to set up openvpn_server2 on both but only one starts on reboot. As OP, I can start server1. Can't revert or reset as both routers are 30 miles away in lockdown. I have "other" means of remote access. Otherwise 384.16 working swell.

 

[RMerlin]

You seem to have a disk-related issue. The diskmon service is taking an unusual amount of time to start, on both firmware versions. It's just by luck that the VPN server happens to run on the older version, not because something is broken in 384.16.

 

[QMax]

OpenVPN server works fine here on AC66_B1 (same firmware) with .15. No problems restarting the router.

Inviato dal mio Z2 utilizzando Tapatalk

 

[bbunge]

You seem to have a disk-related issue. The diskmon service is taking an unusual amount of time to start, on both firmware versions. It's just by luck that the VPN server happens to run on the older version, not because something is broken in 384.16.

My two have no USB devices. Could it be related to /jffs issues?

 

[bbunge]

Log from one router

 

[RMerlin]

Log from one router

Your boot events are also getting skipped because the diskmon service is taking longer than expected to restart.

I don't know the exact reason why, and since Asus moved the event handling code to closed sources a few years ago, debugging/adjusting this is difficult.

 

[RMerlin]

The stalled diskmon restart request comes from ntpd sync. Either of you having made any particular changes related to NTP?

EDIT: Stating diskmon takes 5 seconds on my own RT-AC68U. On yours, it's taking a minute - causing any other queued event to be skipped as the hardcoded timeout limit is 15 seconds. So, I am unable to reproduce on my own RT-AC68U, something particular in your setup causing this unusually long start time.

 

[bbunge]

The stalled diskmon restart request comes from ntpd sync. Either of you having made any particular changes related to NTP?

EDIT: Stating diskmon takes 5 seconds on my own RT-AC68U. On yours, it's taking a minute - causing any other queued event to be skipped as the hardcoded timeout limit is 15 seconds. So, I am unable to reproduce on my own RT-AC68U, something particular in your setup causing this unusually long start time.

No. The only change was to turn off DoT and use CF 1.1.1.2/1.0.0.2. And this was after I had a no start on one router with 384.15 just before I upgraded to 384.16 b3. I had also enabled IPV6.

 

[bbunge]

Hmm... Just disabled IPV6, set DNS to 1.1.1.1/1.0.0.1 rebooted and both OpenVPN servers came up.
F.Y.I. my WAN IPV4 is a static address. IPV6 was DHCP-PD on Comcast.

 

[bbunge]

Update: I was able to get the OpenVPN servers running on my two AC68U's. Had to:
Return the OpenVPN servers to default which erased all the certs and settings.
Reboot the router
Enable and configure the OpenVPN servers which required a new config file for the remote clients.
Rebooted the router to make sure the servers started.

Today I re-enabled IPV6 on one router and it did not get an address from DHCP-PD. So I disabled IPV6 and left it off.
I suspect it was an IPV6 DHCP failure that caused OpenVPN server to not start in the first place(?).

 

[jopoegar]

Thanks for your help. I succeeded in solving the problem, though I am not sure what is the deeper cause. The direct cause I presume is indeed the stalling of the diskmon start. The relation with NTP is not clear to me. Possible diskmon needs to be restarted after the time is synced at boot. I noticed in my logs (on different locations), but also in the log of bbunge, the line : rc_service: wanduck 176:notify_rc stop_ntpd and 15 seconds later: rc_service: wanduck 176:notify_rc start_ntpd. So possible Wanduck stalls the boot-process for 15 seconds, causing time-outs on other processes?

My 68U is behind the router of my ISP in the DMZ of that router. My Asus was on the WAN-side configured with a static IP. Because Wanduck manages the WAN interface I tried changing the configuration to automatic IP. I installed 384.16 and the VPN-server came up just fine. Diskmon start within 3 seconds, and in my bootlog are no loglines of Wanduck anymore.