VPN Client down and SmartTV is now a StupidTV

[eibgrad]

Ok let's see. So I would have:

#!/bin/sh

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/init2-start"

mkdir -p $SCRIPTS_DIR

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
    exit 1
fi

cat << "EOF" > $SCRIPT
#!/bin/sh
set -x # uncomment/comment to enable/disable debug mode
(
CLIENT_ID='1'

while sleep 60; do
    if [ "$(nvram get vpn_client${CLIENT_ID}_state)" != "0" ]; then
        if ! ps | grep -q [v]pnclient${CLIENT_ID}; then
            service restart_vpnclient${CLIENT_ID}
            echo "vpnclient${CLIENT_ID} restarted"
        fi
    fi
done

) 2>&1 | logger -t $(basename $0)[$$] &
EOF
chmod +x $SCRIPT

Then in my init-start script:

#!/bin/sh
[ -x /jffs/dnscrypt/manager ] && /jffs/dnscrypt/manager init-start
cru a amtm_RebootScheduler "0 5 * * * service reboot" # Added by amtm
/jffs/scripts/init2-start

Does that look right?

This looks correct.

 

[jorgsmash]

This looks correct.

Ok I have implemented it. I assume this script is not meant to be called from the terminal because I just ran

# /jffs/scripts/init2-start

and it showed

# + basename /jffs/scripts/init2-start
+ logger -t init2-start[7481]

And left the terminal hanging until I press ctrl+c. I assume this is due to the trailing '&' sign at the end of your script? What is the purpose for that?

Also, for the VPN clients on the router, are they referred to as CLIENT_ID='1' CLIENT_ID='2' and so on?

 

[eibgrad]

Ok I have implemented it. I assume this script is not meant to be called from the terminal because I just ran

# /jffs/scripts/init2-start

and it showed

# + basename /jffs/scripts/init2-start
+ logger -t init2-start[7481]

And left the terminal hanging until I press ctrl+c. I assume this is due to the trailing '&' sign at the end of your script? What is the purpose for that?

Also, for the VPN clients on the router, are they referred to as CLIENT_ID='1' CLIENT_ID='2' and so on?

The script creates a subprocess that runs continuously in the background. It runs in the background so it doesn't prevent other init scripts from running, or in any way prevent the bootup process from continuing. You only see those two particular lines of output when executed from the terminal because they are NOT part of that subprocess. That's the part of the script that tells the subprocess to send its output/messages to the syslog. So you can run it from the terminal, and it will work. But it's assumed you will normally run it on bootup where you will NOT have the opportunity to see any output (e.g., error messages). But if you examine the syslog, you'll always be able to confirm it ran (and in this case, continuing to run) and whether successfully or perhaps w/ errors.

IOW, it's designed to be user-friendly and give you feedback in a way that's useful, via the syslog.

 

[jorgsmash]

The script creates a subprocess that runs continuously in the background. It runs in the background so it doesn't prevent other init scripts from running, or in any way prevent the bootup process from continuing. You only see those two particular lines of output when executed from the terminal because they are NOT part of that subprocess. That's the part of the script that tells the subprocess to send its output/messages to the syslog. So you can run it from the terminal, and it will work. But it's assumed you will normally run it on bootup where you will NOT have the opportunity to see any output (e.g., error messages). But if you examine the syslog, you'll always be able to confirm it ran (and in this case, continuing to run) and whether successfully or perhaps w/ errors.

IOW, it's designed to be user-friendly and give you feedback in a way that's useful, via the syslog.

I see the syslog entries! I'll try it out and hopefully it works! My VPN client went down yesterday before I had this implemented but unfortunately on the vpn client page the status switch was switched to 'off' so I don't think this will turn it back on in that case. Could have been a fluke but I'm not sure why it switched to 'off'

What is your recommendation for running this on multiple vpn client instances?

 

[eibgrad]

I see the syslog entries! I'll try it out and hopefully it works! My VPN client went down yesterday before I had this implemented but unfortunately on the vpn client page the status switch was switched to 'off' so I don't think this will turn it back on in that case. Could have been a fluke but I'm not sure why it switched to 'off'

What is your recommendation for running this on multiple vpn client instances?

If I had known you needed it for multiple OpenVPN clients, I probably would have written it differently, to make that possible from the one script. But you could just make copies of the script, one dedicated to each OpenVPN client, and start each from the init-start script (init-client1-start, init-client2-start, etc.). Kind of tedious and messy, but in a pinch, it should work.

When I have some time, I'll see if I can rewrite it. In the meantime, I would just see if it helps the one OpenVPN client remain running. No point in enhancing the script to support multiple OpenVPN clients if it doesn't even help the one.

 

[jorgsmash]

If I had known you needed it for multiple OpenVPN clients, I probably would have written it differently, to make that possible from the one script. But you could just make copies of the script, one dedicated to each OpenVPN client, and start each from the init-start script (init-client1-start, init-client2-start, etc.). Kind of tedious and messy, but in a pinch, it should work.

When I have some time, I'll see if I can rewrite it. In the meantime, I would just see if it helps the one OpenVPN client remain running. No point in enhancing the script to support multiple OpenVPN clients if it doesn't even help the one.

Thanks for all your efforts in this! You don't have to re-write it if you don't want to. I can make copies and test it once I come to the conclusion that this is helping for Client 1. I have one client set to block routed clients if the tunnel goes down, and one that will still allow the connection. My TV is on the vpn client that will still allow the connection even if the VPN tunnel goes down but even with that set, I still lost connectivity when the tunnel broke. If I recall when that happened a while back, I do think that the switch for the VPN was still set to 'On' but the IP was lost for some reason.

Thanks again!

 

[jorgsmash]

If I had known you needed it for multiple OpenVPN clients, I probably would have written it differently, to make that possible from the one script. But you could just make copies of the script, one dedicated to each OpenVPN client, and start each from the init-start script (init-client1-start, init-client2-start, etc.). Kind of tedious and messy, but in a pinch, it should work.

When I have some time, I'll see if I can rewrite it. In the meantime, I would just see if it helps the one OpenVPN client remain running. No point in enhancing the script to support multiple OpenVPN clients if it doesn't even help the one.

So I have my router set to reboot every morning at 5 am. This am my phone and my PC could not access Internet when connected to wifi. I logged into the router and checked the VPN client. It was on, the tunnel was up and I had an IP. Couldn't access the Internet though. But once I turned the VPN off and back on connectivity was restored. I figure if the router reboots every day that it should solve issues with the tunnel. But it doesn't seem like it. Is there a better approach to making sure this doesn't happen? Maybe having the tunnel reconnect every 12 hrs or so?