Posts by infinity85

Quote from zomboided

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

  Error connecting to VPN, unrecognised option.
  Disable block-outside-dns in debug menu, reset ovpn files and retry.
  Or check log and review ovpn file in use.

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

  Options Error: --up script fails with '/storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh': Permission denied

• 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:
  
  
  Code

  Warning: External program may not be called unless '--script-security 2' or higher is enabled
  Warning: Failed running command (--up/--down): external program fork failed
  exiting due to fatal error

• so I added "script-security 2" to the ovpn file. Then this error showed up:
  
  
  Code

  /storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh tun0 1500 1558 136.0.5.201 255.255.255.224 init
  Warning: Failed running command (--up/--down): external program fork failed
  exiting due to fatal error

• 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?

Quote from Brolantor

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 -_-

Quote from Brolantor

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.

Sorry @escalade that I did not go your way at first. I couldn't find an easy way to realize it (no experience at all for this), but instead I had the templates for systemd services in LibreELECs .config folder. Your solution sounds kind of perfect in terms of flexibility, when reading it now after you explained it a bit further

@zomboided
Do you think that it would also be possible to take user defined into account? I'm using PureVPN, but I'm using custom *.ovpn files for it with your User Defined option, because this way I can specify also direct connections to the Servers IP-addresses behind their DNS names.

Like
DNS: usny1-ovpn-udp.pointtoserver.com
Corresponding IP-Adresses after resolution: 23.236.155.35 and 172.245.48.125 and 172.94.41.130 etc.

Doing this method, because sometimes the servers are overloaded and slow and then I can cherry pick them by choosing different *.ovpn's to find a server that is kind of less used at the moment.

Quote from zomboided

Thanks for the email Mr Infinity. Let's have the conversation here so I better understand. I don't have my LibreELEC boxes handy right now.

Regardless of the approach that's used, I think the requirement is to update the iptable before establishing a VPN with the following two commands?

Code

iptables -A INPUT -i tun+ -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i tun+ -j DROP

If a VPN is disconnected, what effect do these commands have? I think they'll be redundant, correct? And therefore there's no need to remove them.

If they are redundant why is there a requirement to switch it on and off? I think any integration with VPN Manager (which seems like a good idea, with it turned on by default), would be just to ensure these commands are sent, with an option to not do this for users that want to create their own special rules and go down a path of a systemd task that does magical things at boot?

Exactly. I can only speak for myself at first: My intention to have a "turn off" option was to ensure that users, who use your addon with their own VPN server (no PureVPN or IPVanish or similar), have the option to have control over this setting (or at least they would take notice that VPN Manager for OpenVPN is setting up iptables rules). If it wasn't an option in the addons GUI, then nobody would know why his private VPN (from lets say his vacation location to his home-router) isn't working as expected, although this person did not set up any firewall rules to be responsible for this. They'd probably wrap LibreELEC inside out to find the reason

From developers point of view lrusak, you and awiouy do certainly have a better overview and basis to discuss pro's and con's for this

Quote from CA_cabotage

Honestly neither will bother me, 30Hz certainly won't, almost 100% of my content plays back at 24Hz, I honestly don't know what people are wanting to watch at 60Hz on an HTPC?

You have now all your content at 24Hz because all Blurays (movies) are in 24Hz. But this will change, especially with 4K content in the near future. I am mentioning it also with taking into account that you mentioned 10 years of usage.

Quote from CA_cabotage

I didn't know about the eight bit output though, good point and thanks for bringing that up! And if it does bother me in a few years, I'll pick up the latest version for another $60. This obviously isn't state of the art at $60 for Mobo and CPU, but as far as your average HTPC goes I still think that 30Hz, 8 bit 4k has a ton of bang for the buck and will last most users for many years, maybe not ten for me though ;).
[hr]

