Autor Thema: [workaround] Option '--scan-network' funktioniert leider nicht  (Gelesen 7646 mal)

sparkie

  • Jr. Member
  • **
  • Beiträge: 65
    • Profil anzeigen
[workaround] Option '--scan-network' funktioniert leider nicht
« am: Juli 21, 2012, 03:08:42 Nachmittag »
Hallo Sundtek Support,

ich wollte mal meine Sundtek-Server Verwaltung  etwas optimieren. Dazu braeuchte ich die Option '--scan-network'. Diese scheint aber nicht zu funktionieren. Egal wo ich die ausfuehre (Client oder Server) sie liefert immer:
/opt/bin/mediaclient --scan-network
-  0 IPTV server found -------------------------------------------------------

Tatsaechlich sind aber 4 Sticks im Serverbetrieb und lassen sich auch problemlos von den Clients ueber's Netz mounten.
Alle Rechner befinden sich ausserdem im selben Netzwerk (aka LAN-Switch). Natuerlich keine Firewalls.

Ein (un)mount der Sticks funktioniert immer ohne Probleme und auch sonst geht alles.

Vielleicht mache ich nur was falsch?

Version auf allen beteiligten Kisten ist die aktuelle 'sundtek_installer_120720.2210.sh'

Fuer einen Tipp waer' ich dankbar

- sparkie


« Letzte Änderung: Juli 23, 2012, 08:28:01 Nachmittag von sparkie »

Sundtek

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 8512
    • Profil anzeigen
Re:Option '--scan-network' funktioniert leider nicht
« Antwort #1 am: Juli 21, 2012, 09:30:27 Nachmittag »
Klappt hier aber recht gut bei uns, zudem hat sich hier schon länger nichts mehr verändert im Netzwerkscan-Bereich.

Zitat

root@bm750:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1D:EC:01:52:11 
          inet addr:192.168.2.193  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14947 errors:314 dropped:314 overruns:0 frame:293
          TX packets:3732 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2605796 (2.4 MiB)  TX bytes:612481 (598.1 KiB)
          Interrupt:16

root@bm750:~# /opt/bin/mediaclient --scan-network
Scanning network for IPTV media servers
------------------------------------------------------------------------------
 IP address       | ID  |  devicename          | Users | Capabilities | Serial
------------------------------------------------------------------------------
 192.168.2.198    | 0   | Sundtek MediaTV Pro (USB 2.0)  |  0   | DVB-T, DVB-C | U120714xxxxxx
-  1 IPTV server found -------------------------------------------------------

Der Scan verwendet Multicast 224.1.2.65 Port 35245 sowie als Fallback Broadcast des Netzwerks mit Port 26362. Eventuell ist die Broadcast Adresse bei dir falsch gesetzt?

Als Tipp, schau dir mit tcpdump einfach an wohin die Daten gesendet bzw. ob sie empfangen werden.
« Letzte Änderung: Juli 21, 2012, 09:58:58 Nachmittag von Sundtek »
Failure is a good thing! I'll fix it

sparkie

  • Jr. Member
  • **
  • Beiträge: 65
    • Profil anzeigen
Re:Option '--scan-network' funktioniert leider nicht
« Antwort #2 am: Juli 21, 2012, 10:00:35 Nachmittag »
danke, nein Broadcast ist korrekt gesetzt. Leider hat der '--scan-network' bei mir noch nie richtig funktioniert.

Die Zeile 'Scanning network for IPTV media servers' erscheint bei mir uebrigens gar nicht:
/opt/bin/mediaclient --scan-network
-  0 IPTV server found -------------------------------------------------------

installiert habe ich mit 'sundtek_installer_120505.0521.sh -service -nolirc'. Kann das evtl ein Problem sein?

Manchmal geht es wenn ich auf dem Server ausfuehre:
/opt/bin/mediaclient --shutdown;sleep 3;/opt/bin/mediaclient --start
mit der aktuellen Version habe ich es damit aber auch nicht wieder hinbekommen.

- sparkie
« Letzte Änderung: Juli 21, 2012, 10:04:03 Nachmittag von sparkie »

Sundtek

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 8512
    • Profil anzeigen
Re:Option '--scan-network' funktioniert leider nicht
« Antwort #3 am: Juli 21, 2012, 10:08:21 Nachmittag »
Die einzige Möglichkeit ist das bei dir mit tcpdump zu überprüfen wohin die Daten geschickt werden.
Moeglich waere das der Server bei dir eventuell gestartet wird bevor das Netzwerk verfügbar ist, das könntest du aber lösen in dem du den Server einfach neu startest. Sollte dies das Problem sein kannst du einfach die udev Skripte anpassen und das Start Delay dort erhöhen.

