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.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 529905
Url: https://administrator.de/contentid/529905
Ausgedruckt am: 14.11.2024 um 01:11 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.
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...?!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 !