Hi.
I have a similar problem, see here: LibreELEC
Posts by outcave
-
-
Hi.
No news about this???Thanks
-
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... -
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 - 2024I 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 OpenSSLActually 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.
-
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):
CodeLibreELEC:~ # 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):
CodeLibreELEC:~ # 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:CodeLibreELEC:~ # 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:
CodeProto 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! -
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.
-
-
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:
Code
Display MoreLibreELEC:~/.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.