Erste Sat>IP-Geräte vorgestellt: Hardware- und Erfahrungs-Sammel-Thread

@ ichamthe1st
schöne Sammlung von HW

ich habe hier auch noch einen --> http://www.telestar.de/indexbe…l?nav=Sat_to_IP,de,76-331

hier ein weiteres Gerät von GSS für obige Sammlung

hier was von Zinwell --> http://www.zintech.com.tw/modules/product/page.php?tbdsn=165

Die Geräte von Inverto, Telestar und GSS scheinen mir baugleich zu sein.
Interessant ist was da bei GSS bei den technischen Daten steht:

Quote

Betriebssystem: Linux

Dann muss es auch irgendwo den Quellcode dazu geben, das lädt zu Spekulationen ein .

Bislang konnte ich leider nichts zu den verwendeten Komponenten heraus finden.
Das wäre schon interessant um abzuschätzen, ob es sich lohnt damit zu experimentieren.

Ist jemandem schon so ein Ding in der freien Wildbahn begegnet?
Bei einem ausgepackten Gerät könnte man vielleicht was vom Innenleben erkennen.
Bislang hab ich nur einen Digibit R1 im Karton gesehen, das war nicht wirklich aufschlussreich.

Quote from SHF

Die Geräte von Inverto, Telestar und GSS scheinen mir baugleich zu sein.
Interessant ist was da bei GSS bei den technischen Daten steht:

Dann muss es auch irgendwo den Quellcode dazu geben, das lädt zu Spekulationen ein .

Laut englischem Wikipedia ist auch die IDL400S 'Linux-based'. Unter Clients suppported steht auch der VLC-Player drin. Kann mans denn dann für den VDR schon umsetzen?

Direkt kann man es noch nicht nutzen, da fehlt noch ein entsprechendes Plugin oder ein Treiber der das als DVB-Karte verfügbar macht.
Da die Spezifikation offen und nicht besonders kompliziert ist, dürfte es aber nur eine Frage der Zeit sein bis da was kommt.
Ob das dann den Ansprüchen für den VDR-Betrieb (Umschaltzeiten, Stabilität usw.) genügt ist dann die nächste Frage.

Ich bin derzeit aber eher am überlegen, den VDR als Server direkt auf dem Teil zu installieren.
Wenn man das Datenblatt von dem Zinswell ansieht, sieht das garnicht so schlecht aus. Zwar ein Bisschen wenig Flash, aber 512Mb RAM, damit könnte man was machen.
Die Frage ist halt, ob die Tuner auch Intern verfügbar sind, sonst sieht es schecht aus.

Frage:

Wäre es mit SAT>IP prinzipiell möglich, das Signal via Internet an z.B ein Ferienhaus mit Internetanschluss weiterzuleiten?

Da mein Vermieter an der Ferienadresse keine Sat-Antennen duldet, wäre dies doch die Optimale lösung, wenn's dann funktionieren würde?!?!?

wohl kaum - außer du hast eine dicke Internetleitung (Upload)

VDR mit Streamdev und externremux kann dir aber helfen...

Wenn es die bauliche Lage erlaubt, dann ist denn Stuhl auf dem Balkon sicher erlaubt http://www.reichelt.de/?ARTICLE=111920;PROVID=2028;&utm_source=Preisvergleich&utm_medium=CPC&utm_campaign=Preisvergleich_google_feed

cu

Also im Triax TSS 400 SAT>IP Server ist ein STI7108-Prozessor verbaut. So wie es aussieht, kommt das Board von "zintech". Auf dem Board ist die Bezeichnung "ZIM-1800" zu finden.

Mal sehen, ob man einen SeriellPort oder sonst irgendwas findet

Wer braucht schon einen Seriell-Port wenn das Ding auf Port 99 ein Telnet mit Root-Zugriff bietet
Ich habe mich mal ein wenig umgesehen...

Ein wenig necrobumping, aber das hier hab ich sonst noch nirgends direkt gefunden. Ausserdem war grad der Artikel in der c't, weshalb einige moeglicherweise wieder sensibilisiert wurden.

Der Triax TSS400 ist offenbar bauglich zum ZIM-1800. So einen hab ich neulich fuer die neue Haus-Sat-Anlage bestell (den Triax, nicht den ZIM).

