Posts by outcave

Hi.
I have a similar problem, see here: LibreELEC

Hi.
No news about this???

Thanks

Quote from chewitt

It will fix your VPN, but will also break binary compatibility with everything else that uses SSL (and expects LibreSSL). Not impossible, but not a quick change either. You energies would be more productive figuring out the patch/hack for LibreSSL ..

Should I find a patch for LibreSSL? And how? LibreSSL actually do not want to resolve it.... How Can I do?
I expect LibreELEC should take charge and find a solution for it! As it is now LibreELEC do not "work" for certificate with year after 2038: it's a fact...

Quote from adiadore

i understood your problem, but im telling you now, i switched from ipvanish to another vpn (they used a >2038 expiry date and couldnt change it) and it works again on LibreELEC v7.90.005 and on the latest kodi 17 millhouse alphas

i gathered some information about other vpn's if you want to leave hide.me

these are all in the openvpn manager:
vpn unlimited - openvpn cert valid until 2023
ibVPN - 2020
celo - every 2 years
AirVPN - 2024

I don't want to leave Hide.me, now I'm using it without problems with LibreELEC version 7.0.2. For the future? May be I will compile OpenSSL and overwrite to LibreSSL

Hi guys.
Please no make confusion .

The Certificate problem is on all versions of LibreELEC v7.90.004 ALPHA and next versions because these versions has inside the newest version of LibreSSL. These new versions of LibreSSL does not work with Certificate that will expire after year 2038 on 32 bit operating system (such as Raspberry Pi 2). It seems that LibreSSL does not want to solve this issue and it seems that also LibreELEC does not want to switch to OpenSSL (OpenSSL works fine also on 32 bit operating system, so OpenSSL is OK on Raspberry Pi).

So the problem is not Hide.me, is not IPVanish, is not VPNManager addon. The problem is only LibreSSL on 32 bit operating system.

Now you have various way to follow to solve the issue:

1. Contact your VPN "provider" and ask to have a new Certificate (CA) that will expire before 2038. Hide.me is "friendly" and I'm quite sure that will give you a new Certificate if you will explain the problem. So open a Support Ticket on Hide.me website.
2. Contact LibreELEC team to ask to use OpenSSL instead to use LibreSSL (see these my posts and later: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0))
3. Contact LibreSSL to ask to solve the issue (I think this is useless, see here: Year 2038 bug on LibreSSL 32bit regression between 2.2.x and 2.3.x · Issue #207 · libressl-portable/portable · GitHub)
4. Use a more old version of LibreELEC (version 7.0.2 works fine because it uses an old version of LibreSSL) or use OpenELEC 6.0.3 that uses OpenSSL

Actually I'm using LibreELEC version 7.0.2 with the last version of VPNManager addon made by zomboided and I can connect to Hide.me VPN without problems.

About Hide.me, there WAS a problem on routing table on OpenELEC / LibreELEC (VPN was connected but all traffic does not go via VPN) now solved since VPNManager addon version 1.9 ("redirect-gateway def1" option was added into VPNManager addon).

More info about my analysis on routing table for Hide.me see this my post: OpenELEC Mediacenter - OpenELEC Forum - VPN Manager for OpenVPN (38/63)

Enjoy.

Quote from vpeter

It is something which needs to be fixed in libressl. If this is some serious bug I'm sure it will be fixed asap (in libressl).

LibreSSL will not solve this issue.
I hope the LibreELEC community will swtich to OpenSSL...

Hi.
This behavior is on LibreELEC and OpenELEC on Raspberry Pi 2, I don't know if it happens also on others system.
I don't know why but when I specify DNS (then DNS Server not obtained from the DHCP) by default the system put specific routes of these DNS address into routing table.

This is the route print of LibreELEC when IP fields (IP, subnet mask, default gateway, DNS...) are given by DHCP (so DNS Servers automatically obtained from DHCP):

LibreELEC:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

This is the route print of LibreELEC when I manual configure DNS Servers (8.8.8.8 and 8.8.4.4 in this case):

LibreELEC:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
8.8.4.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
8.8.8.8         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

As you can see the 8.8.8.8 and 8.8.4.4 (DNS Servers) have their specific routes...

On my experience this behavior is in OpenELEC 6.x and LibreELEC (Jarvis 16.1) v7.0.2 and also LibreELEC (Krypton) v7.90.004 and next versions.
I know how to remove that routes, but my question is why the system put these unsefull routes?
How can say to OS to do not put the DNS Servers route when manually assign DNS Server?

In a VPN environment this give a DNS leak because the traffic to DNS Servers will go via eth0 (default) and not via the tun0 interface (VPN interface) and on my experience there is a very strange behavior: also if I remove these routes the system (LibreELEC / OpenELEC) will still and always uses these routes for DNS lookup, so the DNS query will go "directly" to DNS Servers (via eth0 interface) not using the VPN tunnel (via tun0 interface); I have checked this strange behavior with "netstat": there are established connection to DNS from eth0 and not from tun0!

This is the route print of LibreELEC when I manual configure DNS Servers (8.8.8.8 and 8.8.4.4 in this case) and when OpenVPN is up:

LibreELEC:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.3.200.254    0.0.0.0         UG    0      0        0 tun0
8.8.4.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
8.8.8.8         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
10.3.200.0      *               255.255.255.0   U     0      0        0 tun0
159.122.133.197 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.1     *               255.255.255.255 UH    0      0        0 eth0

As you can see, also if the VPN connection is UP and the default gateway (destination) is via VPN, the DNS routes are there and the connection to DNS goes via eth0 interface and not via tun0......

This the netstat:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 192.168.1.65:44941      google-public-dns-a.google.com:domain ESTABLISHED 294/connmand
udp        0      0 192.168.1.65:47546      google-public-dns-b.google.com:domain ESTABLISHED 294/connmand
udp        0      0 192.168.1.65:35954      google-public-dns-a.google.com:domain ESTABLISHED 294/connmand
udp        0      0 192.168.1.65:58527      google-public-dns-b.google.com:domain ESTABLISHED 294/connmand

As you can see, ESTABLISHED connections to the DNS Servers are via eth0 and not via tun0.
This happens also if I manual remove the DNS entry for the routing table ("route del 8.8.8.8" and "route del 8.8.4.4"): the "connmand" process will always goes directly (using eth0) and not via VPN (using tun0).
If I kill the "connmand" process (with PID 294 in this case), the "connmand" process will automatically starts again and the DNS connection, however, will always goes directly (using eth0) and not via VPN (using tun0).
I think this is a wrong behavior of connman.

Any solutions / patch?
Thanks!

Quote from outcave

The DATE and TIME of RPI2 are correct (via NTP)

Hi again.
The problem is LibreSSL 2.3.x (inside LibreELEC v7.90.004 ALPHA and next versions) that on the Raspberry Pi (and also on all 32 bit operating system) will not works with certificate that will expires after 2038 due to "Year 2038 bug".

See here: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)

