Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

Markus, George and potential GNU/Linuxers

Concerning the first post I can add my experience of installing TelliCast on Debian 10 amd64 (Buster).
My receivers are headless command line systems managed via ssh. Keyboard and monitor is only used
during the base install. I downloaded and burnt on CD the latest 343MB debian-10.3-amd64-netinst.iso.
All the following refers to a fully 64bit receiver system including TC client and latest EKU software.

The base install on an old Fujitsu/Siemens P7935 (Intel Core2 Duo 3.33GHz, 8GB RAM) takes 1/2 hour.

1) Device driver
   TBS-6903 device drivers are the reason I had to change back to Debian with systemd. The latest
   GIT media driver tree from TBS does not compile anymore on Devuan ASCII 2.0 or 2.1 which still
   has kernel 4.9. It's a pity Devuan does not seem to have the manpower to follow other distros.
   I'am still convinced that a systemd free GNU/Linux OS is more suited for a TC receiver only PC.
   But it's probably true: UNIX is dead and Linux goes the way of a modern desktop/mobile OS where
   you constantly plug in or connect to all kinds of things that have to be handled automatically.

2) EKU software
   I had no problem to get my eToken Pro v4.2.5.4 EKU working. I did *not* add any udev eToken rule.
   I faced the problems I reported before: I had to install gtk2.0.0 as the SavenetAuthenticationClient
   has been developped and linked to graphic stuff not found on my Debian 10 CLI only receiver system.
   I had to add the missing link: ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/libcrypto.so

3) Diseqc switching
   Something I do not use. But I use my own version of szap-s2 compiled from CrazyCat sources.

4) smcroute
   This is where systemd begins to interfere. The EUMETSAT distributed SysV init scripts originate
   from the old days of DVB-S and do not fit well in a systemd handled GNU/Linux. I also had to:

   systemctl disable smcroute
   systemctl disable smcroute-helper

   There is more: systemd comes with its own ntp client service. This is normally disabled when
   you install a full featured ntpd. But when you sync your clock with TelliCast (as EUMETSAT
   proposes) you better check that your RTC is not pushed back and forth beween TC and systemd.

   I use my own versions of dvb-eumetcast and tellicast-client scripts outside of /etc/init.d

   The EUMETSAT distributed script dvb-eumetcast still relies on old ifconfig which is not there
   unless you apt-get install net-tools. Even then it failed to configure my dummy0, dummy1, dummy2
   multicast interfaces. This is new to me: In older Linux kernels with module dummy loaded you
   could just type "ifconfig dummy0 192.168.1.1 multicast" and you had your new dummy0 configured.
   in Debian 10 with kernel 4.19.0-8-amd64 I had to create my 3 dummies first with utility ip:

   ip link add dummy0 type dummy  
   ip link add dummy1 type dummy
   ip link add dummy2 type dummy

   Then I could configure them with ifconfig. I will rewrite my dvb-eumetcast script to
   only use ip instead of ancient ifconfig and probably drop EUMETSAT a note about that.

   There is more problems with smcroute. This used to be one executable in /usr/sbin.
   The version 2.4.2-4 distributed with Debian 10 is now called with smcrouted and
   smcroutectl (sounds like systemctl :-) and smcroute is actually a "compatibility
   wrapper for users with old startup scripts" in /usr/sbin. It's obvious that this
   can go wrong with the EUMETSAT distributed dvb-eumetcast script. As a new feature
   the daemon flushes "unused dynamic" multicast routes after a default delay of 60s.
   This feature deserves more study. It drops routes for channels that have not been
   active recently. When TelliCast announces data in such a channel it usually fails
   with: "WRN: ... Failed to open data channel ... address ... No data received from
   sender". Starting the daemon smcrouted with "smcroute -d -c 0" did the trick !

5) SUCCESS
   It took me 5 hours too. Next install will be with CloneZilla in 10 minutes.

6) Tune as usual
   I have very little missed packets as usual. As posted several times before I
   recommend to disable C-States in BIOS and to pin busiest interrupts to cores.

Bottom line: Yes, installing a GNU/Linux TC receiver is not for the faint of heart.
But if you are willing to google, read posts and man pages it can easily be done.
A couple of people on this list have done it before in different ways and are willing
to help. Please keep in mind that EUMETSAT pushed routers from the very beginning
of DVB-S2 transmission and that they do not have the manpower to keep up with
all that's going on around PCIe DVB-S2 cards and the many GNU/Linux distros.


Best regards,
Ernst

Join MSG-1@groups.io to automatically receive all group messages.