Sorry, last question then I’ll leave you alone. Just for completion sake, if I wanted the option of changing profile, say to pia_Manchester, I’ve tried issuing the following…
sudo systemctl stop openvpn
sudo systemctl start openvpn@pia_Manchester
I’ve tried this and it works, and sticks for a reboot, but then reverts back to pia_Ireland on the next reboot. If it’s a more complicated process, I’m happy with the setup you’ve supported me with so will just leave it as is, but would be useful to know. Thanks.
You could try using /etc/default/openvpn again. Change the autostart to whichever profile you want to use.
Alternately you just create a conf file called VPN.conf for example, and just change the remote to the IP/domain name of the server/profile you wish to connect to. Then you would restart openvpn(sudo systemctl restart openvpn) or reboot. This approach will work better if you only have one conf file, so rename the others to something like pia_Manchester.conf.bak.
Hi. This setup has been really solid, connecting on boot every time. However, I checked my vero this morning before heading off to work to find the vpn had disconnected overnight. I thought the restart on failure code would automatically reconnect anytime the vpn connection was lost, or is that just in relation to when the vero boots up? Thanks.
It should, but would need to see systemctl status openvpn & systemctl status openvpn@vpn (assuming you are now using vpn.conf as previously suggested), when the vpn has disconnected. Without seeing these, one thing you could try is increasing RestartSec= ; could possibly trying to restart to quick.
You can try this, but I think I had issues with this; when we moved from jessie. Another option is to change it to `Restart=on-abnormal’
Ok, thanks guys. I was under the impression that automatic restart would occur if the vpn tunnel failed to connect- I assumed this had been the reason for inconsistent connections on boot previously, and the reason why I’m now able to connect every time on boot. Worth noting that I reverted back to using PIA’s name server profile to connect (as it seems to work every time and figured it would give me more options to reconnect if the connection to a server drops, as opposed to connecting via one static IP address/single server). Maybe I should revert back to the static ip address as a starting point.
I was under the impression, the approach I suggested should work and I believe it used to; when I had a similar set-up.
I suggest you leave the setup as it is and the provide the output of the systemctl status (openvpn & openvpn@) from my previous post. I think we can get to work using this approach, if not achieve it with a systemd watchdog instead.
Ok cheers Tom, will do. Just to check… I need to wait for the vpn connection to drop by itself before providing the results of systemctl status openvpn & systemctl status openvpn@pia_Ireland? (Didn’t end up using vpn.conf). If so, I’ll post results when it next happens.
As an update…vpn remained connected overnight which is good. However, on reboot, an issue I’d been having prior to latest progress showed up- Kodi is connected to internet (system info- network) and vpn is connected (curl ipinfo.io/ip) but I can’t open any addons. Had to grab logs from command line as MyOSMC wouldn’t open.
FYI, throughout this process the vero has been assigned a static ip address via MyOSMC (192.168.0.2) outside of my router’s DHCP range (which I changed to start from 192.168.0.5) and has also had private internet access’ dns servers assigned to it via MyOSMC.
I can see from the log that ‘cannot resolve host address’ may suggest I shouldn’t be using name server in the pia_Ireland.conf file, but it’s been rock solid connecting via name server in recent days. This seemingly random behaviour (to a novice like me) makes me hesitant in pursuing a solution as these issues may be nothing to do with the Vero setup itself but more to do with my network environment/ rubbish router.
Really appreciate your help so far and would welcome any comments, but I’m conscious of taking up your time on this issue so may well admit defeat and throw in the towel. Cheers.
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/The Toy.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Absolutely Fabulous: The Movie.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Charlie Brooker's Antiviral Wipe.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Absolutely Fabulous: The Movie.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Absolutely Fabulous: The Movie.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Absolutely Fabulous: The Movie.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Absolutely Fabulous: The Movie.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Absolutely Fabulous: The Movie.ts'
Jul 07 16:02:52 osmc tvheadend[1314]: dvr: unable to stat file '/media/SD Card/Recordings/Absolutely Fabulous: The Movie.ts'
TVHeandend is having issues and the client is unable to connect. I suggest try temporarily setting the record path on the TVHeadend (http://192.168.0.2:9981) to something like /home/osmc/Movies and then rebooting and see if that resolves the issue. If it does that you will need to work out whats happened to the SD CARD.
Hi Tom. Had no idea tvheadend could be playing a part in this. I actually reformatted the SD card recently and haven’t re-added the recording path. Ok will try. Cheers.
No. It’s simply that OpenVPN is starting before the network is up:
Jul 07 16:02:31 osmc ovpn-pia_Ireland[334]: RESOLVE: Cannot resolve host address: ireland.privateinternetaccess.com:1198 (Name or service not known)
Jul 07 16:02:32 osmc systemd[1]: Reached target Network is Online.
There is a separate issue, which is that the network then disconnects and reconnects but that’s not relevant to the “cannot resolve host address” message you see.
This error was also in the first log, but I was hoping it was being caused by TVheanded issue. I suggest disabling the dnsleaktest addon and see if you can reproduce the issue.
Same issue with dns leak test addon disabled unfortunately. Probably not relevant but I’ve noticed my ping speed and download speed is significantly slower than usual when using speed tester addon. Don’t know if there’s some conflict happening that could be relevant to the network connection. Anyway, thanks guys. Amazed by your patience and willingness to help but totally fine to draw a line under this.