Posts by infinity85

    Hi, try the following command:

    1. cp /etc/lirc/lircd.conf.rpi .config/lircd.conf

    The file lircd.conf is not present under default conditions in .config directory. So you'll copy the MCE Remote Mapping with this command and override the default lirc.conf in /etc/lirc (probably default uses original Odroid Remote mapping). Then reboot the system.

    If it does not help, then simply delete the created lircd.conf in .config directory (ssh) respectively Configfiles directory (SMB) and you'll be back where you started. And post here for further assistance :)

    Okay, I've been digging a bit in a systemd manual... and I'd be glad if you could give your 2cents about pro's and con's to this :/.

    Here's my preliminary solution:

    • Create a file (iptables.rules) containing the rules in: /storage/.config/iptables.rules

      1. # perform "systemctl restart iptables.service" after editing rules
      2. # tun+ will filter all tunnels. Change to tun0, tun1, tunX if wanted otherwise
      3. iptables -F
      4. iptables -A INPUT -i tun+ -m state --state ESTABLISHED,RELATED -j ACCEPT
      5. iptables -A INPUT -i tun+ -j DROP

      Remark to iptables -F:
      This line iptables -F is necessary, otherwise the rules will be aggregated upon manual restart of service

    • Create the systemd service (iptables.service) in: /storage/.config/system.d/iptables.service

    • Enable this systemd service with following command systemctl enable iptables.service
      (This command will create a symlink in /storage/.config/system.d/

    • Now start the service with: systemctl start iptables.service

    • Check if rules were set sucessfully with: iptables -nvL
      Output should look like this:


    Preceding thoughts:

    At first I used the service with Type=forking:

    I chose "forking" because I could define Restart=on-failure, as I thought it is good for a security related service like this to be restarted upon failure.
    I'm not sure if that does make sense. Perhaps I'm wrong here and this parameter does not have any effect practically. That is because I'm not sure whether forking is some kind of daemon, which is running the whole time in background and notices whenever it gets killed, to be restarted with "Restart=on-failure" in that case. If that is the case, then I don't understand why "ExecStop" in combination with "forking" does not activate the rules. May be I'm missing some other paramter? Or is forking just invoking the rules once and then closes automatically, that would mean that Restart=on-failure is just working for the boot, but not if the service has a failure somewhen later during watching content or so.

    Then I made this first Type=oneshot approach:

    • The advantage of this was that you could also stop the service on demand with systemctl stop iptables.service and it would then flush the rules thanks to ExecStop=/usr/sbin/iptables -F
    • The downside was that you could not use Restart=on-failure in combination with oneshot and,...(see next point)
    • If I understand it correctly, oneshot with RemainAfterExit=yes would keep up the service the entire time consuming ressources, wouldn't it? And if it crashes, the service wouldn't restart automatically because of missing Restart=on-failure. So in worst case the rules would vanish until next reboot and you wouldn't notice that your network is exposed again. Unfortunately Restart=on-failure does not work with oneshot.

    Finally I sticked to the short "oneshot" version without the ExecStop and RemainAfterExit=yes options to not having the service running the whole time. If I make systemctl stop iptables.service the service would ignore this I think, but the iptables rules will remain active until you invoke iptables -F

    Sorry that this post is so long again -_-. However I'd really appreciate if somebody could say which one of the three services would be the best. Or how oneshot or forking handles the situation if something kills the service.

    Buy an emmc module, it's much faster then SD card or usb stick.

    It surely is, if reading wrxtasys reports and from some other users, but on the other hand a fast UHS-I MicroSD Card with 32GB like a Samsung EVO+ is round about 10€ and they are pretty fast as well. Apart from boot times most won't notice the difference I guess. Even the 16GB eMMC is about 45€+Shipping usually. That does not suit for everybody :)

    And as far as I understood OP, he is not concerned about speed, it is more like he wants to have the library on a seperate datastorage for perhaps switching the boot-disk without having to backup and restore everytime. But may be I'm wrong about the motivation.

    There is no guide I'm aware of, you will need coding experience:

    First you'll need to modify the OpenSSH (or whatever ssh daemon you use) source code to log the passwords on failed attempts, then you'll have the log data in "/var/log/auth.log". Some ssh daemons might log the passwords in high debug log levels, but this will likely explode the size of your log file, so editing the source to log the passwords in the normal log level is always advised.

    From there it's up to you on how you handle it. I've created a file parser in PHP, that is called by cron and writes the failed attempts into a mysql database. From there I can easily manage the data and display statistics and search for specific entries in a custom PHP based web interface. You don't have to use PHP for this, but I personally prefer it when working with mysql and simple file operations.

    Okay, that sounds more like an overkill for me. The effort wouldn't be worth for this. I hoped that there might be just some package or a script ;). Fail2ban etc. will have to do it's job and I'll rely on that :)

    Thanks anyway for your description regarding this, Grimson :)

    Probably best done with a check-box in the provider setup dialog and then an ip-up script in the generated OpenVPN config file. I don't use any VPN addons myself so that's just a suggestion, there are a number of ways it could be done.

    I don't see why an addon would throw away your, that would make a lot of people angry. It should be fine to use that. You can use tun+ instead of tun0 if you happen to have more than one VPN at a time as well. Yes, systemd is another way of running scripts during start.

    Very, very useful tips! especially the tun+ hint is awesome, thanks!

    You're right. I thought I would leave the -F rule in case that somebody has already manipulated the rules somewhere in the system, so -F would flush them and set my own rules to override the hidden ones. On the other hand this -F rule could be also deleted by an attacker haha.

    I think having this included in the VPN addon itself would be the neatest solution. How would that be done the best? I mean... I do it by introducing an and adding these lines to it. But actually my contains also other lines which could get lost, if some addon starts to mess around with existing
    Do you have a suggestion fo a more safe solution without editing an, is there some other already present routine in LibreELEC for such things? (I'm no programmer unfortunately, but I see directories like: /storage/.config/system.d/ with *.samples which imply that there are more ways to achieve something during boot/after start without Would that also count for iptables?

    I'd like to provide these tips respectively this thread to the VPN Manager Addon developer, so perhaps he will be willing to think about implementing it.

    Well, I'm owning/running a dedicated server in a data center and among other things I log failed ssh access credentials. The root/openelec combination shows up quite regularly. The root/libreelec combination has appeared a few times in the last 2 months, so there is at least one tool out there that has it in it's database as a combination to try.

    Well this thread here is a perfect example for the concerns I posted in feature request subforum some days ago: VPN: Include default iptables rule for tun0 or at least optional
    I'd be somehow more satisfied if there would be some open and serious discussion about this. From my point of view this hijacking of IoT and VPN devices is a pretty up-to-date topic on systems like LibreELEC.

    It's quite interesting to read that you logged the user/pass variations. Is it hard to achieve? I'm running a Banana Pi Seafile server and would also like to have this kind of logs after reading your post. Is there a guide/tutorial you could recommend (for linux noobs who can follow guides)?

    Hi guys really new, I mean really new. Just purchased the odroid c2 and they did not have any remotes instock, Can someone please point me to a link on how i can setup an infrared remote? I haven figured out how you guys edit the files or make changes yet. So is there a tutorial or dummys guide i would appreciate it. Setting up the software is no problem. I am just unclear how to make changes?

    I havent seemed to find any info if it is even possible but I want to try and setup the Xbox One Media Remote is that even possible? I cant find much at all?

    If you follow this guide from wrxtasy: Mini Guide to setting up any IR remote on the C1/C2
    you'll be able to use basically any IR Remote that you can find at home to be used for LibreELEC. Just follow the steps, restart and then most of the buttons will be assigned.

    If this is not enough then, so lets say you want it customized further, you can use the addon "Keymap editor" from kodi repository.

    And if that is not suiting you somehow, then you can do this manually by editing/using the following files in combination:

    • /storage/.kodi/userdata/Lircmap.xml
    • /storage/.kodi/userdata/keymaps/remote.xml

    There are loads of threads about this at and So you'll find everything you need written somewhere. But I remember how irritating it was when I tried it myself for the first time (especially the two *.xml for custom mapping). So if you need further help, just ask here :)

    Well, maybe next time in the future, when I will not have too much data on it. So it will not take very long to copy them back :-)
    I dont have another HDD for test.

    Aah what a shame, too late again :dodgy: :D

    Anyways, the Krypton builds should improve it significantly (big_writes seems included in master)

    I agree completely to your post :)
    And thanks for adding the explanation for the mentioned iptables rules.

    Further example: Using these rulest the tunnel will only allow transfers to you, if you request them. So if you turn on ITPV, this is a requested URL and the stream will be started without any delay. If you search and download subtitles, this will also work as before through the tunnel.
    But if somebody got your tunnels IP, lets say a bad guy at the IPTV provider that is streaming to you, then his attempt to connect to your machine will be blocked, because you did not open personally an additional connection besides the stream itself.

    @lrusak or Team LibreELEC
    Don't you think it would be reasonable to include an on/off switch for iptables (with at least these 3 rules) to the first boot installation wizard? Currently there is only a switch for SMB and SSH.

    I'm a bit persistent here because this entire "issue" is not really prominently placed or mentioned anywhere. Also here in this forum, nobody will pay attention to it or notice that it is extremely dangerous to use a VPN for geo-unblocking, whenever somebody is going to set up OpenVPN on LibreELEC for the first time, because LibreELEC simply does not have any firewall rules set in default config. This is in some kind of contrast to LibreELECs philosophy where you choose LibreELEC because it is so easy to set up and simply running perfectly and lightweight. If you would be an advanced user who knows everything about linux, then you would take a distro like Ubuntu or whatever and you would know, that you need to set iptables, because you would use the machine for many different tasks and those persons would probably know a bit more about security or so.

    The underlying file system appears to have no bearing on the allocation roundup size - an RPi2 with 4096 byte ext4 block size still results in Windows 7 reporting 1024 bytes "Size on disk" for a 1 byte file.

    Yep, that confirms my impression that there was actually a bug in Windows 7 (ignores parameter allocation roundup size), which is solved since Windows 8 :)

    Thanks a lot for solving my issue here!

    will need support added in our linux-amlogic kernel and support in the device tree before you can use it.

    What exactly are you referring to? I simply think that my config is wrong somehow. Why should something be added to device tree? I doubt the display was ever integrated into device tree on 7.0.2 builds (where it worked just fine). Is the kernel different between Krypton and Jarvis LibreELEC?
    Perhaps I misunderstand your reply?

    Trying to find out if Power on feature for odroid c2 was or is active with an Ir remote? I have read alot of posts but it was unclear if this was ever worked out. It sort of sucks to have to plug it in to turn it on? I havent got a remote yet so i can test it out. Thank you for your help!

    It depends what Remote you use for it. You will be able to power on/off it with an original Odroid Remote and with Logitech harmony (Odroid C1 profile)
    This will work for recent community builds from wrxtasy (LibreELEC 7.1 wrxtasy builds from and with official Krypton Alpha builds, which you can find at

    Here's all the testing and info regarding your question:
    ODROID Forum • View topic - IR Remote: Suspend/Resume
    ODROID Forum • View topic - Turning C2 on with IR/CEC Remote
    And ODROID Forum • View topic - Please Laugh at Me! LIRC Harmony Remote Shutdown Related

    This thread here is the perfect opportunity to confirm whether and how much ntfs big_writes mount parameter improves transfer speeds. As escalade stated, it is because of the ntfs driver and its fuse implementation.

    See here the discussion and further links: Network: smb & ntfs config mods #807

    I suggested and tested some months ago the big_writes parameter for ntfs mounts, which is said to achieve a big leap in transfer speeds while writing. Unfortunately I could only test it to a SBC (odroid C2) which is naturally limited. But you could test it now with your more powerful x86 based machine with GBLan, like escalades suggested back then.

    If I'm not wrong: The current v7.90.008 ALPHA should contain the "big_writes" parameter for ntfs mounting. So if you could repeat your NTFS test from the beginning with this current Alpha build (just for testing), then I'm quite sure you'll achieve at least 60MB/s instead of the 30MB/s that you had before.
    Of course it's kind of inconvenient to reformat an HDD. But perhaps you have another laying around for testing. Anyways, it would be great if you could try this to have a confirmation about the acutal effect of big_writes on more powerful systems (compared to SBCs like Raspberries and Odroids).


    What would the command to enable /dev/i2c-2 be (i have no hw to test, need some hints for debugging)?

    A1. Config folder is now in /storage/.kodi/userdata/addon_data/service.lcdd, accessible via ssh and smb

    A2. Settings should be in settings folder

    good question hmm... I just know that I had to modify in LCDd.conf the line Device=/dev/i2c-1 to Device=/dev/i2c-2

    # Device of the serial interface [default: /dev/lcd]

    It is visible on my LibreELEC 7.0.x setups on RPi and C2:

    And it is not present when using LibreELEC Krypton 008 alpha build. But I am not sure what is responsible that the file appears in the directory /dev/i2c-x :/.

    Regarding A2: So no settings in GUI like in old builds? You mean the settings.xml or are you referring to the lcd.xml where you set what infolabels should be displayed?

    Hi there,

    first of all I want to provide the solution to this Issue in form of a feature request:

    Please add those VPN tun0 rules as default into your iptables (for the non-considered regular user like me and others):

    1. iptables -F
    2. iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
    3. iptables -A INPUT -i tun0 -j DROP

    These rules will filter only the tun0 interface in case an OpenVPN connection is established to a VPN provider (remote Server, which is not in your control) for overcoming geo-blocking or for IP anonymization etc. So only requested data will get to you (IPTV and scraping media coverarts will all work with that). All local connections (lcdproc, yatse, webserver, samba) will remain untouched by this.

    Now here's the long shot of the story as explanation why this is a concern of massive consequences:

    As nowadays many LibreELEC users consume not only local content, but also streaming content, they might use one of a lot of VPN Providers on the market to overcome geo-blocking or simply to mask their own IP Address to be anonymous during media scraping like Coverarts etc.

    Because of the demand to use VPN connections on LibreELEC, LibreELEC team reincluded OpenVPN and the user zomboided developed a mighty and very awesome addon VPN Manager for OpenVPN as well as lrusak provided his own one before. So the demand got heard :)

    The Problem with LibreELEC is that it was not meant to be used outside of the own LAN, thus no iptables rules are set as default and there is also no GUI for that or any addon that could provide you this. But fortunately iptables is integrated, so anybody can add his own rules, if he knows that they are mandatory on his setup. So this issue potentially exposes your entire local area network to the internet.

    BUT here's the massive security issue with some VPN Providers in combination with LibreELECs default setup:
    I can speak for my VPN Provider "PureVPN": PureVPN and probably many other VPN services assign an external IP to my/your LibreELEC device whenever you connect to one of their servers. The shocking point here is:
    Knowing this IP, everybody is able to access your LibreELEC system and bypassing the routers firewall as well as all its closed ports. This is an unbelievably massive security issue, because all ports are open (including SSH 22)!

    Obviously this is exactly how a VPN connection is working and why it was invented originally: People wanted an encrypted connection from workplaces or from vacation to their Network at home. So far so good, but the use case of overcoming geo-blocking or using VPNs to anonymize your own IP is differnt here: You are paying for a tunnel, of which you have only control on your own side (LAN), but not of the other side (VPN Providers remote Servers). That means that a mean employee at your VPN Provider sees the IP assigned to you upon establishing the connection and gets access to your LibreELEC machine, and in an extreme situation to your whole LAN, although you have set up a quite secure Router-Firewall and NAT (everything gets bypassed).

    I was naive and didn't ever consider that a big VPN-Provider like PureVPN (and some others are doing the same) assign not shared IPs upon established VPN connection, but real 1:1 for every single VPN tunnel. I thought that it would be like NAT: Every unrequested connection coming from outside will be simply rejected. But that's not the case. PureVPN and some other providers simply route every single connection from outside to your client. So whenever you are surfing or streaming or so through their tunnel, every content provider or website logs your PureVPN IP, which points directly to your machine bypassing your router. They can simply type in this IP into a browser and access your Webserver at Port 8080, or access through SSH.
    Comparison: If using a private VPN connection for connecting the home network to the working place network (vice versa), then you know the other side and have probably control of the server at the other end, also there might be a software firewall which does its part to security (Windows firewall doesn't help you, if established an OpenVPN tunnel). But here you don't know what is on the other side and you certainly don't want to be accessed without asking while you simply use netflix USA from Europe or so.

    And this is the frightening result of it:

    • Establish a OpenVPN connection with PureVPN
    • determine your external VPN IP: curl --> Lets say you get this IP:
    • Everybody can SSH into your system now, just knowing your IP: with root/libreelec (provided you have SSH activated with password)
    • Everybody can access your webserver at, if you don't have set a password for it (default: not set). Even with password, it won't be hard for an attacker to breach it, I think.
    • You can be pinged with ping
    • This way everybody could also access your Samba shares and simply everything that is connected to your local network. Even if the routers firewall secures everything, the VPN tunnels from some of those VPN services, are really dangerous for not so well informed people like me and many others. Anybody on the other side simply needs to guess or to read the IP and then they can get directly into your network no matter what router security configuration you have.
    • As this is a VPN tunnel IP, it passes through my WAN router and bypasses also all the closed ports of it

    The worst thing in case of LibreELEC is that the SSH user/pass are hardcoded: root/libereelec, so anybody who has SSH activated and did not deactivate the password, is accessable due to this shit of some VPN providers from all over the world with root/libreelec.

    The thing is that I was concerned about security before using VPNs for this purpose. And whenever you search for "VPN+security", it tells you that it is kind of safe. Even if I search now for keywords with the current knowledge, it is nowhere mentioned, that those services don't close all ports in your direction by default. So a normal user like I am, would simply assume that only connections established by me will cause inbound traffic. Just like it is if you are using a Windows computer with a browser: The Firewall or routers NAT will block everything that I did not request by typing it in into the URL bar.
    And anyways... I can't even think of any use case where somebody would like to have opened ports in his direction from remote servers, where he is not sitting (if the other side is not his own LAN).

    So.. What I want to say is: VPN Providers like PureVPN, IPVanish, PIA are nowadays (especially on MediaCenters like LibreELEC) not to be seen as a regular VPN tunnel, which is commonly known for secure connections between workplaces and your homenetwork. After discovering this issue, I had the explanation why I had suddenly about 15000 infected files (by an ancient trojan) on my external harddrive some months ago, which is always connected to my Odroid C2, and no other system at home had this infection.

    Using another VPN Provider named PIA is also kind of strange: Mostly you land on a foreign computer (noticed because ssh user/pass didn't work). So it is also similar to PureVPN, except the IP is kind of random to many computers (real NAT would reject those access attempts).

    Quick workaround for those who encounter the same or who can successful access their webserver via External-VPN-IP:8080 :

    • create an in: storage/.config/
    • with this content:
      1. #!/bin/sh
      2. iptables -F
      3. iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
      4. iptables -A INPUT -i tun0 -j DROP

    • make it executable: chmod +x storage/.config/
    • Reboot the system and check whether the new rules are set in SSH: iptables -L
    • Then try again to ping your computer or accress ssh via port 22. It should time out.

    Sorry for the long post :/. But I already brang this topic up in the german kodinerds forum and many users tried to explain me that this is what VPN is for... but they didn't want to understand that this geo-unblocking usecase is a different matter in terms of VPN usage. And then some other users tested it and found out that they have the same issue with their VPN Providers and didn't notice that their network was exposed the whole time because of this.

    After seeing this thread, I was curious whether my OLED 20x4 would run on LibreELEC (Krypton) v7.90.008 ALPHA for Odroid C2.

    Well.. it doesn't... it starts already with the missing i2c-2 address :D :

    1. HD44780: I2C: open i2c device '/dev/i2c-2' failed: No such file or directory

    On wrxtasys 7.0.x / 7.1 builds it works for i2c-2 and i2c-1. Unfortunately it is wired for i2c-2 right now, so I cannot check i2c-1 easily.

    Besides the question why i2c-2 is not present?, I still have two more questions:

    • I have to use a custom compiled HD44780 because my controller (SSD1311 is not fully compatible to HD44780). On my Raspberry Pi's and on my Odroid C2 with 7.0.x builds I simply had to put the modified driver and config files (, LCDd.conf) into .config directory and LCD.xml into userdata directory. The display worked then right away after enabling HD44780 displaydriver in LibreELEC Configuration / Services. LCDd.conf contained the path to my custom "/storage/.config/"
      Where do I have to put those files now. LCD.conf in .config seems to be ignored?
    • There are no settings left in lcdproc (no dimming, no scroll speed, no alternative character choice). Is it coming back, or did you dig those configuration options somewhere else?

    Sweet! The wireshark info is nice to see. Didn't know that wireshark also lists this info, thanks for this hint!

    Well yeah, then it's indeed solved. I'd say allocation = 0 is a good setting as future default.

    Already marked it as solved ;)

    Regarding the passwords issue with special characters like ! and * that I mentioned in my Post #15: If somebody has a clue, feel free to share it :)