ggrab und udrec wollen beide nicht streamen

Beitrag von **soletan** » Samstag 29. November 2003, 14:19

Hallo,

ich versuche seit kurzem, mit ggrab oder udrec Daten aus meiner Sagem (1x) dBox2 zu streamen. Als Rechner kommt dabei ein AMD K6/2 350 MHz mit 128 MB RAM unter SuSE 8.2 zum Einsatz. Die NIC zur Box hat einen RTL-8129.

Vorab: die ganze Zeit über kann ich mich per Web, per Telnet, per FTP auf die Box einwählen. Aufnahme-Anfragen von der Box zum Server werden registriert und führen einfach nur zu fehlerhaftem Verhalten.
Auf dem Rechner ist keine iptables-Rule gesetzt, die Policies aller chains sind auf ACCEPT gesetzt. Das Routing arbeitet ebenfalls ordentlich, sonst gäbe es kein WWW/FTP/Telnet.

Auf der Box war bis vor kurzem das AlexW Image vom 22.7.2003 - seit vergangener Woche hatte ich das Release-Image vom 4.11.2003 genutzt, gestern kam nun das Snapshot vom 24.11.2003 drauf ...

Ich hatte bisher versucht sserver/ggrab aus dem ggrab-Paket zum Laufen zu bringen. Es funktioniert einmalig recht gut mit dem Release-Image vom 4.11.2003 ... ein zwei Tage später klappte da aber gar nichts mehr. Das Ergebnis ist seither die Meldung

xlist::sid: Timeout wait for data

Gestern habe ich das aktuelle Snapshot vom 24.11.2003 eingespielt und auf dem Server mit udrec angefangen. Zahlreiche Probleme konnte ich bereits beheben und sserver/udrec aus dem mkdvd-0.06c-Paket laufen an sich ordentlich. udrec wird gefunden und alles läuft soweit. Die Ausgaben im Log sind folgende:

Code: Alles auswählen

14:10.10 - to DBox: AUDIO 31341 16 0 1 va 8ff 900
14:10.10 - from DBox: INFO: IP c0a80301 Port 31341
14:10.10 - from DBox: PID va 2 8ff 900
14:10.10 - to DBox: START
14:10.10 - from DBox: INFO: UdpSender() - PID156 R0 W0
14:10.10 - from DBox: INFO: DmxReader() - Pid 8ff 204960 0 0
14:10.10 - from DBox: INFO: DmxReader() - Pid 900 29280 0 0
14:10.41 - UDP Timeout
14:10.41 - to DBox: STOP
14:10.42 - from DBox: EXIT
14:10.42 - Stopped: 1 1 1


ps aux | grep sserver

root     29654  0.0  0.2  1192  356 pts/2    S    14:09   0:00 /usr/sbin/sserver.udrec -udrec -o /srv/dbox/movies
root     29697  0.0  0.3  3776  500 pts/2    S    14:11   0:00 grep sserver

Die Dateien (.a0 und .v0) wurden bei udrec angelegt, blieben aber leer. Bei ggrab gab's gar keine Files. Ich würde allemal lieber udrec einsetzen.

Wer mag, kann TCP-Dumps erhalten, die ich aufgrund Ihrer Größe separat abgelegt habe.

ggrab: http://toxa.homeip.net/ggrab.dump.gz
udrec: http://toxa.homeip.net/udrec.dump.gz (~ 11MB)

Bei beiden erfolgen Timeouts.

Danke für jede Hilfe, die kommen mag.
Soletan

Beitrag von **tonsel** » Samstag 29. November 2003, 15:52

Hast Du Bild und Ton während des Aufnahmeversuchs?

tonsel

Beitrag von **soletan** » Samstag 29. November 2003, 16:17

Hallo,

ja - ich habe Ton und Bild ... das Playback wird bei Neutrino nicht angehalten, wohl aber der sectionsd ...

Beitrag von **tonsel** » Samstag 29. November 2003, 17:58

Ist dein PC bzw. die Nezwerkarte an der die DBox hängt auf die IP 192.168.3.1 eingestellt? Dort werden die Daten per Udp hingeschickt.