Der Grundig GSS 400 und das Inverto-Geraet scheinen ebenfalls baugleich, benutzen aber nicht unbedingt die gleiche Software. Zumindest haben die Firmware-Updates ein anderes Format (bei diesen Geraeten: id4k.bin, was offenbar ein uImage mit Kernel und dazugelinktem initramfs ist).

Bei Triax gibt es inzwischen ein Softwareupdate hier: http://www.triax-gmbh.de/?alPage=&rkPage=&articleId={DD19082B-15C5-4586-B5A6-A76D2FB267CB}

In den img-Dateien ist am Anfang ein 64 byte grosser "ZinImage"-Header.

Wenn man den abschneidet, faengt im satip_sw.img dahinter in Kernel-uImage an und im satip_data.img ein UBI-Image.

Unter der Annahme, dass das rootfs ebenfalls als UBI-Image vorliegt, kann man mit

grep -P -a -b UBI# --only-matching satip_sw.img

den Anfang herausfinden, bei mir Offset 2022152.

Das kann man dann extrahieren:

dd if=satip_sw.img of=sw.ubi bs=1 skip=2022152

und unter Zuhilfename des nand-Simulators mounten:

modprobe nandsim first_id_byte=0x20 second_id_byte=0xa2 third_id_byte=0x00 fourth_id_byte=0x15
modprobe ubi
ubiformat /dev/mtd0 -f sw.ubi
ubiattach -m 0 /dev/ubi_ctrl
mkdir ubi
mount -t ubifs ubi0 /mnt/ubi

Das gleiche kann man mit dem data-Image machen, hier benutzt man als Startoffset fuer dd dann skip=64 um den ZinImage-Header wegzuschneiden.

Das rootfs ist recht rudimentaer. Hier gibt es eigentlich nur busybox und die beiden proprietaeren binaries "CliConsole" und "zim1800" sowie die Kernel-Module aus dem STAPI-SDK.

Bemerkenswert ist, dass im Update die root-shell auf port 99 entfallen ist, die Zeile ist in satip.sh auskommentiert.

Im zim1800-Binary findet sich u.a. folgender String:

STAPI_SDK-REL_36.0

Siehe hier: http://www.stlinux.com/stworkb…ction/STAPISDK_linux.html

Es gibt wohl auch eine serielle Konsole "ttyAS1". Im Update laeuft hier das satip.sh.

Linux und Busybox bedeutet im Umkehrschluss, dass der Hersteller auf Anfrage auch Sourcecode rausgeben muss. Hat da schonmal jemand nachgefragt?

Quote from Mreimer

Linux und Busybox bedeutet im Umkehrschluss, dass der Hersteller auf Anfrage auch Sourcecode rausgeben muss. Hat da schonmal jemand nachgefragt?

Naja, das ST-SDK kriegt man wohl so, und die ganzen spannenden Sachen (source vom zim1800 usw...) fallen nicht zwangslaeufig unter die GPL.

Interessant waer z.B. 'nen headless-vdr direkt auf dem Ding laufen zu lassen.

Die Frage ist, wie man eigenen Krams da dauerhaft installieren kann. Das rootfs auf ubi muesste man recht einfach r/w mounten koennen. Dummerweise ist die root-backdoor beim Update wohl deaktiviert. Evtl. gibt es noch eine zusaetzliche, wenn man einen USB-Stick mit einer Triggerdatei (enable-telnet-console) anschliesst, passiert da irgendwas.

Im zim1800 binary ist auch eine Sektion, die irgendwie wie eine Hilfe zu einem Command Line Interface aussieht, da gibt es u.a. auch ein Kommando SHELL.

Andere Ideen, das Backdoor beim Update ohne das dranfrickeln einer seriellen Konsole zu erhalten waeren:

- nicht updaten. Die Auslieferungsversion kann aber evtl. kein DLNA
- Nach obiger Beschreibung das Update extrahieren und die Dateien einzeln austauschen (fuer die busybox vermutlich garnicht noetig, aber fuer das zim1800-binary)
- Binaerpatch fuer das Update und den '#' vor dem Start des telnet-Servers durch ein Space ersetzen. Dabei koennte aber evtl. eine Pruefsumme im ZinImage-Header oder im UBI-Image kaputtgehen. Ein neues UBI-Image zu erstellen waere moeglich, die Tools sind alle offen.

