Menu
What's new
By:
Filters Better Search

vpnclient1 up / down scripts (openvpn) ac86u help needed

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

See two error lines.
Code: 
May 12 10:48:03 openvpn-event[31845_***DEBUG]: Error: Address /jffs/scripts/vpnclient1-route-pre-down is invalid
May 12 10:48:17 openvpn-event[32176_***DEBUG]: Error: Address /jffs/scripts/vpnclient1-route-up is invalid
Here are those two again.

vpnclient1-route-pre-down
Code: 
#!/bin/sh
set -x
(
MYROUTER=$(nvram get computer_name)
if [ -d "/tmp/mnt/"$MYROUTER ]; then
   MOUNT="/tmp/mnt/"$MYROUTER
else
   MOUNT="/tmp"
fi
LOCKFILE=$MOUNT"/vpnclient"$VPN_ID"-monitor"
if [ -z "$(grep "NOKILL" $LOCKFILE)" ];then
   PID=$(cat $LOCKFILE)
   [ "$PID" != "NOKILL" ] && kill $PID
   rm $LOCKFILE
   logger -st "($(basename $0))" $$ "VPN Failover Monitor self-destruct requested....." $LOCKFILE "RC="$?
fi
) 2>&1 | logger -st $(basename $0)"[$$_***DEBUG]"
vpnclient1-route-up
Code: 
#!/bin/sh
set -x
(
VPN_ID=${dev:4:1}
sh /jffs/scripts/VPN_Failover.sh "$VPN_ID" "delay=60" &
) 2>&1 | logger -st $(basename $0)"[$$_***DEBUG]"
 
Butterfly Bones said:
Thanks again. Deleted openvpn-event and recreated, did not attempt to include the "Marineau Hack" lines that I added previously. Checked all 3 scripts, verified chmod 755 on all.
Code: 
May 12 10:48:17 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1553 10.200.0.54 10.200.0.53)
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + basename /jffs/scripts/openvpn-event
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + scr_name=openvpn-event[32176]
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + vpn_name=client1
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + vpn_script_name=vpnclient1-route-up
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + nvram get vpn_script_state
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + vpn_script_state=vpnclient1-route-pre-down
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + nvram set vpn_script_state=vpnclient1-route-up
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + [ vpnclient1-route-up = vpnclient1-route-pre-down ]
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + [[ -f /jffs/scripts/vpnclient1-route-up ]]
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + sh /jffs/scripts/vpnclient1-route-up tun11 1500 1553 10.200.0.54 10.200.0.53
May 12 10:48:17 openvpn-event[32176_***DEBUG]: Error: Address /jffs/scripts/vpnclient1-route-up is invalid
May 12 10:48:17 openvpn-event[32176_***DEBUG]: *** Usage:
May 12 10:48:17 openvpn-event[32176_***DEBUG]:  dw/dh/db <physical address in hex> <number>
May 12 10:48:17 openvpn-event[32176_***DEBUG]:  dw/dh/db <-k> <virtual address in hex> <number>
May 12 10:48:17 openvpn-event[32176_***DEBUG]:  sw/sh/sb <physical address in hex> <data value1> <data value2> ..<data valueN>
May 12 10:48:17 openvpn-event[32176_***DEBUG]:  sw/sh/sb <-k> <virtual address in hex> <data value1> <data value2> ..<data valueN>
May 12 10:48:17 openvpn-event[32176_***DEBUG]:  fw/fh/fb  <physical address in hex> <data value> <length>
May 12 10:48:17 openvpn-event[32176_***DEBUG]:  fw/fh/fb <-k> <virtual address in hex> <data value> <length>
May 12 10:48:17 openvpn-event[32176_***DEBUG]:   -s (currently works with physical addresses for d*/s*/f* commands
May 12 10:48:17 openvpn-event[32176_***DEBUG]: and virtual addresses for s*/f* commands)
May 12 10:48:17 openvpn-event[32176_***DEBUG]: + exit 0
May 12 10:48:17 ovpn-client1[31945]: Initialization Sequence Completed
Click to expand...

OK, so if you issue
Code: 
memaccess /jffs/scripts/vpnclient1-route-up
then you should see all the dross regarding the "*** Usage:" text.
But clearly I can't find any explicit reference to the 'memaccess' utility in either of the scripts.

