13
UPnP-Routing - Medien-Server in anderem Subnetz wird nicht von allen Clients bzw. Media-Playern gefunden
Hallo in die Runde,
wie an anderer Stelle hier im Forum schon mal erwähnt, bin ich gerade dabei, bei mir zuhause eine Art Servernetz aufzubauen. Genauer: einen Server mit Proxmox VE als Virtualisierungsplattform, der durch eine Firewall (APU2D4, Debian, iptables) kontrolliert mit dem bereits vorhandenen (User-) Netz verbunden sein soll. Aktuell ist der Server noch nicht da, wohl aber die Firewall (so weit konfiguriert), und ich teste deren Funktionalität mit einem Raspberry, der sich jetzt in dem Subnetz befindet, das später dem Server-Netz entsprechen soll (ist an LAN-Port 2 angeschlossen, während Port 1 mit einer FritzBox verbunden ist, die weiterhin als Internet-GW und WLAN-Router fungiert).
Einer der Dienste, die im Server-Netz laufen sollen, ist ein Medien-Server: minidlna, also UPnP. Idealerweise hätte ich auch den gerne im "Server-Netz" - deswegen habe ich die Firewall um smcroute erweitert und mit Hilfe von ipset war auch eine vernünftige iptables-Konfiguration möglich.
Jetzt, beim Test, bin ich auf folgende Merkwürdigkeit gestoßen: grundsätzlich funktioniert alles so, wie es soll. Verwende ich z.B. VLC, wird der Server im anderen Subnetz gefunden und man kann Mediendateien abspielen. Allerdings geht das nicht mit allen Clients bzw. Media-Playern. Von meinem Samsung Smart-TV wird der Server z.B. nicht gefunden. Ebenfalls nicht vom "PlayerXtreme" auf dem iPad (wohl aber vom VLC auf dem selben iPad).
Schaue ich mir mit tcpdump den Traffic (udp-Port 1900) auf FW und Server an, zeigt sich, dass, wenn z.B. der PlayerXtreme verwendet wird, Pakete an die richtige Multicast-Adresse (239.255.255.250) auf der Firewall registriert werden - aber sie kommen nicht beim Server an (ebenfalls mit tcpdump untersucht). Beim TV scheinen welche dort anzukommen, aber mit der Quell-Adresse des WLAN-Routers. Normalerweise finden sich auf beiden untersuchten Geräten, wie ja auch zu erwarten wäre, Pakete mit den Adressen von Client und Server selbst.
Eine erste Suche im Netz hat mich bisher weder einer Lösung noch wenigstens einer Erklärung des Problems näher gebracht. Hat jemand eine Ahnung, was dem zugrunde liegen könnte? Oder wie ich noch versuchen könnte, das Problem einzugrenzen? Ich bin gerade mit meinem Latein ziemlich am Ende...
Vielen Dank für die Zeit und bis später.
wie an anderer Stelle hier im Forum schon mal erwähnt, bin ich gerade dabei, bei mir zuhause eine Art Servernetz aufzubauen. Genauer: einen Server mit Proxmox VE als Virtualisierungsplattform, der durch eine Firewall (APU2D4, Debian, iptables) kontrolliert mit dem bereits vorhandenen (User-) Netz verbunden sein soll. Aktuell ist der Server noch nicht da, wohl aber die Firewall (so weit konfiguriert), und ich teste deren Funktionalität mit einem Raspberry, der sich jetzt in dem Subnetz befindet, das später dem Server-Netz entsprechen soll (ist an LAN-Port 2 angeschlossen, während Port 1 mit einer FritzBox verbunden ist, die weiterhin als Internet-GW und WLAN-Router fungiert).
Einer der Dienste, die im Server-Netz laufen sollen, ist ein Medien-Server: minidlna, also UPnP. Idealerweise hätte ich auch den gerne im "Server-Netz" - deswegen habe ich die Firewall um smcroute erweitert und mit Hilfe von ipset war auch eine vernünftige iptables-Konfiguration möglich.
Jetzt, beim Test, bin ich auf folgende Merkwürdigkeit gestoßen: grundsätzlich funktioniert alles so, wie es soll. Verwende ich z.B. VLC, wird der Server im anderen Subnetz gefunden und man kann Mediendateien abspielen. Allerdings geht das nicht mit allen Clients bzw. Media-Playern. Von meinem Samsung Smart-TV wird der Server z.B. nicht gefunden. Ebenfalls nicht vom "PlayerXtreme" auf dem iPad (wohl aber vom VLC auf dem selben iPad).
Schaue ich mir mit tcpdump den Traffic (udp-Port 1900) auf FW und Server an, zeigt sich, dass, wenn z.B. der PlayerXtreme verwendet wird, Pakete an die richtige Multicast-Adresse (239.255.255.250) auf der Firewall registriert werden - aber sie kommen nicht beim Server an (ebenfalls mit tcpdump untersucht). Beim TV scheinen welche dort anzukommen, aber mit der Quell-Adresse des WLAN-Routers. Normalerweise finden sich auf beiden untersuchten Geräten, wie ja auch zu erwarten wäre, Pakete mit den Adressen von Client und Server selbst.
Eine erste Suche im Netz hat mich bisher weder einer Lösung noch wenigstens einer Erklärung des Problems näher gebracht. Hat jemand eine Ahnung, was dem zugrunde liegen könnte? Oder wie ich noch versuchen könnte, das Problem einzugrenzen? Ich bin gerade mit meinem Latein ziemlich am Ende...
Vielen Dank für die Zeit und bis später.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 529905
Url: https://administrator.de/forum/upnp-routing-medien-server-in-anderem-subnetz-wird-nicht-von-allen-clients-bzw-media-playern-gefunden-529905.html
Ausgedruckt am: 31.12.2024 um 14:12 Uhr
13 Kommentare
Neuester Kommentar
Spannend wäre es mal gewesen wenn du zum Vergleich mal die Multicast Frames vom VLC angesehen hättest wie die am Ziel ankommen, denn die kommen ja richtig an.
Es muss da ja einen Unterschied geben zu denen die vom TV und dem PlayerXtreme kommen so das diese verworfen werden. Hast du das mal untersucht ?
Knackpunkt ist hier die TTL (Time to Live). Obowhl die Multicast Adresse 239.255.255.250 ja explizit keine Link Local Multicast Adresse ist die einen TTL von 1 immer erzwingt setzen aber viele Clients trotzdem den TTL Counter auf 1. Das bewirkt dann das diese MC Pakete nicht mehr routebar sind und sie im lokalen Segment versanden. Letztlich ist das dann ein Bug des Herstellers.
Wichtig ist also das du mit dem Wireshark mal die exakten Unterschied der VLC Frames im Vergleich zu den der beiden nicht laufenden Kandidaten untersuchst.
Es muss da ja einen Unterschied geben zu denen die vom TV und dem PlayerXtreme kommen so das diese verworfen werden. Hast du das mal untersucht ?
Knackpunkt ist hier die TTL (Time to Live). Obowhl die Multicast Adresse 239.255.255.250 ja explizit keine Link Local Multicast Adresse ist die einen TTL von 1 immer erzwingt setzen aber viele Clients trotzdem den TTL Counter auf 1. Das bewirkt dann das diese MC Pakete nicht mehr routebar sind und sie im lokalen Segment versanden. Letztlich ist das dann ein Bug des Herstellers.
Wichtig ist also das du mit dem Wireshark mal die exakten Unterschied der VLC Frames im Vergleich zu den der beiden nicht laufenden Kandidaten untersuchst.
Darüber, wie man das auf dem iPad anstellen kann, informiere ich mich gerade. Beim VLC bzw. dem entsprechenden PC habe ich mir den Traffic mit Wireshark angesehen. Die TTL des Request-Pakets ist in dem Fall 4.
Dass es an der Client-Software liegt, war auch mein erster Gedanke. Hatte allerdings keine Vorstellung davon, was genau es sein könnte. Danke also schon mal für den Hinweis.
Dass es an der Client-Software liegt, war auch mein erster Gedanke. Hatte allerdings keine Vorstellung davon, was genau es sein könnte. Danke also schon mal für den Hinweis.
Darüber, wie man das auf dem iPad anstellen kann, informiere ich mich gerade.
Guckst du hier:https://www.heise.de/ct/artikel/c-t-Raspion-Projektseite-4606645.html
Ist in 5 Minuten aufgesetzt und liefert dir kompletten Wireshark Traces im Browser
https://www.heise.de/select/ct/2020/1/1577557365384859
Das aktuelle Heft gibts noch am Kiosk !
Die TTL des Request-Pakets ist in dem Fall 4.
Da ist es dann spannend was TV und anderer Client da haben...?!
Hat etwas gedauert, aber nun konnte ich die beiden fraglichen Clients mit Hilfe von Raspion untersuchen - und in der Tat ist die TTL in beiden Fällen 1... Auch, wenn es schade ist, dass es hier also keine eigentliche Lösung gibt, habe ich dabei doch wieder mal einiges gelernt. Und der Raspion ist auf jeden Fall eine feine Sache. Also erneut vielen Dank für die Hilfe, aqui!
und in der Tat ist die TTL in beiden Fällen 1.
Tadaaa...wie vermutet ! Damit können die nicht geroutet werden. Ist die Pest mit den falschen MC Implementationen, denn das ist ein ganz klarer Bug. Ggf. kannst du einen Case beim Hersteller oder Programmauthor aufmachen ?! Bei VLC ist es im Default auch 1 aber es lässt sich dort zum Glück customizen:Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Kannst du mit dem RasPi testen..
Also erneut vielen Dank für die Hilfe, aqui!
Immer gerne ! Und Dank an dich für das hilfreiche Feedback ! 
Zumindest als UPnP-Client verwendet, scheint der VLC mittlerweile standardmäßig eine TTL von 4 zu benutzen. Den Wert fand ich jedenfalls gleich von Anfang an bei der Analyse der Players auf meinem PC. Einstellungen verändert hatte ich da nicht. Der VLC hat ja auch von Beginn an keine Probleme gemacht. Vielleicht haben die in der Zwischenzeit die Default-Einstellungen entsprechend geändert?
Ansonsten: ja, ich werde den Entwickler mal deswegen anschreiben. Wäre ja sicher kein großer Aufwand, das zu ändern.
Ansonsten: ja, ich werde den Entwickler mal deswegen anschreiben. Wäre ja sicher kein großer Aufwand, das zu ändern.
Wäre ja sicher kein großer Aufwand, das zu ändern.
Da hast du Recht. Das ist eine winzige Kleinigkeit und er muss nur eine Ziffer im Sourcecode ändern.
Ich habe auf jeden Fall mal eine Mail an deren Support geschrieben. Mal sehen, was bzw. ob da was herauskommt.
Feedback wäre mal spannend wenn da was kommen sollte vom Support.
Würde ich auf jeden Fall hier schreiben.
Bisher gab es leider keine Reaktion...
Allerdings habe ich in der Zwischenzeit eine (potentielle) Lösung für das Problem gefunden: ich lasse iptables die TTL der fraglichen Pakete hochsetzen:
Das funktioniert auch einwandfrei; allerdings habe ich an mehreren Stellen gelesen, dass eine solche Konfiguration massive Probleme verursachen kann. Offenbar dann, wenn durch eine Schleife im Netzwerk das Paket immer wieder den entsprechenden Router passiert und dadurch niemals verworfen wird.
Nur sehe ich in meinem Fall nicht, wie eine solche Situation entstehen könnte. Ich habe zwei Subnetze (192.168.0.0/24 und 10.0.0.0/24), wobei sich im ersten die Clients befinden und im zweiten die Server (bzw. ein Proxmox VE-Server mit diversen Containern). Verbunden sind sie über einen APU2D4 mit iptables. Außerdem gibt es eine FritzBox als Internet-GW und WLAN-AP. Die fraglichen Pakete entstehen im Client-Netz, gehen über die Fritzbox als AP/Switch zum APU2D4 (hier wird dann die TTL ggf. um 1 erhöht), und zuletzt sollten sie beim Medien-Server im Server-Netz ankommen.
Meint Ihr, bei diesem Aufbau könnte diese Konfiguration Probleme verursachen?
Allerdings habe ich in der Zwischenzeit eine (potentielle) Lösung für das Problem gefunden: ich lasse iptables die TTL der fraglichen Pakete hochsetzen:
iptables -t mangle -A PREROUTING -i enp1s0 -s 192.168.0.0/24 -d 239.255.255.250 -p udp --dport 1900 -m ttl --ttl-eq 1 -j TTL --ttl-inc 1Das funktioniert auch einwandfrei; allerdings habe ich an mehreren Stellen gelesen, dass eine solche Konfiguration massive Probleme verursachen kann. Offenbar dann, wenn durch eine Schleife im Netzwerk das Paket immer wieder den entsprechenden Router passiert und dadurch niemals verworfen wird.
Nur sehe ich in meinem Fall nicht, wie eine solche Situation entstehen könnte. Ich habe zwei Subnetze (192.168.0.0/24 und 10.0.0.0/24), wobei sich im ersten die Clients befinden und im zweiten die Server (bzw. ein Proxmox VE-Server mit diversen Containern). Verbunden sind sie über einen APU2D4 mit iptables. Außerdem gibt es eine FritzBox als Internet-GW und WLAN-AP. Die fraglichen Pakete entstehen im Client-Netz, gehen über die Fritzbox als AP/Switch zum APU2D4 (hier wird dann die TTL ggf. um 1 erhöht), und zuletzt sollten sie beim Medien-Server im Server-Netz ankommen.
Meint Ihr, bei diesem Aufbau könnte diese Konfiguration Probleme verursachen?
ich lasse iptables die TTL der fraglichen Pakete hochsetzen:
Das ist natürlich sehr pfiffig ! 😎Offenbar dann, wenn durch eine Schleife im Netzwerk
Stimmt aber solange du keine L3 Redundanz hast geht die Gefahr von Loops gegen Null. Aufpassen muss man natürlich etwas.
Danke für die Bestätigung. Ich werde es mal so lassen und in der nächsten Zeit beobachten. Bisher konnte ich auch noch nichts Ungewöhnliches feststellen (habe den Server heute vom iPad aus etwas beansprucht und tcpdump laufen lassen).