Wenn meine Hardware da ist, werd ich aber erstmal gucken, wie man an den Bootloader kommt (wird wohl u-boot sein) und wie der Update-Mechanismus funktioniert (ein ubi-image kann ja nicht das laufende rootfs ueberschreiben).

Quote from wuselfuzz

Ein wenig necrobumping, aber das hier hab ich sonst noch nirgends direkt gefunden. Ausserdem war grad der Artikel in der c't, weshalb einige moeglicherweise wieder sensibilisiert wurden.

Hi,
es gibt sehr wohl einen Thread, der sich mit Sat>IP beschäftigt: Offene Runde SAT>IP
Ich habe den Artikel auch die Tage gelesen und bin ehrlich gesagt ziemlich angetan von dem Prinzip. Was jetzt eigentlich fehlt ist ein Plugin, mit dem man den Empfänger von einem VDR transparent nutzen kann und zwar inklusive verschiedener Audio IDs, EPG, Teletext usw. Auf der Kiste selber einen VDR laufen zu lassen finde ich nicht so zielführend, da dann wieder nur ein bestimmtes Gerät unterstützt wird und die VDR-VDR Kopplung über Streamdev jetzt auch nicht die tollste Lösung ist. Dann doch lieber so eine Kiste (oder zwei oder drei?!?) auf den Dachboden neben den Multiswitch und einen nativen Client auf eine Raspberry Pi o.ä. am Fernseher. Zum Aufnehmen dann noch einen headless VDR auf die NAS, so dass die Daten auch gleich an der richtigen Stelle landen.

Gruß Darkstar.

Quote from Mreimer

Linux und Busybox bedeutet im Umkehrschluss, dass der Hersteller auf Anfrage auch Sourcecode rausgeben muss. Hat da schonmal jemand nachgefragt?

Meines Wissens muss er nur den Teil des Sourcecodes herausgeben, der unter GNU o.ä. steht. Wenn er das System erweitert mit eigenem Code, dann darf er diesen unter Verschluss halten.

Das ist auch der falsche Ansatz.
Die Daten sind ja schon im Netwerk abrufbar. Nur die EPG-Infos fehlen.

Könnte nicht mal jemand den Stream in dem das EPG vermutet wird mitsniffen und irgendwo hochladen?

Quote from heinzelrumpel

Meines Wissens muss er nur den Teil des Sourcecodes herausgeben, der unter GNU o.ä. steht. Wenn er das System erweitert mit eigenem Code, dann darf er diesen unter Verschluss halten.

Stimmt teilweise. Vielleicht verstehe ich dich aber auch nur falsch. Wenn ein Programm, welches unter GPL steht, nämlich erweitert, bzw. verändert wird, dann muss der komplette Sourcecode inklusive Veränderungen wieder veröffentlicht werden.

Quote from Mreimer

Stimmt teilweise. Vielleicht verstehe ich dich aber auch nur falsch. Wenn ein Programm, welches unter GPL steht, nämlich erweitert, bzw. verändert wird, dann muss der komplette Sourcecode inklusive Veränderungen wieder veröffentlicht werden.

Wie ich oben schon schrieb, die interessanten Teile (sprich: das zim1800 binary, was das ganze DVB-Zeug abhandelt, und CliConsole) fallen mit hoher Wahrscheinlichkeit nicht unter die GPL, und den Rest kann man sich vermutlich sehr einfach mit einer der gaengigen Embedded-Linux-Distributionen nachbauen.

Nicht-GPL Kernelmodule, die nur binaer vorliegen "tainten" den Kernel zwar, fallen aber selbst ebenfalls nicht unter die GPL. Man erweitert dabei ja nicht den Kernel, sondern interagiert nur mit dem Kernel (auch wenn das hinzufuegen eines Moduls eine Erweiterung darstellt).

tl;dr: Ja, hier liegt vermutlich eine GPL-Violation vor. Nein, es wuerd beim Basteln mit dieser Box nicht grossartig helfen, wenn die Hersteller die Quellen rausruecken wuerde, die er rausruecken muss.