Multicast Routing

[spambin]

Hi,

ich habe hier getrennte Netze für LAN und WLAN, im LAN steht ein UPnP/DLNA Server, auf den LAN-Clients problemlos zugreifen können. WLAN-Clients können ihn nicht sehen, was daran liegen dürfte, dass der Router eben keinen Multicast-Traffic routet.

Gibt es da eine onboard-Lösung?

 

[frank_m24]

Das liegt nicht am fehlenden Multicast Routing, sondern daran, dass über Subnetz-Grenzen hinweg keine Broadcasts übertragen werden. UPNP arbeitet mit Broadcasts, nicht mit Multicasts.

Frage: Warum trennst du überhaupt die Netze?

 

[spambin]

Das liegt nicht am fehlenden Multicast Routing, sondern daran, dass über Subnetz-Grenzen hinweg keine Broadcasts übertragen werden. UPNP arbeitet mit Broadcasts, nicht mit Multicasts.

Da muss ich leider widersprechen, UPnP verwendet für die discovery Phase SSDP, welches Multicast auf Adresse 239.255.255.250, Port 1900 verwendet, siehe hierzu auch den Wikipedia-Artikel zu UPnP und den Wikipedia-Artikel zu SSDP

Frage: Warum trennst du überhaupt die Netze?

Ich habe hier das klassische Setup mit getrennten Netzen für LAN, WLAN und DMZ, das WLAN-Netz betrachte ich als generell unsicher. Ich habe auch unterschiedliche Konfigurationen für DHCP, im LAN gibt es z.B. keine Antworten für unbekannte Clients.

Was noch interessant in Bezug auf das Multicast-Routing-Problem ist: Die FB reagiert auf pings auf 224.0.0.2 (ALL ROUTERS) udn 224.0.0.22 (IGMP), behauptet also Multicast zu routen.

 

[frank_m24]

Hallo,

Da muss ich leider widersprechen, UPnP verwendet für die discovery Phase SSDP

Das würde ich nicht uneingeschränkt unterschreiben. Ich vermute, dass die UPNP Spec hier weich ist und auch Broadcasts erlaubt. Ich kann mich an mindestens eine Installation erinnern, in der UPNP funktioniert, obwohl der Switch definitiv Multicasts verwirft (warum auch immer). Es würde auch einige andere Effekte erklären, die ich im Umfeld UPNP gemacht habe.

Was noch interessant in Bezug auf das Multicast-Routing-Problem ist: Die FB reagiert auf pings auf 224.0.0.2 (ALL ROUTERS) udn 224.0.0.22 (IGMP), behauptet also Multicast zu routen.

Das ist auch richtig, wie hier im Forum schon nachzulesen ist. Auch IP-TV von T-Home Entertain funktioniert ja mit Fritzboxen, und das basiert ebenfalls auf IPv4 Multicast.

Ich habe hier das klassische Setup mit getrennten Netzen für LAN, WLAN und DMZ, das WLAN-Netz betrachte ich als generell unsicher.

Du bist dir darüber im Klaren, dass diese Trennung keinerlei Schutz bietet, da die Box zwischen beiden Netzen vollwertig und uneingeschränkt routet?

 

[spambin]

Hallo,
Das würde ich nicht uneingeschränkt unterschreiben. Ich vermute, dass die UPNP Spec hier weich ist und auch Broadcasts erlaubt.

Hm, das halte ich für sehr unwahrscheinlich, denn die discovery funktioniert ja quasi rückwärts, indem die Clients die Multicastgruppe joinen, in der der Server bereits drin ist. Ohne Multicast müsste der Server ja die Broadcasts schicken.
Ich sehe hier jedenfalls keine Broascasts vom UPnP-Server im Netz (direkt auf dem Host, auf dem der Server läuft).

Ich kann mich an mindestens eine Installation erinnern, in der UPNP funktioniert, obwohl der Switch definitiv Multicasts verwirft (warum auch immer). Es würde auch einige andere Effekte erklären, die ich im Umfeld UPNP gemacht habe.

Du meinst hier Router, nicht Switch, oder? Ein Switch arbeitet auf layer 2, der kümmrt sich nicht um den Inhalt der Ethernet-Pakete, dem ist es total egal, ob es sich bei einem Paket um Unicast, Multicast oder Broadcast handelt. Oder sprichst Du jetzt von Ethernet/L2 Multicast (im Gegensatz von IP/L3-Multicast)? Das ist eine ganz andere Baustellle.

Was wirklich seltsam ist: Die FB reagiert sowohl im LAN wie auch im WAN auf die Multicast-Gruppen 224.0.0.2, 224.0.0.22 und 239.255.255.250, aber die Kommunikation zwischen Clients im WLAN und dem Server im LAN funktioniert nicht.

Ich lasse jetzt mal für einige Zeit ein tcpdump mit laufen, vielleicht zeigt das ja das Problem auf.

 

