What's new

How to delay vpn start at boot

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

hs222

New Around Here
Hello,
my rt-ac68u is configured to start a openvpn client at boot time, but it often fails, although I have no problem when I manually start the client once router is up. Therefore I would like to know how I could delay the effective start of the vpn service until the wan is restored.

To be more precise I think one origin of the openvpn client problem is caused by the NTP update because it is happening in the middle of the negotiation process. Indeed, before NTP update time is "Dec 1 01:00:xx" and after it is the real current time, and that's why the remote openvpn server is complaining about a timeout and is aborting the TLS negotiation!!!

here is some log excerpt
Code:
.....
Dec  1 01:00:28 openvpn[793]: Expected Remote Options hash (VER=V4): .....
Dec  1 01:00:28 openvpn[794]: UDPv4 link local: [undef]
Dec  1 01:00:28 openvpn[794]: UDPv4 link remote: [AF_INET]....

Dec  1 01:00:29 WAN Connection: WAN was restored.   <---- Here the wan is available
Dec  1 01:00:29 ntp: start NTP update     <-- still waiting for time update

......
Dec  1 01:00:30 openvpn[794]: TLS: Initial packet from [AF_INET].....  <-negociation start here "Dec 1"
Dec  1 01:00:31 openvpn[794]: VERIFY OK: ...
Dec  1 01:00:31 openvpn[794]: VERIFY X509NAME .....
....

Dec  1 01:00:32 ntp: start NTP update  <----- Still waiting for time update.....
...
May 23 21:23:00 openvpn[794]: Data Channel Encrypt:  <---- negociation continues here on "May 23"!!
May 23 21:23:00 openvpn[794]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
May 23 21:23:00 openvpn[794]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
May 23 21:23:00 openvpn[794]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

May 23 21:23:00 openvpn[794]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)   
^------------- TIMEOUT !!!!
May 23 21:23:00 openvpn[794]: TLS Error: TLS handshake failed
May 23 21:23:00 rc_service: ntp 668:notify_rc restart_upnp
May 23 21:23:00 rc_service: waitting "restart_nasapps" via  ...
May 23 21:23:01 openvpn[794]: TCP/UDP: Closing socket
May 23 21:23:01 openvpn[794]: SIGUSR1[soft,tls-error] received, process restarting
May 23 21:23:01 openvpn[794]: Restart pause, 2 second(s)

So is it possible (at boot) to delay the open vpn client start until the wan is up and the time has been set?

thanks.
 
Assuming you're vpn client start script listen to nvram boot complete, from there you can:
- variant 1, buggy, sleep like 60 sec hopping ntp will update
- variant 2, less buggy, ntp update in the script, and continue after (eliminate original problem)
- variant 3. wait like 30s (or research wan connection and wait for it) , ntp update, continue

You'll have to think of something you don't have internet connection (worst case link up, small net reach , but no Internet)
 
Marian, thanks for your help. I've found a solution for this issue. Not sure it's the best but anyway it seems to fix my problem.

First I tried to add a waiting loop into the openvpn-event script, then in the wan-start script but it was useless because actually the client process is started in parallel in another thread. Finally I 've decided to change the way the client is started. I've removed the option "start with wan" in the web interface and now I use the wan-start script to start the openvpn client.

Here my wan-start script :
Code:
#!/bin/sh
c=0
while [ $(date +%Y) -lt 2015 -a $c -lt 20 ]
do
c=`expr $c + 1`
logger "waiting for time adjustment...."
sleep 1s
done
logger "starting vpn 1"
service start_vpnclient1

The script waits until the time is set (waits as long as current year < 2015) but not more than 20 seconds (just to in case....), then it starts the vpn client
 
378.54 will check if the NTP update has occurred before starting the OpenVPN client/servers, if not it will wait for a while to give it time to occur.
 
If you can't use version RMelin mentioned, I was thinking to something more like forcing the ntp update. Something like:

ntpupdate(){
local success=1
ping -n -c 1 -W 1 -w 1000 $1 1>/dev/null 2>&1
if [ $? = 0 ]; then
ntpclient -c 1 -d -s -l -h $1 1>/dev/null 2>&1
if [ $? = 0 ]; then success=0; fi
fi;
echo $success
}

c=0;
#or get the ntp server from nvram
n=$(ntpupdate "pool.ntp.org");
while [ $c -lt 5 -a $n -ne 0 ]; do
sleep 4;
echo "sleep, $c";
c=`/usr/bin/expr $c + 1`
n=$(ntpupdate "$1");
done

Now you can check again n to see if success and start you're vpnclient (or error nicely).



Marian, thanks for your help. I've found a solution for this issue. Not sure it's the best but anyway it seems to fix my problem.

First I tried to add a waiting loop into the openvpn-event script, then in the wan-start script but it was useless because actually the client process is started in parallel in another thread. Finally I 've decided to change the way the client is started. I've removed the option "start with wan" in the web interface and now I use the wan-start script to start the openvpn client.

Here my wan-start script :
Code:
#!/bin/sh
c=0
while [ $(date +%Y) -lt 2015 -a $c -lt 20 ]
do
c=`expr $c + 1`
logger "waiting for time adjustment...."
sleep 1s
done
logger "starting vpn 1"
service start_vpnclient1

The script waits until the time is set (waits as long as current year < 2015) but not more than 20 seconds (just to in case....), then it starts the vpn client
 
Last edited:
Hi Marian,
I've reused a version of your ntpupdate function in my script, it's far better than my poor date tricks and by the way it makes me think that I urgently need to refresh my shell script skills...
Thank you I appreciate your help.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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