However, ff you look closely at the dross, notice the two "sw/sh/sb" lines?
And if you look at the standard method we use within scripts to schedule the scripts...see something similar?
Code: 
sh /jffs/scripts/vpnclient1-route-up tun11 1500 1553 10.200.0.54 10.200.0.53

"sh /" appears, so here's a wacky idea.o_Oo_Oo_O

In 'openvpn-event' and 'vpnclient1-route-up' very carefully replace
Code: 
sh /jffs/scripts
with
Code: 
/jffs/scripts

and retest.;)

Code: 
 xxxxxxxxxx@RT-AC86U:/usr/sbin# ./sh /jffs/scripts/vpnclient1-route-pre-up

Error: Address /jffs/scripts/vpnclient1-route-pre-up is invalid

*** Usage:
 dw/dh/db <physical address in hex> <number>
 dw/dh/db <-k> <virtual address in hex> <number>
 sw/sh/sb <physical address in hex> <data value1> <data value2> ..<data valueN>
 sw/sh/sb <-k> <virtual address in hex> <data value1> <data value2> ..<data valueN>
 fw/fh/fb  <physical address in hex> <data value> <length>
 fw/fh/fb <-k> <virtual address in hex> <data value> <length>
  -s (currently works with physical addresses for d*/s*/f* commands
and virtual addresses for s*/f* commands)
 
Last edited:
F i n a l l y ! !

Too big for SNB. Complete log on pastebin.
https://pastebin.com/fsYAaMzi

