Hi. Hoping someone can offer some advice. My vero 4K+ is occasionally unable to connect to the internet on boot (tested both wired and wireless), even though it will have the correct ip address assigned. When this happens, the weather icon - which will normally pop up on boot after tvheadend has connected - doesn’t, then I find the eth0 not connected message in network settings. This recently happened to my parents’ Vero after installing an osmc update (which has an identical vpn setup to my box) so I’m guessing this is the problem.
I’ve set up private internet access using openvpn via the command line, which auto starts on boot and works really well. However, I skipped the instruction to change the nameserver ip addresses in /etc/resolv.conf to PIAs on the advice of the very helpful Tom_Doyle, and instead chose to create a static ip address in osmc settings and change primary and secondary DNS settings to those of private internet access (209.222.18.222/218) to prevent DNS leaks. I’m using a NowTV router and my parents use a sky router. Is there anything obvious that I’ve set up incorrectly? Thanks.
Hey Sam. Just pinged 8.8.8.8 and a sequence of time stamps are produced which I assume is what should happen. Says zero packet loss. I cannot remember when this started happening but assumed it was not a problem with the vero (or specific update) but more to do with how I’ve set my dns server up with Sky/NowTV routers. If it helps at all, when things are working fine I will often get a busy sign on my weather/internet icon when I stop using an addon or sometimes when I stop playing a channel via tvheadend, which last around 5 seconds.
Hi Tom. Since using the Brian Hornsby addon, I did a fresh install and have been using openvpn from command line ever since. I also didn’t bother messing with ip tables after that fresh install. Thanks.
This is expected behaviour. Is the Eth0 not connect issue occurring with the affected now? If so I would agree with Sam’s suspicion that is a dns issue, please try pinging google.com to confirm.
If the issue isn’t currently occurring, we may have to wait till it is for some more diagnostic info. Next time it occurs, could please trying pinging 8.8.8.8 and google.com and post the response here. It would also be a good test to see if stopping openvpn fixes the issue.
In the mean time could you please provide the output of ifconfig or issue iifconfig | paste-log and post the the link provided.
Ok, will do. No, the issue isn’t occurring now. I get decent stretches of time where it’s fine but once it happens, it seems to get locked and take a number of reboots to remedy.
Out of curiosity, could it possbly help to change the nameserver ip addresses in /etc/resolv.conf to PIAs and configure Vero’s network using DHCP, removing the static IP address and DNS info I manually entered?
The output of ifconfig, looks ok. Reporting a few drop packets, but if your not having issues when the connection is up; I would say its not relevant to this issue and I wouldn’t worry about it.
From a quick google its looks like it may be possible to do it via connmanctl, its not something I’ve tried before.
Ah ok. I was thinking I could just do the following from the instructions I followed…
sudo apt-get install openresolv
Add the following to the bottom of vpnname.conf:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
Then configure vero network using DHCP.
I’m not even sure how necessary it is to do anything with my dns settings. I do get the feeling that having changed my primary and secondary dns servers may be messing with things.
Hi. Having read more posts on the osmc forum following your comments, I realised that although I set a static ip on my Vero, I hadn’t reserved that ip/ mac address on my NowTV router. No other devices have been assigned the same address as the Vero, however, having now done this, I don’t seem to be getting those occassional ‘busy’ signs (weather icon) when exiting addons/ tvheadend channel and connection to the internet on boot (which I also tell by the weather icon loading) seems to be snappier. Early days, but could this have potentially been causing an issue?
Hi. In case it helps anyone, I though I’d share how I finally got a guaranteed openvpn connection to private internet access vpn every time I reboot. I’ve tried setting up private internet access via the command line and using Brian Hornsby’s addon with an autoexec.py file- I’ve settled on the latter. Firstly, the PIA ovpn file needed to include the IP address, not the server name address. Also, a big issue I solved was with my router. Probably obvious to some, but rather than just create a static ip address on the vero (with pia’s primary and secondary dns) and reserving that address on my router, I needed to change the DHCP range on the router and assign the vero an address outside of this range. I can now connect to PIA every time on boot. All very new to me but I’m guessing you were right and this was a dns conflict issue. Thanks for your help!
Hi. Think I spoke too soon. Moving the vero to an address outside of router’s DHCP range and triggering an ovpn file with an ip address (as opposed to name server) has definitely helped a lot. Been rock solid so far in fact, until a standard reboot last night. Brian Hornsby’s addon notified me that it had connected on boot but didn’t actually connect to a vpn, leaving me with my ISP’s IP address. Can anyone advise on what could cause this please? I have wait for network enabled with an autoexec.py script to trigger the process. Could the script itself have triggered before the network was up on this occasion? I have no experience with systemd scripts, but could this be a better option as I could tell it to wait for network? (if this is indeed the problem). Sorry to hassle you, I just want this process to be rock solid going forward. If it’s difficult to advise because of all the potential issues within my own network environment, I completely understand. Thanks.
Fair enough, although that question was really about the relationship between autoexec.py scripts and wait for network. It may take a while to get this issue to occur again but will upload logs if it does. Would still be interested to know about this relationship in the meantime though.
I suspect wait for network did as it should, kodi did not start until the network was up, then the autoexec.py. But maybe a issue occurred PIAs end meant a connection to the VPN could not be established.
With the current approach kodi will start once the your network is up, regardless of the VPN connection being up or down. If you went back to systemd, kodi would still start regardless; but the following can be added to the openvpn-client@ systemd unit:
Restart=on-failure
RestartSec=5s
Then openvpn will restart when the connection fails to establish or drop.
Actual you need to create a copy in /etc/systemd/system and make the changes to that, process is done as follows:
Wow thanks Tom. I’ll give this a shot when work calms down. Just to clarify, would using this method mean going back to setting up the vpn via command line and ditching the Brian Hornsby addon? Thanks again for your help (and patience).