Anstelle von sleep 3; /opt/bin/mediaclient --start kannst du auch /opt/bin/mediaclient --start=3 ausführen.

Der Scan funktioniert einwandfrei, irgendwo wird bei dir wohl gefiltert.

Ist dein Server ein PC oder ein Embedded System? 32 Bit oder 64bit?

Hier wurde es getestet mit Linux/Mac und einer MIPS Settopbox, sowie auf dem WLAN Router.

Wichtig -- überall die gleiche Treiberversion verwenden, oder zumindestens eine ab Juli.
« Letzte Änderung: Juli 21, 2012, 10:12:39 Nachmittag von Sundtek »
Failure is a good thing! I'll fix it

sparkie

  • Jr. Member
  • **
  • Beiträge: 65
    • Profil anzeigen
Re:Option '--scan-network' funktioniert leider nicht
« Antwort #4 am: Juli 21, 2012, 10:16:50 Nachmittag »
ok danke fuer die Antwort (am Samstag abend :) ), ich werde mir das morgen mal genauer mit tcpdump ansehen. Ich poste das Ergebnis dann hier.

- sparkie

sparkie

  • Jr. Member
  • **
  • Beiträge: 65
    • Profil anzeigen
Re:Option '--scan-network' funktioniert leider nicht
« Antwort #5 am: Juli 22, 2012, 02:59:13 Nachmittag »
Die einzige Möglichkeit ist das bei dir mit tcpdump zu überprüfen wohin die Daten geschickt werden.

ok, das habe ich gemacht. Ergebnisse siehe unten.

Zitat
Moeglich waere das der Server bei dir eventuell gestartet wird bevor das Netzwerk verfügbar ist, das könntest du aber lösen in dem du den Server einfach neu startest. Sollte dies das Problem sein kannst du einfach die udev Skripte anpassen und das Start Delay dort erhöhen.

es sieht tatsachlich so aus, als wenn das Problem mit einem zu fruehen Start des mediasrv zu tun haette. Mittlerweile gelingt es mir ohne weiteres nach einem manuellen shutdown/start des mediasrv auf dem Server den Scan wieder funktionsfaehig zu machen.

Zitat
Anstelle von sleep 3; /opt/bin/mediaclient --start kannst du auch /opt/bin/mediaclient --start=3 ausführen.

diesbezueglich habe ich aber das Problem, dass der 'mediasrv' trotz '--start=50' augenblicklich gestartet wird (siehe 'ps -ef'). Jetzt koennte man annehmen dass das vielleicht ok ist, weil sich das Delay in Wirklichkeit nur auf Netzwerk-Aktionen bezieht.

Aber selbst dann wenn ich in '/lib/udev/rules.d/80-mediasrv-eeti.rules' und '/etc/udev/rules.d/80-mediasrv-eeti.rules'
eintrage:

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ACTION=="add",    RUN+="/opt/bin/mediaclient --start=50"

aendert das am Fehlerverhalten nichts (d.h. der scan funktioniert trotzdem nicht). Mein System braucht aus power-off uebrigens ca 30s bis zum Shell-Prompt ueber's Netz. Da sollten also 50s Start-Delay dicke ausreichen.

Erst wenn ich wie oben beschrieben

/opt/bin/mediaclient --shutdown

und dann

/opt/bin/mediaclient --start

eingebe nach dem das System schon laengst oben ist, funktioniert ploetzlich alles wie gewuenscht. D.h alle Sticks am Server werden auf den Clients gemeldet.

Zitat
Der Scan funktioniert einwandfrei, irgendwo wird bei dir wohl gefiltert.

also gefiltert wird sicher nicht, wie die nachfolgenden tcpdumps zeigen.

Zitat
Ist dein Server ein PC oder ein Embedded System? 32 Bit oder 64bit?

es ist ein ganz normales Intel 64bit System auf einem DN2800MT. OS ist eine debian 6.0 minimal-Installation. Ich habe das System praktisch im Originalzustand + eure aktuellsten Treiber.

Zitat
Wichtig -- überall die gleiche Treiberversion verwenden, oder zumindestens eine ab Juli.  

ich habe überall (Server+Client) die Version sundtek_installer_120720.2210.sh

Jetzt zu den tcpdumps. Ich habe 4 Files:

BAD_server.txt  - Schlechtfall/ tcpdump vom Stick-Server
BAD_client.txt  - Schlechtfall/ tcpdump vom Client
GOOD_server.txt - Gutfall/ tcpdump vom Stick-Server
GOOD_client.txt - Gutfall/ tcpdump vom Client