Well, it's possible that 1080p content will play with 10Bit on a HDMI 1.4 Device. But 4K@10Bit will be a problem because of the limited HDMI 1.4 bandwidth. But you're right, the decision to simply buy a current device at a reasonable price that is good enough for the current needs is absolutely sane. You never know what is coming around the corner next (e.g. HDR standards or perhaps a new 3D standard for 4k content) then an update wouldn't hurt that much.
On the other hand I guess that your current/old htpc would do it's job with 24Hz as well for some more time if it was enough for the last years. I'm sure that I will wait for a mature software support of those new apollo lake devices. I'm really interested in those, as they seem to become a shooting star

Hmm... I'm wondering about your J3355B-ITX choice for 10Bit and 4K for the next 10 years. The J3355B-ITX can perhaps decode 10Bit, but it won't ever output it as 10bit (8 bit I guess), because of its HDMI 1.4 port. Also the 30Hz limit will be something that will bother you perhaps for 9 of the 10 years, that you are planning to use it :/.

The ASRock J3455-ITX has a DisplayPort to HDMI converter chip, which gives it HDMI 2.0 capability including 60Hz and HDCP 2.2. So it should be fully HDMI2.0 compatible, including perhaps 10 Bit output (not just decode). But regarding 10 Bit output I wouldn't be so sure, as it is nowhere mentioned when I fly about the data sheets.

Has anybody read about output of 60Hz and 10Bit on Apollo Lake yet? This J3455-ITX sounds pretty interesting, I'm considering to buy it.

Quote from freem@n

this means unless someone finds this closed source compiled library for other architectures we will never get Spotify connect for x64 HTPCs running the Generic LibreELEC build, right?

aarch64 is not generic x64. It is aarch64 the "new" 64 architecture of ARM CPU cores. The RPi3 and Odroid C2 and Wetek Hubs are all aarch64. In case or RPi3 the main distributions like Raspbian still don't use 64 bit instructions, but stick to the RPi2 compatible 32bit libraries, that is why it is working for Raspberries.
I don't know anything about x64 (x86-64) Intel/AMD situation, though.

Oh I was pretty surprised reading that. But after further testing I see that /Altair and /media/Altair is handled the same way, apparently :). I'm glad it works now for you!

Regarding the very slow transfer: Try deleting the values SO_RCVBUF=65536 SO_SNDBUF=65536
This doubles (or even more) the samba transfer speed on my Odroid C2 (before 13MB/s, after up to 40MB/s). Not sure which effect it can have on RPi3. Of course the wifi connection can be the limit already, so removing those buffers won't have any positive effect.

Perhaps I'm totally off the track, but isn't the actual problem that Colokid does not point to the mountpoint of the drive? How could samba know where to find the disk by only giving

[Altair]
  path = /Altair

what would be if you try?:

[Altair]
path = /media

This should list all mounted drives. If you see then the name of the drive, then you can add it to specify the mount point one level deeper:

