UPS PIco HV3.0A Stack Plus on LibreELEC

Details

Published: 09 March 2017

I am currently trying to make the UPS PIco HV3.0A Stack Plus from πmodules fly on LibreELEC 8 running on a RASPBERRY PI 3 MODEL B. I'll update this post as I make progress.

First of all, all stuff is in place in regards to the drivers needed for the RTC part (as I got many request regarding those drivers. They are in place, you do not have to do anything).
You can check the existence on your system with "cat /lib/modules/$(uname -r)/modules.builtin" for drives build statically into the Kernel and "ls ls /lib/modules/$(uname -r)/kernel/drivers/rtc" for the drivers compiled as module.

• rtc-ds1307 is available as module
• i2c-dev is compiled into the Kernel
• i2c-bcm2708 is compiled into the Kernel

On the software side two Python packages are missing: XMLTODICT and JINJA2.

• To enable picofssd to talk to the PIco, you need to install the addon "rpi-tools" which provides RPi.GPIO
• To read the config file for picofssd we need xmltodict.
• To send emails we need to download & compile "jinja2"
  This is on my TODO-List - didn't set up a LibreELEC dev system yet
  We can easily work around this flaw by deactivate the eMail feature.
  --> Comment out the instantiation of the sendEmail class, its invocation and self.alert_email() in the python script "picofssd" (e.g. in PiModules/code/python/upspico/picofssd/scripts or edit it in the new location after installation e.g. /storage/upspico/usr/bin)

Read more: UPS PIco HV3.0A Stack Plus on LibreELEC

Download JAVA JRE JDK via the commandline

Details

Published: 02 July 2016

Sick of firing up a web browser, downloading JRE or JDK to your desktop and scp it to the server you are updating?

I was:

wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u92-b14/jdk-8u92-linux-x64.tar.gz

If you are using Gentoo, you can use this script.

Rainbow Six - Siege (port forwarding for open NAT type)

Details

Published: 22 December 2015

As UBI gave a ridiculous long but incomplete list of ports which have to be forwarded to make R6-Siege report the NAT type to be open, I decided to figure out on my own what I really need to make R6-Siege report an open NAT type as UPNP and a never ending list of ports which have to be forwarded is not an option for me.

So let me first quote the ports provided from UBI:

Uplay
TCP: 80, 443, 13000, 13005, 13200, 14000, 14001, 14008

Rainbow Six: Siege
UDP 10000-10099, 3074, 6015
TCP 80, 443

Source: CONNECTIVITY ISSUES IN RAINBOW 6 SIEGE

Once I configured that list, the NAT type reported was still "moderate". So I looked at "Process Monitor" (Sysinternals) and Wireshark on which ports R6-Siege is hogging. After launching it a couple of times while my desktop was configured as "exposed host" (all ports directly forwarded to it) it looked like R6-Siege is picking a random UDP port from 50000 onward.

This range 50000-60000 was missing in the list of UBI. After adding this R6-Siege always (until now) reported an open NAT type.

After further trying to narrow the required ports down, I ended up with a single UDP port and a range of UDP-Ports which have to be forwarded:

TCP: 6015
UDP: 6015, 50000-60000 (if this fails for you, try UDP 49152-65535)

If I should figure out this is wrong for whatever reason, I will update it here.

Update 28.12.2015:
I made a mistake while writing this. It requires only the above UDP ports. I attached a screenshot of my Fritz!Box port forwarding settings.

Update 02.01.2016:
Some players had to extend the port range to 65000 *sigh* and it might depend to which data center you are connecting.

Update 16.06.2016:
Nyr suggested, that Ubi is using the entire range from port 49152 to 65535. This range is delegated for private use or custom services and not officially assigned by IANA.
So if the above mentioned port range fails on you, try forwarding the entire UDP range from port 49152 to 65535.

Update 30.07.2016:
Looks like 6015 was unnecessary (It was the local port. The remote port was UDP 9103)