Using a Harmony 950 with a Hub, so basically an Elite. Also switched over from IR to Bluetooth based control on the Harmony. So the harmony typical delay is gone finally, but I have to test it a bit further with bluetooth, because sometimes the bluetooth pairing gets lost. This issue could be related to the early stage of Odroid C2 development, and I'm switching the builds a lot.
any idea why my vpn connection is not validating? i press it, and nothing happens...
Does the progress bar show something? If it fails, at the end there is a button where you can read the openvpn.log. You could tell us what is written there as a reason.
great to read that you found the reason for the limititation! But how did you know to ask them for this specific thing (never heard of something like "bridge mode" on ISPs side)?
I have the current release installed on Odroid C2 (LibreELEC-Odroid_C2.aarch64-7.90.010).
Everything works fine but the remote is not working.
I want to use the remote of my bluray player (Pioneer) with the Odroid C2 and LibreELEC with the build in IR receiver.
If I run irw there is nothing recognized.
Many thanks in advance for your help.
You would have to follow this guide to use other remotes than Windows Media Center remote or the official Odroid remote. Following the guide, LibreELEC (Lirc) will learn to use all the buttons of your Pioneer remote. You can then backup the created "/storage/.config/lircd.conf", so that you can reuse it whenever you make a reinstall of LibreELEC or so, thus avoiding to do all the steps again and again.
Pretty interesting infos you provide here!
So some conclusion is:
- As your Win 10 machine is limited with OpenVPN (PureVPN provider) similarly as your raspberry is, it means that choosing the OpenVPN protocoll is one part of your limitation
- Your further testing showed that the limit could be either because of the Port 53 (could be an indication of limitation withing your Network) or that PureVPN limits its own OpenVPN connections on Port 53. Or your Provider Limits the Port 53 intentionally.
- You know... I think that routers need to support "VPN Passthrough" for having the ability to use VPN clients on your machines. As your VPN is establishing tunnels successfully, that means that your router obviously supports vpn passthrough (as does almost every I think). But who knows... perhaps the router limits some ports or certain VPN protocols because of hardware limitations or so? May be I'm also wrong about necessity of VPN-Passthrough support, but I remember reading something like this once.
- It would be great if you could contact the PureVPN support and describe your problem and the results of this testing. Imagine they would explain you how to change the port (to lets say 25000, because you know already due to your crosscheck that it is fast) and still be able to use PureVPN. Then you could perhaps avoid this limit, and if not, then you would have the clue that is some other limitation by your ISP (limiting PureVPN intentionally) or by PureVPN in general because of OVPN bandwidth limits to their servers.
I found that Windows client of PureVPN is using nl.pointtoserver.com as host.
When i typed this host in Convert Host Name to IP Address or Find IP address of a host - e.g. find IP address of host name of
It came with 11 IP addresses:
Host Name : nl.pointtoserver.com
IP Address : 126.96.36.199 and 188.8.131.52 and 184.108.40.206 and 220.127.116.11 and 18.104.22.168 and 22.214.171.124 and 126.96.36.199 and 188.8.131.52 and 184.108.40.206 and 220.127.116.11 and 18.104.22.168
I have tested it in my ovpn file and the first speedtest i got was 23Mbit/s...However I get a feeling that the speedtest.py that i am using is not the right one...which one do you use?
Have tested several times with all dutch servers, including nl.pointtoserver.com (latest VPN Manager 2.3.0)...no difference...max 23Mbit/s, but mostly under 10Mbit/s. Also connected RPi to my ISP router....same results
If you look at vpn-servers for the "netherlands" servers, then you'll see nl1.pointtoserver.com as the DNS for PPTP, L2TP, SSTP, IKEv2 protocols. hcidata.info gives you the same server IP's for nl1.pointtoserver.com and nl.pointtoserver.com. Windows simply prefers the nonOpenVPN servers, because they perhaps produce less load or are more efficient, because of the easier encryption. Apparently you proved us that now that you can use the same servers in OpenVPN (which were meant for PPTP etc.), but then it is consequently building a OpenVPN tunnel. I have still the opinion that OpenVPN, altogether with PureVPN-servers, is the bottleneck in your chain. If it is not the raspberry (like zomboided said), then it is perhaps the PureVPN's servers, which limit OpenVPN somehow in favor of PPTP and other protocols.
You could test something else... you could take your windows machine and install official OpenVPN client there and make a speedtest with this connection instead of PureVPN clients PPTP etc. And perhaps the speedtest you used for windows is not appropriate for comparison with speedtest.py?
I am not familiar with VPNbook. I only used PureVPN so far, and it's okay for me.
You said you have a DD-WRT device there. I think it would be possible to establish a PPTP connection with DD-WRT. On the other hand PPTP has a weaker encryption and that's why faster I guess. Don't know whether that automatically means realistic security issues.
I understand....but what about the Windows 10 VPN connection of my PureVPN account which hits 90mbps? Several times over 110....which is even faster than my normal ISP connection speed
VPN connections are encrypted. Encryption takes some amount of processing power. So the CPU of your Win10 system can cope with decrypting even when the data comes with high throughput, the Raspberry has limited processing power... (I edited my last post, there I explain it also). Depends on your the way you established your VPN on Windows. Perhaps it was PPTP or so, which is faster/easier to decrypt I think. Anyways... At first you should make sure that the VPN was established correctly on your Win10 machine during testing and then you should make a comparison with the raspberry at the same time. Perhaps it turns out that OpenVPN servers are not just harder to decrypt for the raspberry, but may be also PureVPN assigns them less bandwidth compared to PPTP and the other protocols. It would be a question for the PureVPN support chat again.
Thanx for helping me out here.
So resume to understand VPN Connections:
- With a "default" PureVPN connection setup in VPN Manager be aware that there is an unbelievably massive security issue, because all ports are open (including SSH 22)
Correct, but the solution is simple and the Iptables rules/solutions are all mentioned in my thread I linked in my last post, so if you follow it, you should have no concerns about security.
- I have tested your Speedtest IP's (How do you get/know these IP's anyway?) from 9:00 AM to 12:00 AM, the fastest one had a 25 Mbit/s. 3 of them had a 1 or 2 time >23 Mbit/s hit, but later tests on the same IP's came up with 0-5 Mbit/s. The selected host at "Hosted by" was quite of influence in the tests.
I obtain the IPs by resolving the DNS (nl1-ovpn-udp.purevpn.net) with Convert Host Name to IP Address or Find IP address of a host - e.g. find IP address of host name of. When I had the same issues a year ago, the pureVPN live chat support suggested me this site and to use the direct server IPs instead of the DNS. That is why I came around with this proposal for solution. You should be aware that no cheap VPN provider will guarantee you perfect unlimited speed. There will always be limits... I mostly don't hit the limit with my 40MBit ISP speed, but you will hit it quite often with your 90MBit connection. Though, 25Mbit is still not so slow and you saw that I get more than 30 MBit with my speedtests (okay, it was night time, and perhaps the routing is somehow different in germany for some providers). It is certainly shit that you have 23MBit at one time and later only a very limited connection on the same server :/. This is something I would try to bother their support over and over again. Apparently netherland servers are used pretty frequently hmmm... You have 7 servers, I hope you can find one, which is more reliable than the others. Besides this, I have also my favourite swiss server as primary connection and it gets sometimes slow when streaming IPTV, and for this case I have specified the other IP's as additional 2nd, 3rd, 4th connections to cycle between then for this particular case. VPN Manager offers you all these possibilities with its great featureset.
I don't know about the influence of the "Hosted by" providers -_-. Again something the PureVPN Chat could help you with, or answer it.
- When I just used "nl1-ovpn-udp.purevpn.net" instead of an IP, 90% of the tested speeds were less than 4 Mbit/s
I assume that this is because nl1-ovpn-udp.purevpn.net assigns you in 90% of the time one of the slower servers. As I showed in my yesterdays speed test, there was one server (22.214.171.124), which was extremely slow no matter how many speed tests I did. In your case it is apparently in 90% of you connection attempts with nl1-ovpn-udp.purevpn.net that pureVPN decides to resolve it to 126.96.36.199 for your connection and then you end up with a slow connection. This was just an example. It is likely that my slow 188.8.131.52 is in your case one of the other 7 servers, may be even at the same time... who knows what the reason is... perhaps it is my ISPs routing, or the daytime of your connection attempt, which results in one or the other server being slower (more loaded with users/transfers) than the other servers --> Cycle the VPN connection to another server to avoid being limited.
- So 70% of the times the RPi makes a VPN connection, the speed does not hit above 4 Mbit/s.....I would say that VPN is not working for me? Or are there other settings (Routers, DNS) which are influencing the poor VPN Connection speed?
You said that you had connections respectively speedtests which exceeded 25MBit. So there might be no issue on your side at all. It might be just the simple reason, that PureVPN has too many people at the same time transferring big amount of data on the servers you want to use. It can be just as simple as it is... like a shared internet connection. Perhaps you should simply choose another VPN provider (at least for a testing period).
I am no network guy, though I think it is surely possible that routers / firewalls etc. influence the speed of a VPN connection. But in your case you had connections of 25MBit, so that means your setup is able to handle at least these speeds with OpenVPN... I don't know why the same setup would limit you to 1MBit some minutes later... sure... everything is possible and troubleshooting can be a pain in the ass, but it soulds more like an issue on PureVPNs side. And I can tell you that I also had speed issues... And I do also have sometimes speed issues without a VPN connection, because my ISP has technical issues... same things can happen to PureVPN servers. But especially the additional layer (VPN tunnel and VPN Provider) in your internet connection can obviously become an additional factor of bandwidth limitation. This is something you cannot avoid, but ideally you could lower the risk of bandwidth limitation by using a business 1000€/month VPN provider who is specialized on fast and reliable VPN connections for companies or so. PureVPN, IPVanish etc. are quite cheap for the service they provide you, and still they are quite fast and reliable... everything is a matter of reasonability or proportionality (not sure which expression is the correct one for this in english )
infinity85 , do I need to update the Pure connection list? I can't think why the DNS name would make a difference as both resolve to the same IP. I can believe that Pure workload balance, which maybe what's happening here?
No I don't think there is anything you should update as long as the servers list is up-to-date (I do get successful connections if using your default PureVPN list, so there is no general problem. Perhaps some countries are down, but in this case the people who use those countries could/would mention it to you).
I'm sure the DNS name makes no difference. As you say... it resolves to the same IP. But in this case there are simply 7 Servers (7 IP's) behind it and sometimes you simply get assigned to one of those 7 servers, which is quite slow. There's nothing you could do about it, other than to resolve every single country's DNS to its IP's and then to make seperate *.ovpn for every single IP. Afaik there are more than 140 countries listed at PureVPN... and If some of them have 7 or 10 or 5 seperate IP's behind the DNS', then you end up with up to 500 *.ovpn... that would make no sense at all in your addon :D. Your UserDefined function is totally appropriate to handle it manually, like I described some posts above. It is as you said, the PureVPN workload balance is kind of poor sometimes during establishing a connection.
I thought let's install a spare Windows 10 PC with a PureVPN connection on my Home Network. Established the VPN connection on the selected the dutch server (no other choice) and did a speedtest on Ookla: and Boooommmm...90mbps...several times
Why is this so fast?
Great to hear that! How did you establish the connection? Was it also via OpenVPN, or did you use the PureVPN software client? PureVPN offers the following VPN connection protocols: PPTP, L2TP, SSTP, IKEv2 OpenVPN-UDP and OpenVPN-TCP and some of them might be easier in encryption (less processing load on you Raspberry, that the other). On LibreELEC you do only have the choice to use OpenVPN afaik. The encryption there might load your Raspberries CPU's more, thus the CPU being the limiting factor. But As you said earlier... you achieved 25Mbit with the Raspberry, so the CPU is capable to cope with at least 25Mbit, 90MBit/s would even be too hard to achieve with a Raspberry Pi, because it has only a 100Mbit (theoretical) ethernet speed, and to make it even worse it is hooked up to the USB interface, sharing Ethernet transfers with USB transfers. Though, according to my knowledge the Raspberry Pi2 and especially RPi3 come very close to the theoretical limit of 100Mbit/s. May be the CPU limits a VPN throughbut to 50Mbit/s max, maybe it does more, just a guess.
When you made the speedtests with your windows machine... did you make comparison speedtests to the same servers at the same time (no matter whether some minutes later) with your raspberry? I could imagine that the raspberry would also have good speeds at the same time and same servers, because I still assume that the sporadic bottleneck is rather on PureVPNs side than on yours.
There are also audio-video-sync issues. At least when playing 24fps (23.976) content (standard Blu-Ray framerate) there is on my TV a sync offset of about 175ms (audio ahead of video). I assume that this varies from TV to TV, because this seems to be the processing time my TV needs for the pictures in 24fps mode. My Odroid C2 is connected to an AV-Receiver. This leads to my assumption that Odroid C2 does have a broken LipSync (so called feature) support in the last builds, where HDMI should correct this offset via a handshake or so.
This offset was also discussed on forum.odroid.com because others also noticed it since wrxtasys 7.1 community builds. His 7.0.2 builds were not affected apparently.
Then I used instead of "remote nl1-ovpn-udp.purevpn.net"-->"184.108.40.206", because this gave the best connection.
And then I suddenly got:Code
- LibreELEC (official) Version: 7.0.2
- LibreELEC:~ # curl ipinfo.io
- "ip": "83.82.xxx.xxx",
- "hostname": "535285E6.cm-6-3c.dynamic.ziggo.nl",
- "city": "Werkendam",
- "region": "Noord-Brabant",
- "country": "NL",
- "loc": "51.8098,4.8937",
- "org": "AS9143 Ziggo B.V.",
- "postal": "4250"
- }LibreELEC:~ # python speedtest.py
- Retrieving speedtest.net configuration...
- Testing from Ziggo (83.82.xxx.xxx)...
- Retrieving speedtest.net server list...
- Selecting best server based on ping...
- Hosted by Vodafone NL (Utrecht) [34.87 km]: 16.267 ms
- Testing download speed................................................................................
- Download: 90.36 Mbit/s
- Testing upload speed....................................................................................................
- Upload: 15.09 Mbit/s
- LibreELEC:~ #
Ziggo is actually my ISP and the "83.82.xxx.xxx" is my WAN Ip address?!?!
I performed the speed test on "220.127.116.11" 3x and 3x I got a different Ziggo Server with the same connetion speeds.
This confuses me...Can I use my own ISP to make a VPN Connection?
And if so is the internet traffic still anonymous?
Update: I saw that The VPN connection was not established with this IP address, OpenVPN was not started
Exactly... you didn't establish a VPN connection, because you tried to use your own external PureVPN IP as the server IP. That cannot work.
You were assigned the external IP 18.104.22.168 by PureVPN, when you connected to the server 22.214.171.124. Apparently this was the one of the 7 servers, which PureVPN assigned you, when you connected to nl1-ovpn-udp.purevpn.net. When you connect to one of PureVPNs servers, you are getting an external IP
matching the first three positions and the last one makes it your personal external IP. PureVPN doesn't share IP's between users, which is by the way extremely dangerous for your system and probably your entire home LAN, because PureVPN passes all connections (unwanted) into your direction directly to your LibreELEC machine.. bear that in mind, if you enabled SSH (hardcoded user "root" and pass "libreelec") and the webserver with its port 8080 (necessary for Yatse remote, for example).
I highly recommend to read my thread here regarding PureVPN (and other VPN providers): LibreELEC
So, you found out that server 126.96.36.199 was the only one with reasonable bandwidth. Perhaps it is just temporary, because the others were loaded for some temporary reason, but it could be worth a try to set this ip in your *.ovpn file instead of the nl1-ovpn-udp.purevpn.net address and just use this one server. And make a second *.ovpn with the default address nl1-ovpn-udp.purevpn.net to cycle to it, if 188.8.131.52 is overloaded. That is at least how I do it for a year now.
Here are my speedtests for those 7 servers: [Bash] PureVPN Netherlands Speedtest - Pastebin.com
Turns out that server 184.108.40.206 was the only one which cut my bandwidth down to max 1Mbit Down, less than 1Mbit up. All others had nearly full speed of my 50/10 (max 40/10 synced) internet connection.
And it turns out that the external PureVPN IP's are not always matching the corresponding server IP's (except for the fourth position). Netherlands servers are the first where I see totally different assigned external IP's than the actual servers IP you connect to. Anyways, perhaps this all helps. Perhaps there is one particular of those 7 servers, which you should avoid. I made the above linked speedtests at ~2am from germany, so there might be no load on servers during this time, hence it's not a good comparison for your measurements.
When I look at my openvpn.log I notice 3 things:
- Why is UDP port 53 used and not 1194 (manual openvpn tutorials)
- On the PureVPN server list on their site "nl1-ovpn-udp.pointtoserver.com" is mentioned for the Netherlands but from the VPN Manager is "nl1-ovpn-udp.purevpn.net" selected...Why?
- ERROR: Linux route add command failed: external program exited with error status: 2
do you get a dutch IP if you are connected? Could you do a reproducable speedtest while connected to the server? I could then try to reproduce your results and see if can confirm your bottleneck.
UDP is always 53 at PureVPN. They chose it, I don't see an issue with this.
As zomboided said already, there is no difference in using nl1-ovpn-udp.pointtoserver.com or nl1-ovpn-udp.purevpn.net.
Your dutch nl1-ovpn-udp.pointtoserver.com has the following servers behind it:220.127.116.11
You can take your *.ovpn configuration file and substitute the Server with one of these IP's
PureVPN connects you randomly to one of those 7 Servers, if you use the default "nl1-ovpn-udp.pointtoserver.com". Your problem might be, that you get connected to a slow or overloaded server randomly. Try to pic those servers one by one. If that is really the problem, then finding picking the right one will solve your bandwitch issue. (I do the same with switzerland... there are 4 Servers. Some of them are slow, so I prefer mostly 2 of them).
I'm using PureVPN as well and usually everything is fast. Perhaps your chosen server is the bottleneck?
I'm not sure whether this is something I should mention or if it is on the agenda anyway. I thought I'll mention it just in case nobody is aware of this issue.
In current alpha builds, if starting a 3D mkv (also MVC iso) kodi switches correctly into 3D mode, but it does not indicate the TV to do so. So you have to manually turn it on on your TV and choose the correct TAB or SBS mode via TV remote control (TV menu, not Kodi GUI).
This is working on raspberries perfectly (I think realized through framepacked).
And this is working as a workaround on wrxtasy's 7.0.x (7.1.x) community builds. Afaik he integrated a koying patch for making it possible.
See here how it works: ODROID Forum • View topic - LibreELEC 7.0.2 - Kodi Jarvis 16.1 - Archived - LE Tips HERE
In short: On wrxtasy's builds you had to set the 3D mode to "ask me" insted of "preferred mode" and as soon as Kodi asks upon starting a movie, you just confirm choosing the "preferred mode" and it would switch the TV automatically in the correct 3D mode (sounds a bit weird, but it is that way).
Funny thing though: Last week I tried wrxtasy's C2 build on a Sony Android TV (X8507c Series). And there it switched always correctly even without the workaround with "ask me". You could leave it on automatic "preferred mode" and it would switch just like it did on the Raspberry Pis. I guess Android TV is the reason that it works there perfectly, because wrxtasy integrated Koyings 3D patch, wich was meant to be for Android Kodi (SPMC).
Is there any aim to integrate 3D functionality in Odroid C2 Krypton builds in the future?
Your script should run in isolation...you should be able to type up.sh and it execute. If you can't then this is a large part of the problem you're having. For Pure, there does seem to be some issues I'll need to look at. script-security 2 should be added with the up option but I can look and see why it's not happening.
As for a risky solution....maybe if you were being port scanned at DoS levels of activity. This is the way that openvpn expects to be used from what I can tell though so I'm not going to worry about this.
You're right, I had forgotten the headline "#!/bin/sh", now the up.sh is like this:
And it does work indeed now. The rules are set after successful connection. But I took a look into OpenVPN.log and saw these to last lines (although VPN tunnel works):
Anyway...after ignoring it, I played around a bit:
- Disconnecting the VPN does not flush the rules. They stay if I do "iptables -nvL". So flushing would be the purpose of a down.sh? If yes, then down.sh should be made the way that it only deletes the rules, which were introduced by up.sh upon connection attempt.
- Then I reverted the chmod +x up.sh, to see if it would work without this command.
- Result (without chmod +x up.sh) is this error again:
So the script needs to be marked as executable. I'm no linux guy... is that possible to be done automatically without user interaction?
infinity85 , I've just upload version 2.2.4 which adds support for up/down scripts. I've only tested up scripts on Windows and it'll be a while before I get to test this on my LibreELEC boxes. If you want to create an 'up.sh' in your UserDefined directory, then reset the .ovpn files, then it should detect that you want to use an up script and update your user defined .ovpn files to include the right parameter to cause the script to run after the connection has been established. I think within this script you're wanting to put the iptable modifications you mentioned previously in this thread.
On Windows, the down script is not run. I think this is because of how I'm killing the task. On Linux, I use a more appropriate method of terminating the task which *may* allow the down script to run. As I said, I need to test on my LibreELEC box to know if this is the case.
There's a small amount of doc here Home · Zomboided/service.vpn.manager Wiki · GitHub but it pretty much covers what you know/I've just told you.
If this does work, then I might look to roll it out to all VPN providers, but to be honest I have no idea how many of them don't do some amount of firewalling/blocking for you. I might just be a handful that let everything in like you're seeing with Pure.
I've tested it (honestly not completely understood how to use it):
To have some kind of reproducibility I went the usual way and used your provided *.ovpn scripts, i.e. "PureVPN" instead of "User-Default".
- At first chose a PureVPN server without up.sh. Got this error message:
OpenVPN.log shows that in line 20 (ifconfig-nowarnscript-security) is an unrecognized option or missing parameter:
Line 20: "ifconfig-nowarnscript-security 2"
- I was able to connect to VPN after deleting this line.
- Okay, so I went over to try the new up.sh method. I created the up.sh with the mentioned rules
- Tried reconnecting again:
- Apparently it has to be done chmod +x, so I did: chmod +x /storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh
- This solved the error, but led to another one:
error in openVPN.log:
- so I added "script-security 2" to the ovpn file. Then this error showed up:
- I gave up after this
According to your wiki, the rules would be set 'after' establishing the connection. If that is true, then wouldn't that be a kind of risky solution?
- At first chose a PureVPN server without up.sh. Got this error message:
Ok, this was a good idea. I tried it with a pi running recalbox and it is the same. So moving to Sony
But thanks for helping
Good for LibreELEC, bad for you :/... Hopefully it's only a faulty Firmware and not an upcoming hardware problem -_-
Yes, my amp has this option too and it is set.
So perhaps better contact your manufacturer (sony) in the meantime. May be they will fix this via a firmware update. On my Onkyo 616 and Odroid C2 it works flawlessly.
Do you have another HDMI Device to test it with? Lets say a FireTV or a Chromecast or Bluray player? If this happens with the other devices as well, than LibreELEC team cannot change it, as the issue is on sonys side then
Who knows, may be the HDMI board on your Sony is going to break down soon or so and this is the first sign of it.