[Altair]
path = /media/**HDDName**

So I guess it's:
path = /media/altair
or
path = /media/Altair
(case sensitive!)

aaaah... okay. That's a pity, but thanks anyway. Fortunately my other devices support spotify connect too

Yes that would be some kind of workaround. I remember doing something similar to my tv.

What you could do though is: You leave the raspberry set in Harmony software as "leave always on" and then you simply specify a delayed power on action for "when you enter this activity" and a power off action for "when you leave this activity" like at this timestamp of my video:

EDIT

Quote from raini

So the next action that is not part of your video is to remove the initial startup-acton and insert it after the delay. Is this what you mean? As I cannot remove the initial startup-action I probably must remove the Raspberry from this activity first. I will try this tonight.

Yes perhaps that would be even better :). You can play with it, unless somebody gives a better advice

Quote from awiouy

No, WeTek Hub is aarch64, see the first post

What do you need to get it working on aarch64? Do you need someone to compile it on an aarch64 device? I've got an odroid C2 in case that could help for a small test.

absolutely no need for asking for permission! There is no intellectual property in what I did haha, as I just tested and adapted escalades and lrusaks tips. Sure, I'd be glad if you did this

Do you mind if I send this thread to zomboided, who made the vpn manager addon so that he could integrate your work (or work with you) into his addon? In the long run it would be great anyway, if there is a standalone addon and one part which is integrated into a vpn addon, so that only the vpn related rules are present where they belong: In a VPN addon, right there, where you set up a vpn connection.

And on the other hand there could be a dedicated iptables addon (like you intend to make one), which can be developed for further options and more customizable or so

So may I send it to him also? He'll remember that we had a discussion about this potential issue some months ago via email.

EDIT
Ah and does anybody happen to know whether:

[Install]
WantedBy=multi-user.target

or

[Install]
WantedBy=kodi.target

is the better solution? I think if multi-user.target works, that that would be a better solution in terms of security/reliability, right? But is it consistent with LibreELECs approach of singleuser / root / readonly philosopy? Is there any conflict or so like "multi-user.target" is invoked later or prior or too early, to late etc.?

Quote from raini

Thanks infinity85!
Do you mean what's described on this page: Fixing Power-on Delays? If yes, this does NOT delay the start but creates a pause in order to make sure that the device had enough time to receive additional commands. If not, where do you set this? On the remote or in the configuration-tool?

Have you watched my uploaded video?
It is not that what you described, it is really about a command (in your case power-on) to be sent delayed by an amount of time. Just watch the youtube video I made and linked for you in my last post.

Quote from Gary

Thanks both for the prompt info, I've tried the ip link but its coming up with a cant connect error, i suppose this may be the router, its ISP provided and I've not delved into the security settings. by chance, sorry being lazy now as i should look it up, If I'm using a 32gig sd card will I get it all or is there a limit on SD size?

My 32GB cards are fully expanded, I doubt there is a limit. The connection error might be either because you chose not the IP of your LibreELEC device or rather because you might have not activated samba/smb during initial LibreELEC setup? You do need to type in the double backslashes followed by the correct IP directly into your windows explorers (windows file manager) path bar (not the Internet Explorer). Or try otherwise \\libreelec . Perhaps that works for you as well

Adding something to trogggy's explanation:
It will expand itself upon first boot. That is why the first boot takes longer and involves an automatic reboot.

Quote from lrusak

Why not just do it like other distributions have it?

svntogit/packages.git - Git clone of the 'packages' repository

Thanks for pointing to it lrusak!

Well... a rather more embarrassing reason why I didn't do it like they do! I didn't know how other distros do it and somehow I didn't manage to find this template. Apparently I was using the wrong keywords

I tried iptables-restore once, but it gave me errors... and now I understood that my iptables.rules synax must be adapted for suiting the iptables-restore command. The wrong syntax was the reason it did not work before, and I thought it was because LibreELEC is a bit differently (I thought the error messages arise because of the read-only-filesystem).

Now I adapted the script to suit the template from your arch link:
iptables.service:

[Unit]
Description=Packet Filtering Framework
Before=network-pre.target
Wants=network-pre.target


[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables-restore /storage/.config/iptables.rules
ExecReload=/usr/sbin/iptables-restore /storage/.config/iptables.rules
ExecStop=/usr/sbin/iptables -F
RemainAfterExit=yes


[Install]
WantedBy=kodi.target

And I solved the errors by modifying the iptables.rules files syntax:

# perform "systemctl restart iptables.service" after editing rules
*filter
-A INPUT -i tun+ -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i tun+ -j DROP
COMMIT

And finally the following commands work correctly now:

• systemctl start iptables.service : starts the service (but does it at boot anyway, once it was enabled with systemctl enable iptables.service)
• systemctl stop iptables.service : stops the service and flushes the rules=turns off filtering (reverting to LibreELEC default settings)
• systemctl reload iptables.service : reloads/restarts the rules after one might have modified them or added new ones
• systemctl restart iptables.service : apparently does the same as "reload" above

Do you think this is a good solution? Also performance wise? oneshot should not eat any ressources, right? It is just once invoking the command and then closes again without having a process/service running in background as far as I understood.