[frank_m24]

Hallo,

Du meinst hier Router, nicht Switch, oder?

Ich meine tatsächlich Switches.

Ein Switch arbeitet auf layer 2, der kümmrt sich nicht um den Inhalt der Ethernet-Pakete, dem ist es total egal, ob es sich bei einem Paket um Unicast, Multicast oder Broadcast handelt.

Soweit die Theorie (die allerdings mittlerweile auch ganz offiziell überholt ist).
Wir entwicklen bei uns in der Firma u.a. IPv4 und IPv6 Multicast-Software und haben in unserer Sammlung "problematischer Netzwerkgeräte" Switches, Ethernet-Karten usw., die Probleme mit Multicast haben. Einige Switches können gar kein Multicast, andere nur IPv4 aber kein IPv6 Multicast. Ursache sind die reservierten MAC Adress-Blöcke, auf die Multicast Traffic gemappt wird, mit der die Lookup-Algorithmen dieser Geräte nicht zurecht kommen. Ich kann mich auch an mindestens einen Fall hier aus dem Forum erinnern, da hatte jemand Probleme mit T-Home Entertain, und die Ursache war sein Switch.
Mittlerweile ist es so, dass (managed) Switches ganz offiziell in Multicasts reinsniffen, Stichwort IGMP bzw. MLD Snooping. Damit können sie Multicast Traffic dediziert auf ihre Ports mappen.

 

[tux]

Hallo,

Als workaround kannst du ein Andriod/ iOS device einsetzen und dann via PlugPlayer deinen Renderer beschicken. In diesem Thema habe ich schon etwas dazu geschireben:

http://www.ip-phone-forum.de/showthread.php?t=216476

 

[spambin]

Hallo,

Als workaround kannst du ein Andriod/ iOS device einsetzen und dann via PlugPlayer deinen Renderer beschicken. In diesem Thema habe ich schon etwas dazu geschireben:

http://www.ip-phone-forum.de/showthread.php?t=216476

Da das Ziel sowieso ein Android-Phone sein soll, wäre das noch nicht mal einWorkaround. Im Moment setze ich UPnPlay als Renderer ein, das den Server aber nicht findet.
Bevor ich jetzt Geld für PlugPlayer ausgebe, in dem Thread oben hast Du geschrieben, Du hättest das iPad zuerst im Server-Netz gehabt, damit PlugPlay den Server finden konnte. Diese Möglichkeit habe ich ja nicht, da hier ja der Server im WLAN gar nicht sichtbar ist und ich mein Android-Phone nicht in's LAN bringen kann.

 

[tux]

Hej

Man kan die device url auch händisch eintippen. Hier ist die Software jedoch recht schlecht, da es die url ganz genau haben will. Incl. http:// ...


Dieses im Forum angepriesene java tool funktionierte bei mir unter OSX nicht.

http://www.plugplayer.com/forum/viewtopic.php?f=3&t=468&sid=8f509d64920f1e00443c993783a1addd

Auch lässt sich (unter iOS) eine einmal gefundene url nicht komplett lesen (es werden nur die ersten X Zeichen angezeigt) bzw. kopieren. Sonnst könnte ich die url der FB posten und du bräuchtest nur die IP Adresse tauschen. Dieses feature habe ich in der wishlist gespostet ist jedoch für iOS noch nicht umgesetzt. Wie es bei Andriod aussieht weiss ich nicht.

http://www.plugplayer.com/forum/viewtopic.php?f=5&t=839&sid=ca4e2aec0b34ba340353c4f6dbf4c53f

 

[spambin]

Hej

Man kan die device url auch händisch eintippen. Hier ist die Software jedoch recht schlecht, da es die url ganz genau haben will. Incl. http:// ...

Ah, das ist sehr praktisch. Mal sehen, ob ich den Autor von UPnPlay überreden kann, das ebenfalls einzubauen, sonst schaue ich mir wohl doch mal PlugPlay an.

Dieses im Forum angepriesene java tool funktionierte bei mir unter OSX nicht.

http://www.plugplayer.com/forum/viewtopic.php?f=3&t=468&sid=8f509d64920f1e00443c993783a1addd

Hier funktioniert es mit Java 6 unter Linux:

$ java -jar UPnPdevices.jar urn:schemas-upnp-org:device:MediaServer:1
Found device: http://192.168.225.7:5001/description/fetch

Gut, das beantwortet zwar nicht meine Frage, löst aber zumindest (hoffentlich) das ursprüngliche Problem

edit: Der Autor von UPnPlay hat die Möglichkeit, die URL direkt einzugeben eingebaut, so kann ich jetzt auch auf dem Server zugreifen. Gleichzeitig zeit das, dass die Kommunikation mit dem UPnP-Server korrekt funktioniert und das Problem tatsächlich das Multicast ist..
Das Problem ist damit nicht gelöst, ich habe aber einen für mich funktionierenden Workaround.