Posts by infinity85

    I'm not sure why you don't simply follow the guide for making your own lircd.conf...

    I've tried it with my harmony... Your given profile does not work for me either. But following the above linked guide, I made a custom lircd.conf (see attachment: lircd_harmony-hauppauge-pvr350.zip)

    The thing is that some buttons give the same codes:

    • INFO and MENU button have the same code 0x17CD


    • and the buttons SUBTITLE/CLOSED CAPTION/ # have the same code 0x17CE


    This is likely because I used a harmony to simulate yours. Perhaps you don't even have some of the mentioned buttons on the Hauppauge remote. But as I said: Simply follow the guide to create your own lircd.conf and it will work this time with the hauppage remote. Seems to be a pretty appropriate one for LibreELEC :)

    hi @hru,

    I've now programmed my Harmony 950 to use your Pioneer BDP-180 profile and unfortunately I can confirm your issue.

    Apparently only the cursors and cannel buttons result in discrete lirc codes:

    Quote

    KEY_UP 0x21DE
    KEY_DOWN 0xA15E
    KEY_RIGHT 0x619E
    KEY_LEFT 0xE11E
    KEY_CHANNELUP 0x21DE
    KEY_CHANNELDOWN 0xA15E

    all the other buttons are recognized as 0x817E ir code. Thats really strange, never saw this behaviour on one of my remotes hm :/... I'm afraid you will have to use another remote hmm...

    But anyways, why not use HDMI CEC, i.e. use your TV's remote to control the C2?

    My test lircd.conf with your remote profile:


    Hello,

    thank you for the information.

    I have some problems generating my own lirc.conf with irrecord.
    For nearly all the buttons of the remote irrecord recognizes the same code.
    Thats very strange.

    Best regards

    Hartmut


    hmmm strange.... :/... could you name the exact model of the pioneer bluray player? So I could program my Harmony Remote to imitate your pioneer remote and try it myself. Untunately I cannot promise to do it this weekend, I rather think that I could test it during next week.

    Have you tried it with another remote instead of the pioneers one?

    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.

    @gschmidt
    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)?


    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 : 138.99.211.2 and 188.72.98.130 and 188.72.98.2 and 213.5.64.38 and 213.5.64.37 and 138.99.211.130 and 185.2.31.191 and 213.5.71.71 and 213.5.69.4 and 213.5.68.20 and 185.2.29.191

    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?

    Update:
    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 (206.123.147.2), 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 206.123.147.2 for your connection and then you end up with a slow connection. This was just an example. It is likely that my slow 206.123.147.2 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.
    [hr]


    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"-->"206.123.147.102", because this gave the best connection.
    And then I suddenly got:

    Ziggo is actually my ISP and the "83.82.xxx.xxx" is my WAN Ip address?!?!
    I performed the speed test on "206.123.147.102" 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.

    Explanation:
    You were assigned the external IP 206.123.147.102 by PureVPN, when you connected to the server 206.123.147.2. 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 206.123.147.2 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 206.123.147.2 is overloaded. That is at least how I do it for a year now.

    EDIT:
    Here are my speedtests for those 7 servers: [Bash] PureVPN Netherlands Speedtest - Pastebin.com

    Turns out that server 206.123.147.2 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:213.5.69.62
    206.123.147.2
    188.72.98.130
    138.99.211.130
    213.5.64.38
    79.142.68.125
    213.5.64.37
    185.2.29.191

    You can take your *.ovpn configuration file and substitute the Server with one of these IP's

    example:

    from this

    Code
    remote nl1-ovpn-udp.pointtoserver.com 53

    to that:

    Code
    remote 213.5.69.62 53

    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).

    Hi,
    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:

    Bash
    #!/bin/sh
    iptables -F
    iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -i tun0 -j DROP

    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):

    Code
    ERROR: Linux router add command failed: external program exited with error status: 2
    Initialization Sequence completed

    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:
      Code
      Options Error: --up script fails with '/storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh': Permission denied


    So the script needs to be marked as executable. I'm no linux guy... is that possible to be done automatically without user interaction?