Der Schlechtfall ist sofort reproduzierbar  wenn ich keinen manuell shutdown/start mache. Selbst '--start=50' (siehe oben) bringt nichts.  Der Gutfall ist nach manuellem shutdown/start sofort reproduzierbar.
ServerIP: 192.168.146.210
ClientIP: 192.168.146.187

Wenn man die Server und Client Dumps vergleicht sieht man es wird nichts gefiltert. Alles ist auf Server und Client sichtbar.

Es werden anscheinend immer Multicasts und dann Broadcasts gemacht. Und zwar im Gut wie im Schlechtfall. Im Schlechtfall wird jedoch
 mehrfach wiederholt.

ABER: im Schlechtfall werden vom Server nur die Broadcasts beantwortet. Die Multicasts bleiben ohne Antwort an den Client.

Was ich jetzt nicht verstehe: selbst im Schlechtfall liegen dem Client die Antworten (ueber Broadcast) also vor aber werden anscheinend ignoriert. Eine Anzeige ergibt ergibt zumindest schlichtweg:

-  0 IPTV server found -------------------------------------------------------

So wie es aussieht funktionieren nur die Multicasts. Aber die werden wiederum nur moeglich nach dem manuellen Workaround mit shutdown/start. Alles eine verzwickte Geschichte  :D

Die einzige automatisierte Moeglichkeit im Moment fuer mich ist im '/etc/rc.local' meinen Workaround einzubauen.

Eine andere Idee habe ich nach den ganzen Tests erst mal nicht.

Vielleicht gibt es doch noch eine geschicktere Variante?

Einer der folgenden Fixes sollte dazu bereits ausreichen:

1. Broadcasts zum funktionieren bringen. Dann muesste man sich um die unbeantworteten Multicasts (wegen zu fruehem mediasrv-start) nicht mehr zu kuemmern.
2. die -start=XX Option zum Laufen bringen. Dann muessten  die Multicasts nach bisherigem Wissen eigentlich wieder funktionieren und man muesste die Broadcasts nicht mehr fixen.

Danke schon mal im voraus. Ich kann gerne noch was testen...

- sparkie

[UPDATE]
attachments gehen hier im Forum anscheinend nicht. Mit aktuellem firefox. Ich bekomme immer

 Cannot access attachments upload path!

obwohl die Attachments ganz normal ueber Browse gefunden und eingebunden werden. Access Perms stimmen natuerlich auch.

wie ich die 4 kleinen tcp-Dumps (insges. nur ca. 60kB an Daten) uebermitteln soll - keine Ahnung

[/UPDATE]
« Letzte Änderung: Juli 22, 2012, 03:18:48 Nachmittag von sparkie »

Sundtek

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 8512
    • Profil anzeigen
Re:Option '--scan-network' funktioniert leider nicht
« Antwort #6 am: Juli 22, 2012, 07:44:15 Nachmittag »
--start=50 .. start ist auf 10 Sekunden limitiert, die nächste Version ist auf 30 Sekunden limitiert das sollte ausreichen.
Failure is a good thing! I'll fix it

sparkie

  • Jr. Member
  • **
  • Beiträge: 65
    • Profil anzeigen
Re:Option '--scan-network' funktioniert leider nicht
« Antwort #7 am: Juli 22, 2012, 07:59:26 Nachmittag »
ok danke, ist aber (zumindest fuer mich) gar nicht mehr noetig. Der beste Workaround, den ich bislang gefunden geht so:

1. diese Files:

/etc/udev/rules.d/80-mediasrv-eeti.rules
/lib/udev/rules.d/80-mediasrv-eeti.rules

einfach loeschen. Damit wird der 'mediasrv' erst mal nicht gestartet. Nachdem das, wie wir gesehen haben ja sowieso keinen Sinn macht, sollte das Netzwerk noch nicht oben sein. Da ich im laufenden Betrieb keine Sticks zu/abstecke sind obige Regeln fuer mich also nur kontraproduktiv.

2. ich starte den 'mediasrv' stattdessen erst in '/etc/rc.local' mittels

/opt/bin/mediaclient --start

fertig - das hat bei mir alle Probleme geloest! Das zeigt ausserdem, dass das Problem  nicht an meiner Netzwerk-Konfiguration liegen kann.

Zudem kommt das System dann ohne 'sleeps' optimal schnell hoch.

Der Workaround ist zwar nicht im Sinne des Erfinders - aber was soll's  :D

Ich kann gerne noch was testen, sollten die eigentlichen Probleme angegangen werden. Aber fuer mich ist der Workaround soweit ok.

natuerlich trotzdem danke soweit fuer den Wochenend-Support. Da seid ihr wirklich eine Ausnahme :)

- sparkie


« Letzte Änderung: Juli 23, 2012, 03:06:57 Nachmittag von sparkie »