Code: 
12:24:35 v1.15 VPN Client Monitor: Checking VPN Client 1 connection status....
May 12 12:24:36 (VPN_Failover.sh): 5060 VPN Client Monitor: VPN Client 1 status OK
May 12 12:24:36 vpnclient1-route-up[5056_***DEBUG]: ^[[93m^[[92m        VPN Client 1 connection status OK
May 12 12:24:36 openvpn-event[5047_***DEBUG]: vpnclient1-route-up[5056_***DEBUG]: ^[[93m^[[92m        VPN Client 1 connection status OK
May 12 12:24:36 vpnclient1-route-up[5056_***DEBUG]: ^[[93m
May 12 12:24:36 vpnclient1-route-up[5056_***DEBUG]:         Will check VPN Client 1 connection status again in 30 secs.....@12:25:06
May 12 12:24:36 openvpn-event[5047_***DEBUG]: vpnclient1-route-up[5056_***DEBUG]: ^[[93m
May 12 12:24:36 openvpn-event[5047_***DEBUG]: vpnclient1-route-up[5056_***DEBUG]:
Now my syslog is a mess, but a good mess. :) :D ;) :p :cool:
 
Butterfly Bones said:
F i n a l l y ! !

Too big for SNB. Complete log on pastebin.
https://pastebin.com/fsYAaMzi

Code: 
12:24:35 v1.15 VPN Client Monitor: Checking VPN Client 1 connection status....
May 12 12:24:36 (VPN_Failover.sh): 5060 VPN Client Monitor: VPN Client 1 status OK
May 12 12:24:36 vpnclient1-route-up[5056_***DEBUG]: ^[[93m^[[92m        VPN Client 1 connection status OK
May 12 12:24:36 openvpn-event[5047_***DEBUG]: vpnclient1-route-up[5056_***DEBUG]: ^[[93m^[[92m        VPN Client 1 connection status OK
May 12 12:24:36 vpnclient1-route-up[5056_***DEBUG]: ^[[93m
May 12 12:24:36 vpnclient1-route-up[5056_***DEBUG]:         Will check VPN Client 1 connection status again in 30 secs.....@12:25:06
May 12 12:24:36 openvpn-event[5047_***DEBUG]: vpnclient1-route-up[5056_***DEBUG]: ^[[93m
May 12 12:24:36 openvpn-event[5047_***DEBUG]: vpnclient1-route-up[5056_***DEBUG]:
Now my syslog is a mess, but a good mess. :) :D ;) :p :cool:
Click to expand...

Is is indeed a truly obscure/weird 'bug' and unless @RMerlin etc. can shed any light on this, then this could potentially impact/break many scripts on the HND models.

You can now comment out the three debugging lines, and I suggest you add the following to 'vpnclient1-route-up' so that script 'vpnclient1-route-up' leaves a visible eye-catcher in Syslog.
Code: 
logger -t "($(basename $0))" $$ "Requesting VPN Failover monitor with 60 sec delay....."
 
Martineau said:
Is is indeed a truly obscure/weird 'bug' and unless @RMerlin etc. can shed any light on this, then this could potentially impact/break many scripts on the HND models.

You can now comment out the three debugging lines, and I suggest you add the following to 'vpnclient1-route-up' so that script 'vpnclient1-route-up' leaves a visible eye-catcher in Syslog.
Code: 
logger -t "($(basename $0))" $$ "Requesting VPN Failover monitor with 60 sec delay....."
Click to expand...
Thank you for hanging in there to get this resolved. I truly appreciate it. I added the logger line to vpnclinet1-route-up and commented out the other debug lines.

Funny but the vpn kept restarting and using htop I found 8 instances or VPN_Failover running and killed them all. Now I will check it one more time and if all is good, I will reinstall syslog-ng to handle the messages from VPN_Failover and ChkWAN.
 
Here is the confirmation that VPN_Failover is working now.
Code: 
May 12 13:17:43 openvpn-routing: Configuring policy rules for client 1
May 12 13:17:43 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1553 10.200.0.26 10.200.0.25)
May 12 13:17:43 (vpnclient1-route-up): 22040 Requesting VPN Failover monitor with 60 sec delay.....
May 12 13:17:43 ovpn-client1[21900]: Initialization Sequence Completed
May 12 13:17:43 (VPN_Failover.sh): 22041 v1.15 1 delay=60
May 12 13:18:43 (VPN_Failover.sh): 22041 VPN Client Monitor: Checking VPN Client 1 connection status....
May 12 13:18:43 (VPN_Failover.sh): 22041 VPN Client Monitor: VPN Client 1 status OK
May 12 13:19:13 (VPN_Failover.sh): 22041 VPN Client Monitor: Checking VPN Client 1 connection status....
May 12 13:19:14 (VPN_Failover.sh): 22041 VPN Client Monitor: VPN Client 1 status OK
May 12 13:19:44 (VPN_Failover.sh): 22041 VPN Client Monitor: Checking VPN Client 1 connection status....
May 12 13:19:44 (VPN_Failover.sh): 22041 VPN Client Monitor: VPN Client 1 status OK
Thank you, thank you, thank you!
 
Butterfly Bones said:
Thank you for hanging in there to get this resolved. I truly appreciate it. I added the logger line to vpnclinet1-route-up and commented out the other debug lines.

Funny but the vpn kept restarting and using htop I found 8 instances or VPN_Failover running and killed them all.
Click to expand...
Did the VPN fail to initialise correctly within 60 seconds e.g TLS issues?​

In your environment, there should only ever be one instance of the VPN_Failover.sh script at any time?

Ensure 'vpnclient1-route-pre-down' code to delete an associated running instance of VPN_Failover.sh
Code: 
VPN_ID=${dev:4:1}
 
MOUNT="/tmp"
TRACKFILE="${MOUNT}/vpnclient$VPN_ID"
LOCKFILE=$TRACKFILE"-monitor"

# Don't wait for VPN_Failover.sh itself to test for the existence of the Lockfile BEFORE it attempts a restart!
if [ -z "$(grep "NOKILL" $LOCKFILE)" ];then
   PID=$(cat $LOCKFILE)
   [ "$PID" != "NOKILL" ] && kill $PID
   rm $LOCKFILE
   logger -st "($(basename $0))" $$ "VPN Failover Monitor self-destruct requested....." $LOCKFILE "RC="$?
fi
However, just in case the 'vpnclient1-route-pre-down' wasn't executed, I suggest you modify 'vpnclient1-route-up' to surround the call to '/jffs/scripts/VPN_Failover.sh' with a 'duplicates' check i.e. replace the single line with the five lines:
Code: 
# Only create the VPN Failover monitor if it doesn't already exist
if [ -z "$(ps | grep -v grep | grep "VPN_Failover.sh $VPN_ID")" ];then
   logger -t "($(basename $0))" $$ "Requesting VPN Failover monitor with 60 sec delay....."
   /jffs/scripts/VPN_Failover.sh "$VPN_ID" "delay=60" &
fi
 
Last edited:
Martineau said:
Did the VPN fail to initialise correctly within 60 seconds e.g TLS issues?​

In your environment, there should only ever be one instance of the VPN_Failover.sh script at any time?

Ensure 'vpnclient1-route-pre-down' contains
Code: 
VPN_ID=${dev:4:1}
 
MOUNT="/tmp"
TRACKFILE="${MOUNT}/vpnclient$VPN_ID"
LOCKFILE=$TRACKFILE"-monitor"

# Don't wait for VPN_Failover.sh itself to test for the existence of the Lockfile BEFORE it attempts a restart!
if [ -z "$(grep "NOKILL" $LOCKFILE)" ];then
   PID=$(cat $LOCKFILE)
   [ "$PID" != "NOKILL" ] && kill $PID
   rm $LOCKFILE
   logger -st "($(basename $0))" $$ "VPN Failover Monitor self-destruct requested....." $LOCKFILE "RC="$?
fi
However, just in case, I suggest you modify 'vpnclient1-route-up'
Code: 
# Only create the VPN Failover monitor if it doesn't already exist
if [ -z "$(ps | grep -v grep | grep "VPN_Failover.sh $VPN_ID")" ];then
   logger -t "($(basename $0))" $$ "Requesting VPN Failover monitor with 60 sec delay....."
   /jffs/scripts/VPN_Failover.sh "$VPN_ID" "delay=60" &
fi
Click to expand...
No, the vpn starts very quickly, within seconds. The first start after adding the debug lines was slow, but without them it is very quick.

Verified only one instance of VPN_Failover.sh running using both ps and htop.

Thank you, I will make those changes to the scripts and test. I plan to reboot to test from cold start, but a basketball game 7 needs to complete first. :)
 
Martineau said:
erhaps @RMerlin may have previously encountered this obscure utility?
Click to expand...

Debugging tool part of BCM's HND SDK. If I recall, BCM were symlinking to a totally retarded name that was already used by another well-known tool - namely sh... I thought I had removed it long ago however.
 
Martineau said:
However, just in case, I suggest you modify 'vpnclient1-route-up'​
Code: 
# Only create the VPN Failover monitor if it doesn't already exist
if [ -z "$(ps | grep -v grep | grep "VPN_Failover.sh $VPN_ID")" ];then
   logger -t "($(basename $0))" $$ "Requesting VPN Failover monitor with 60 sec delay....."
   /jffs/scripts/VPN_Failover.sh "$VPN_ID" "delay=60" &
fi
Click to expand...

I had to make a slight addition to this for it to work, I was getting this error.
Code: 
May 12 17:13:59 openvpn-routing: Tunnel re-established, restoring WAN access to clients
May 12 17:13:59 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1553 10.200.0.26 10.200.0.25)
May 12 17:13:59 (vpnclient1-route-up): 6261 Requesting VPN Failover monitor with 60 sec delay.....
May 12 17:13:59 ovpn-client1[6105]: Initialization Sequence Completed
May 12 17:13:59 (VPN_Failover.sh): 6269 v1.15 delay=60
May 12 17:13:59 (VPN_Failover.sh): 6269 **ERROR** VPN Client '' is INVALID (1-5 only)

I added one line to the script using your previous vpnclient1-route-up. Added "VPN_ID=${dev:4:1}" as line 6 below. Used the previous version you posted.
Code: 
#!/bin/sh
# vpnclient1-route-up
# Only create the VPN Failover monitor if it doesn't already exist
if [ -z "$(ps | grep -v grep | grep "VPN_Failover.sh $VPN_ID")" ];then
   logger -t "($(basename $0))" $$ "Requesting VPN Failover monitor with 60 sec delay....."
   VPN_ID=${dev:4:1}
   /jffs/scripts/VPN_Failover.sh "$VPN_ID" "delay=60" &
fi
Now it runs successfully.
Code: 
May 12 17:24:23 openvpn-routing: Tunnel re-established, restoring WAN access to clients
May 12 17:24:23 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1553 10.200.0.34 10.200.0.33)
May 12 17:24:23 (vpnclient1-route-up): 7411 Requesting VPN Failover monitor with 60 sec delay.....
May 12 17:24:23 ovpn-client1[7151]: Initialization Sequence Completed
May 12 17:24:23 (VPN_Failover.sh): 7419 v1.15 1 delay=60
May 12 17:25:23 (VPN_Failover.sh): 7419 VPN Client Monitor: Checking VPN Client 1 connection status....
May 12 17:25:23 (VPN_Failover.sh): 7419 VPN Client Monitor: VPN Client 1 status OK
 
Martineau said:
OK, so if you issue
Code: 
memaccess /jffs/scripts/vpnclient1-route-up
then you should see all the dross regarding the "*** Usage:" text.
But clearly I can't find any explicit reference to the 'memaccess' utility in either of the scripts.

However, ff you look closely at the dross, notice the two "sw/sh/sb" lines?
And if you look at the standard method we use within scripts to schedule the scripts...see something similar?
Code: 
sh /jffs/scripts/vpnclient1-route-up tun11 1500 1553 10.200.0.54 10.200.0.53

"sh /" appears, so here's a wacky idea.o_Oo_Oo_O

In 'openvpn-event' and 'vpnclient1-route-up' very carefully replace
Code: 
sh /jffs/scripts
with
Code: 
/jffs/scripts

and retest.;)
Click to expand...
Thank you for this! Ever since I upgraded my AC86 to 384.11, my openvpn-event sub-scripts would not execute. This has fixed the problem. Any idea what changed in 384.11 to cause this? Or is it just coincidence that it started following the upgrade?
 
stoli412 said:
Thank you for this! Ever since I upgraded my AC86 to 384.11, my openvpn-event sub-scripts would not execute. This has fixed the problem. Any idea what changed in 384.11 to cause this? Or is it just coincidence that it started following the upgrade?
Click to expand...

As per post #69 it appears @RMerlin may have overlooked this [Alpha] RT-AC86U v382.1, and simply forgot to propogate it in v384.11 for HND models.

i.e. totally brain-dead decision by BCM - symlinking 'memaccess' to a totally retarded name that was already used by another well-known tool - namely sh...

Code: 
ls -lahF /usr/sbin | grep memaccess

lrwxrwxrwx    1 admin    root          14 May  9 00:29 db -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 dh -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 dw -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 fb -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 fh -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 fw -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 sb -> /bin/memaccess*

lrwxrwxrwx    1 admin    root          14 May  9 00:29 sh -> /bin/memaccess*         <<=== WTF!!!!!!!

lrwxrwxrwx    1 admin    root          14 May  9 00:29 sw -> /bin/memaccess*
 
Last edited:
Martineau said:
As per post #69 it appears @RMerlin may have overlooked a previous non-HND commit, and simply omitted to include it in v384.11 for HND models.

i.e. totally brain-dead decision by BCM - symlinking 'memaccess' to a totally retarded name that was already used by another well-known tool - namely sh...

Code: 
ls -lahF /usr/sbin | grep memaccess

lrwxrwxrwx    1 admin    root          14 May  9 00:29 db -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 dh -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 dw -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 fb -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 fh -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 fw -> /bin/memaccess*
lrwxrwxrwx    1 admin    root          14 May  9 00:29 sb -> /bin/memaccess*

lrwxrwxrwx    1 admin    root          14 May  9 00:29 sh -> /bin/memaccess*         <<=== WTF!!!!!!!

lrwxrwxrwx    1 admin    root          14 May  9 00:29 sw -> /bin/memaccess*
Click to expand...
BIG ops... :eek:
 
Martineau said:
OK, but it is also on my RT-AC86U?
Click to expand...

Looks like it got added a second time in the mainline branch, so that second time was enabled. Probably from a GPL merge, because on master it's still properly disabled.
 
eibgrad said:
Hmm, me thinks perhaps the OP is running into the problem I discussed previously.
Click to expand...
I don't know if it was intentional but it made me laugh reading your comment and seeing your profile picture, I imagined a dog commenting in a tech forum.
 
pandora.jpg
eibgrad said:
Certainly not intentional.

That's my dog pal Bingo, who we lost in 2011 to old age. We still miss him somethin' terrible. Here's the original photo (circa 2003).

http://bit.ly/v1w5lb
Click to expand...
I'm sorry for your loss :(
On 2011 our dog Pandora was born (see picture from Jan 2018), I also miss her since she lives with my parents back in Mexico. :(
Remember all dogs go to heaven.:)
 
My VPN connection had problems three times overnight, and the VPN_Failover script /vpnclient1-route-pre-down / vpnclient1--route-up handled it perfectly. I only know by checking the log and not finding everything offline this morning.
Code: 
May 16 03:57:27 RT-AC86U-4608 (VPN_Failover.sh): 6965 VPN Client Monitor: Checking VPN Client 1 connection status....
May 16 03:57:33 RT-AC86U-4608 (VPN_Failover.sh): 6965 **VPN Client Monitor: Switching VPN Client 1 to VPN Client 2 (Reason: VPN Client 1 STATE=2;Connected but SLOW!)
May 16 03:57:33 RT-AC86U-4608 (VPN_Failover.sh): 6965 **VPN Client Monitor: Terminating VPN Client 1
May 16 03:57:33 RT-AC86U-4608 (VPN_Failover.sh): 6965 Waiting for VPN Client 1 (VPN Unlimited Stream 1) to disconnect.....
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 VPN Client 1 (VPN Unlimited Stream 1) disconnect'd in 1 secs
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 *Warning VPN Client 2 not configured? - auto IGNORED/SKIPPED
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 VPN Client Monitor: Checking VPN Client 2 connection status....
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 **VPN Client Monitor: Switching VPN Client 2 to VPN Client 3 (Reason: VPN Client 2 STATE=0;Disconnected)
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 *Warning VPN Client 3 not configured? - auto IGNORED/SKIPPED
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 VPN Client Monitor: Checking VPN Client 3 connection status....
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 **VPN Client Monitor: Switching VPN Client 3 to VPN Client 4 (Reason: VPN Client 3 STATE=0;Disconnected)
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 *Warning VPN Client 4 not configured? - auto IGNORED/SKIPPED
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 VPN Client Monitor: Checking VPN Client 4 connection status....
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 **VPN Client Monitor: Switching VPN Client 4 to VPN Client 5 (Reason: VPN Client 4 STATE=0;Disconnected)
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 *Warning VPN Client 5 not configured? - auto IGNORED/SKIPPED
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 VPN Client Monitor: Checking VPN Client 5 connection status....
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 **VPN Client Monitor: Switching VPN Client 5 to VPN Client 1 (Reason: VPN Client 5 STATE=0;Disconnected)
May 16 03:57:35 RT-AC86U-4608 (VPN_Failover.sh): 6965 Waiting for VPN Client 1 (VPN Unlimited Stream 1) to connect.....
May 16 03:57:55 RT-AC86U-4608 (VPN_Failover.sh): 14860 v1.15 1 delay=60
May 16 03:57:55 RT-AC86U-4608 (VPN_Failover.sh): 6965 VPN Client 1 (VPN Unlimited Stream 1) connect'd in 18 secs
 
You must log in or register to reply here.

Similar threads

chetstone
Which user script to use to start a daemon at boot-up?
Replies
3
Views
414
chetstone
chetstone
D
Random timeouts on Firmware:3004.388.8_4
Replies
6
Views
451
dineshgyl
D
T
Troubles with VPN Client + DDNS Setup on GT-BE98
Replies
5
Views
448
Tuntenfisch
T
T
[Help] Problems setting up OpenVPN
Replies
7
Views
492
Thookie
T
S
wan-event sometimes not triggered during WAN event
Replies
2
Views
1K
salvo
S
Similar threads
Thread starter Title Forum Replies Date
Rob Bowlby fwupdate.asuswrt-merlin.net - diversion.ch Down? Asuswrt-Merlin 7
N RT-AX88U wireless shuts down at irregular intervals Asuswrt-Merlin 8
V RT-AX88U Link Down on PC boot Asuswrt-Merlin 0
P In dnsmasq, how do I stop overriding an address if the server goes down? Asuswrt-Merlin 1
M AX82U issues with WAN port going down every day Asuswrt-Merlin 2
G multiple wired ports down Asuswrt-Merlin 5
skeal Attached drive not idling down as the firmware says and is set for Asuswrt-Merlin 6
visortgw asuswrt-merlin.net Website Site Down? Asuswrt-Merlin 18
C hardware down-/up-load graphics miss torrent Asuswrt-Merlin 0
L Custom DDNS vs Drop Down List for Same Provider Asuswrt-Merlin 3

Similar threads

Latest threads

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!

Members online

Total: 832 (members: 27, guests: 805)
Top