WAN connection dropping out after 24 hours uptime

Help and Support
1

Once OSMC has been running for about 24 hours the WAN connection seems to drop out and I can’t get any response when ping google.com is run via the terminal.

After I do a reboot the WAN connection returns.

I’m able to SSH into the OSMC 4.4.8-3-osmc running on a brand new RPi 3 which I have freshly installed OSMC on a week ago.

I’m running a systemctl to load a vpn connection when OSMC starts so I suspect this might be what’s causing the issue. So far I’ve not been able to pinpoint the exact culprit.

2

OSMC doesn’t handle WAN connections beyond establishing a default route.

The only thing I can think of that would tamper with this is something like VPN or modifying routes. This isn’t strictly supported by OSMC unless configured via ConnMan.

Edit: I think you edited your post to mention VPN. This will be removing the default route, or changing it to something that isn’t acceptable.

3

Running $ sudo systemctl status openvpn@uk-london.service -l when the WAN connection has been lost, shows that the connection to the VPN is timing out (I think).

systemctl only shows about 10 lines of output from openvpn.

Do you know where the openvpn log for the process systemctl is creating is stored? Might help to pinpoint what’s going wrong.

Here’s the output I mentioned:

$ sudo systemctl status openvpn@uk-london.service -l
● openvpn@uk-london.service - OpenVPN connection to uk-london
   Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled)
   Active: active (running) since Thu 2016-05-19 21:58:37 BST; 24h ago
  Process: 254 ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf (code=exited, status=0/SUCCESS)
 Main PID: 274 (openvpn)
   CGroup: /system.slice/system-openvpn.slice/openvpn@uk-london.service
           └─274 /usr/sbin/openvpn --daemon ovpn-uk-london --status /run/openvpn/uk-london.status 10 --cd /etc/openvpn --config /etc/openvpn/uk-london.conf

May 20 22:39:36 portable-pi ovpn-uk-london[274]: Attempting to establish TCP connection with [AF_INET]104.238.169.110:443 [nonblock]
May 20 22:39:46 portable-pi ovpn-uk-london[274]: TCP: connect to [AF_INET]104.238.169.110:443 failed, will try again in 5 seconds: Connection timed out
May 20 22:39:46 portable-pi ovpn-uk-london[274]: SIGUSR1[soft,init_instance] received, process restarting
May 20 22:39:51 portable-pi ovpn-uk-london[274]: UDPv4 link local: [undef]
May 20 22:39:51 portable-pi ovpn-uk-london[274]: UDPv4 link remote: [AF_INET]104.238.169.149:9201
May 20 22:40:51 portable-pi ovpn-uk-london[274]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 20 22:40:51 portable-pi ovpn-uk-london[274]: TLS Error: TLS handshake failed
May 20 22:40:51 portable-pi ovpn-uk-london[274]: SIGUSR1[soft,tls-error] received, process restarting
May 20 22:40:53 portable-pi ovpn-uk-london[274]: UDPv4 link local: [undef]
May 20 22:40:53 portable-pi ovpn-uk-london[274]: UDPv4 link remote: [AF_INET]104.238.169.99:53
4

After a lot of back and forth it seems to be that there’s some bug in the version of OpenVPN I’m using which is causing this issue.

For future reference this was with the following setup:

$ openvpn --help
OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Nov 19 2015

$ uname -a
Linux portable-pi 4.4.13-5-osmc #1 SMP PREEMPT Mon Jun 20 16:34:27 UTC 2016 armv7l GNU/Linux

The fix:
I created a CRON script that ran every few hours to restart the VPN connection.

5

I doubt its a “bug” in OpenVPN as such, its more likely that your method of using OpenVPN is not compatible with connman. connman is probably refreshing the routing table and thus stomping on the routes OpenVPN has added.

The only way to get VPN working properly with connman is to use a proper VPN agent for connman so that the VPN operation is properly integrated with connman rather than trying to work around connman. As it is, connman is not aware of your VPN so it will sometimes clash with it.

6

Yes – this will be the issue. ConnMan will adjust route for captive portal detection periodically, which will overwrite the OpenVPN route.

Proper solution is to implement OpenVPN via Connman-VPN.

7

Thanks for the suggestions… any pointers would be great. But I’m guessing something along the lines of this template connman conf I found should do the job?

[provider_openvpn]
Type = OpenVPN
Name = PIA VPN
Host = uk-london.privateinternetaccess.com
Domain = privateinternetaccess.com
OpenVPN.Port = 1194
OpenVPN.CACert = /etc/openvpn/ca.crt
OpenVPN.AuthUserPass = /etc/openvpn/pass.pia
OpenVPN.AuthNoCache = 0
OpenVPN.CompLZO = yes
OpenVPN.RemoteCertTls = server

Do I then remove any conf files I have in /etc/openvpn? And would I need to added any additional local IP settings to the connman conf file?

And do I even need to have OpenVPN still installed as it doesn’t look like Connman uses it. Favouring OpenConnect instead.

8

Not when it’s working properly, no.

I think @DBMandrake and I need to discuss best approach for ConnMan VPN. I think we need a VPN agent or connman-vpn service running at the very least.

S

9

Ok… I’m happy to try some things out if that would help?

10

This would be developed and tested internally first.

11

Is there a timeframe or a likelihood that this might be developed and tested in the next couple of months?

12

When it’s ready. It will come with the new My OSMC at the earliest.

13

Thanks.

When is thew new My OSMC meant to be released?

14

There is no ETA at this time.

15

I’m not sure anyone on the team uses OpenVPN. If they did we could probably speed up the integration. It will happen eventually, but it’s low on the list for now.

Hope that this helps

Sam

16

The issue of VPN causing WAN to drop out now appears fixed in OSMC Feb 2017 that uses Kodi 17.

Thank you!