Hast Du überhaupt UDP-Traffic? - ich vermute JA bei 11MB Log-größe.

tonsel

Beitrag von **soletan** » Samstag 29. November 2003, 18:33

Hallo tonsel.

Da die Dienste telnet, FTP und WWW durchgehen, ebenso wie die Requests der dbox zum Start oder Stopp einer Aufnahme vom sserver auf dem Rechner geloggt werden, kann es nicht an solch grundlegenden Problemen der Netzwerk-Konfiguration liegen - möchte man zumindest meinen. ;-)

Dennoch: eine Ausgabe von ifconfig und route.

Code: Alles auswählen

eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:192.168.3.1  Bcast:192.168.3.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:95591 errors:1248 dropped:0 overruns:24 frame:0
          TX packets:53475 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:117932369 (112.4 Mb)  TX bytes:59982387 (57.2 Mb)
          Interrupt:11 Base address:0x9000 

eth1      Link encap:Ethernet  HWaddr 00:E0:7D:D2:01:14  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:7dff:fed2:114/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4201344 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5447895 errors:0 dropped:0 overruns:3 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:671068086 (639.9 Mb)  TX bytes:464328629 (442.8 Mb)
          Interrupt:9 Base address:0xb000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:42842 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42842 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:10482763 (9.9 Mb)  TX bytes:10482763 (9.9 Mb)

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
default         192.168.1.2 0.0.0.0         UG    0      0        0 eth1

eth0 ist mit der Box verbunden. Ein Startup per SuSE-Skripts mit aktivierter Debug-Ausgabe zeigte keine unerwarteten Ausgaben.

Auf deine Frage nach dem UDP habe ich nun doch einmal versucht, die Dumps selbst ein wenig zu lesen und stellte fest, dass das erste UDP-Paket an den vom Rechner der dbox mitgeteilten Port auf icmp-Ebene abgewiesen wurde mit der Meldung:

192.168.3.1 udp port 31341 unreachable [tos 0xc0]

Dies gilt auch für die folgenden UDP-Pakete. Welches ist der TypeOfService 0xC0?? Eventuell sitzt da einfach noch ein Paketfilter jenseits von iptables drin??? Wie gesagt, dieses ist frei - keine zusätzlichen Tabellen, keine Regeln, nur Policies, die alles durch lassen.

Nun, da ich nicht direkt weiterkomme, hier weitere Ausgaben:

iptables -L

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

ip route

Code: Alles auswählen

192.168.3.0/24 dev eth0  proto kernel  scope link  src 192.168.3.1 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.1 
default via 192.168.1.2 dev eth1

ipfwadm und ipchains sind im Userspace nicht verfügbar und meines Wissens in den Standard-SuSE-Kernel 2.4.20-4GB nicht einkompiliert. Vielleicht werde ich den auch mal durch einen eigenen 2.4.22 ersetzen.

Soweit.
Sofern es möglich ist, mir dabei zu helfen, wie es zu diesem ICMP-Level-Fehler kommt und wodurch ich entsprechende Einstellungen anpassen kann, wäre ich über jede Meldung dankbar.

(Aufgrund von unschönen Fehlern in der Bouquet-Verwaltung ist übrigens nun wieder das letzte Release (4.11.2003) von alexW aufgespielt.)

Soletan

Beitrag von **tonsel** » Samstag 29. November 2003, 19:46

Starte udrec mal mit der Option "-ip 192.168.3.1"

Kannst Du von der DBox aus die 192.168.3.1 anpingen?

tonsel

Beitrag von **soletan** » Samstag 29. November 2003, 22:18

Hallo tonsel,

ich habe die Option -ip ... hinzugefügt und nun empfängt er ordentlich Daten. Und so langsam schwant mir auch aus Sicht der UDP-Technik und der Socket-Erzeugung innerhalb udrec, warum das vorher nicht ging. Es hält nur leider nicht für eine Erklärung der Probleme mit ggrab her, da dort ja laut README nur auf Wunsch UDP genutzt wird. Dieses wäre insofern interessanter, als dass es gemuxte Daten liefern kann ...

Danke in jedem Fall für die sokratische Art des Problemlösens ;-)

Soletan