Hope in a FIX.

Quote from chewitt

The error says the certificate notAfter time is invalid, so either there is bad data in the certificate (unlikely if the same cert works on 7.0.2) or maybe the device date/time is incorrect which causes an odd result.

The DATE and TIME of RPI2 are correct (via NTP)

Hi.
I'm trying to connect to Hide.me VPN service with OpenVPN on LibreELEC (Krypton) v7.90.004 ALPHA on a Raspberry Pi 2.
I have this error:

LibreELEC:~/.kodi/addons/service.vpn.manager/HideMe # openvpn Milan\ \(UDP\).ovpn
Wed Aug 31 20:01:22 2016 OpenVPN 2.3.11 armv7ve-libreelec-linux-gnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [IPv6] built on Aug  8 2016
Wed Aug 31 20:01:22 2016 library versions: LibreSSL 2.3.5, LZO 2.09
Wed Aug 31 20:01:22 2016 WARNING: file '/storage/.kodi/addons/service.vpn.manager/HideMe/pass.txt' is group or others accessible
Wed Aug 31 20:01:22 2016 WARNING: file '/storage/.kodi/addons/service.vpn.manager/HideMe/ta.key' is group or others accessible
Wed Aug 31 20:01:22 2016 Control Channel Authentication: using '/storage/.kodi/addons/service.vpn.manager/HideMe/ta.key' as a OpenVPN static key file
Wed Aug 31 20:01:22 2016 UDPv4 link local: [undef]
Wed Aug 31 20:01:22 2016 UDPv4 link remote: [AF_INET]159.122.133.197:4000
Wed Aug 31 20:01:22 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Aug 31 20:01:22 2016 VERIFY ERROR: depth=2, error=format error in certificate's notAfter field: C=MY, ST=Wilayah Persekutuan, L=Labuan, O=eVenture Limited, OU=Certificate Authority, CN=Hide.Me Root CA
Wed Aug 31 20:01:22 2016 OpenSSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Aug 31 20:01:22 2016 TLS_ERROR: BIO read tls_read_plaintext error
Wed Aug 31 20:01:22 2016 TLS Error: TLS object -> incoming plaintext read error
Wed Aug 31 20:01:22 2016 TLS Error: TLS handshake failed
Wed Aug 31 20:01:22 2016 SIGUSR1[soft,tls-error] received, process restarting

May be some Root CA missed in LibreSSL?

Just for your info, with OpenELEC 6.0.3 and with LibreELEC (Jarvis 16.1) v7.0.2 I was able to connect with the exactly same .ovpn file.

I hope in your help.
Thanks.