Entertain mittels Multicast-Adressen über WLAN

[ecox]

Hallo zusammen,

der eine oder andere Entertainer kennt ja sicherlich folgende Seite Entertain Multicast-Adressen (oder eben auch NICHT Entertainer).

Als ich noch in der Speedport, D-Link & FRITZ! Welt unterwegs war, hat dieses Thema nie ein Problem dargestellt, weder über LAN noch über W-LAN. Es gestaltet sich nun so:

Eins vorweg, mit LAN klappt natürlich alles problemlos

»Entertain mit Wizzard eingerichtet (typisch eben, zwei WAN Verbindungen, zwei FW-Regeln für Multicast und 3 Routing Einträge
»In den logischen WLAN-Einstellungen die Basis-Geschwindigkeit auf max (54Mbit/s)
»Ich denke das hier der Knackpunkt ist, 54Mbit/s sind nur knapp 6,8Mbyte/s, für Entertain ansich zu langsam (da sollten schon 8Mbyte/s ankommen)
»Fakt ist das das umstellen von 2Mbit/s auf 54Mbit/s Besserung brachte, jedoch nach wie vor nur Kästchenbildung ergo man kann sogut wie nichts erkennen
»Hinzu kommt das wohl die 54Mbit/s sowieso niemals erreicht werden, nur rein theoretisch
»Zur Sicherheit noch das IGMP Snooping auf WLAN-1-2 auf Ja gesetzt, wobei das Fluten ja gut im automatischen Modus funktioniert

So, ich denke das das Problem hier wirklich die Sendegeschwindigkeit von Multicast über WLAN ist, oder liege ich da falsch?

Hat evtl. einer das gleiche Problem oder stand mal davor und hat es gelöst? Ich bin gespannt über Ideen und Ansätze

Was die FRITZ!Box oder gar der Speedport kann, muss man doch irgendwie realisiert bekommen.

[alf29]

Moin,

wenn der Stream echt 8 MByte/ s braucht (wäre aber auch für Full-HD schon heftig?), dann hast Du in der Tat ein Problem. 54MBit/s brutto sind netto bestenfalls ~24 MBit/s. Höher drehen, also auf 11n-Raten stellen kann man die Multi/Broadcast-Rate nicht, das würde auch nicht allzuviel bringen, weil bei höheren Bitraten der Overhead für das einzelne Paket immer höher wird und die Nettorate nicht mehr ansteigt.

Was Fritz und Co machen? Sie haben eine Funktion, die vom Streaming-Server kommenden Multicasts zum WLAN-Client hin in Unicasts umzuwandeln. Das hat eine Reihe von Vorteilen: Die Bitrate darf bis zu der maximalen Bitrate der Verbindung steigen, sie wird dynamisch zwischen AP und Client je nach Qualität der Funkverbindung ausgehandelt, verloren gegangene Pakete werden wiederholt, und mit der bei Unicasts möglichen Frame-Aggregierung wird das Verhältnis von Netto- zu Bruttorate dramatisch besser.

Und kurz gesagt: LANCOMs haben dieses Multicast-zu-Unicast-Feature nicht. Multicasts und Broadcasts gehen als solche aufs WLAN raus und sind den Beschränkungen für solche Pakete unterworfen - keine Frame-Aggregierung, Beschränkung auf Legacy-Bitraten, keine Wiederholung bei Übertragungsfehlern und keine dynamische Aushandlung der Bitrate.

Mir ist auch nicht bekannt, daß dieses Feature in absehbarer Zeit auf der Roadmap stände. Video-Streaming ist eher ein "Homeuser-Thema", in den Märkten, in die LANCOMs zu 95% hineinverkauft werden, interessiert das Thema offensichtlich niemanden. Was nicht heißen soll, daß nicht morgen irgendein Großkunde um die Ecke kommen und das fordern kann, dann sähe die Sache anders aus. Ich halte es aber nicht für sehr wahrscheinlich, daß das in nächster Zeit passiert.

Gruß Alfred

[ecox]

Hallo Alfred,

danke für die Info, das erklärt natürlich einiges. Nunja ich habe es nun schon oft gehabt das Arztpraxen, Warteräume usw. in mehreren Räumen Entertain laufen lassen wollten (N24 usw), eben mit diesen Multicast-Adressen (diese Kd. hatten auch immer an die VDSL100, da wäre das natürlich kein Problem gewesen).

Naja wer weiß, eine schöne Sache wäre das schon ist es denn so kompliziert diese Umwandlung zu machen oder ist es hier wirklich ein Kosten/Nutzen-Faktor das zu implementieren?

Grüße

[alf29]

Moin,

Naja wer weiß, eine schöne Sache wäre das schon ist es denn so kompliziert diese Umwandlung zu machen oder ist es hier wirklich ein Kosten/Nutzen-Faktor das zu implementieren?

Das ist immer eine Kosten-Nutzen-Rechnung, und so lange sich die Geräte in der Masse auch ohne verkaufen und man dem Produktmanager keine Zahl geben kann, a la "ich habe hier eine Ausschreibung für x-tausend Geräte und ohne das Feature kommen wir da nicht rein", gibt es eben genug andere Dinge, mit denen man die Entwicklung beschäftigen kann.

Und wenn Du darauf anspielst, daß ich in der Vergangenheit auch das eine oder andere "einfach so" gemacht habe: das fürs erste zumindest für mich vorbei. Zum einen habe ich selber kein Entertain zu Hause, zum anderen habe ich das letzte Mal, als ich mich persönlich für ein Feature engagiert habe (das war der Umbau der WLAN-MAC-Adreßliste auf flexiblere Regeln), hier im Forum derart negative und demotivierende Reaktionen bekommen, daß ich fürs erste beschlossen habe, meine Freizeit mit Dingen zu verbringen, aus denen ich positive Energien ziehen kann. Aber das nur an Rande...

Gruß Alfred

[ecox]

Und wenn Du darauf anspielst, daß ich in der Vergangenheit auch das eine oder andere "einfach so" gemacht habe: das fürs erste zumindest für mich vorbei. Zum einen habe ich selber kein Entertain zu Hause, zum anderen habe ich das letzte Mal, als ich mich persönlich für ein Feature engagiert habe (das war der Umbau der WLAN-MAC-Adreßliste auf flexiblere Regeln), hier im Forum derart negative und demotivierende Reaktionen bekommen, daß ich fürs erste beschlossen habe, meine Freizeit mit Dingen zu verbringen, aus denen ich positive Energien ziehen kann. Aber das nur an Rande...

davon weiß ich nichts, das muss vor meiner lancom zeit gewesen sein ich erwarte auch nicht das hier was auf zuruf eingebaut wird, dafür ist das ganze zu komplex (wirtschaftlich gesehen). und nunja, solange es diese option nicht gibt, kann man das kunden schlecht andrehen, die brauchen immer was zum anfassen, sehen, greifbares, erzählen kann man den ja viel die ticken alle komisch, nunja, kunde ist könig

aber ich denke ich kann dies doch durchaus als feature wunsch äußern oder wäre das an falscher Stelle

grüße

[Dr.Einstein]

Nur zur Einheitenkorrektur: Entertain SD: 2-3 Mbit/s, Entertain HD: 8 Mbit/s

Gruß Dr.Einstein

[alf29]

Nur zur Einheitenkorrektur: Entertain SD: 2-3 Mbit/s, Entertain HD: 8 Mbit/s

Das wäre mit 54 MBit Multicastrate brutto noch problemlos zu machen. Was der Sache vermutlich dann noch das Genick bricht, ist die fehlende Wiederholung bei Übertragungsfehlern.

Gruß Alfred

[Chaosphere64]

Kurze Anmerkung: Ich habe mich auch eine ganze Weile gewundert, warum Geräte von AVM, ASUS etc. bei mir problemlos Entertain an Endgeräte gesendet haben, hochpreisige Router bzw. APs (darunter auch LANCOM) aber nicht. Irgendwann bin ich darauf gestossen, was hier auch schon gesagt wurde: Die senden gar kein Multicast! Im Falle meines damaligen ASUS RT-N66-U habe ich dann herausgefunden, dass dort schlicht eine Softwarelösung zu diesem Zweck implementiert worden ist: udpxy, der UDP Multicast auf einen http-Stream für einen anfordernden Client, also TCP Unicast, wandelt.

Vielleicht magst Du für ausgewählte Fälle so etwa mit einem RPi auf Linux oder BSD oder ähnlichem bauen, selber habe ich das nie versucht.

HTH

[ecox]

Das klingt gut, ich werde das mal mit udpxy probieren, installiere gerade mal ubuntu als vm . Danke für den tip!

[Chaosphere64]

Gerne, falls Du die Zeit findest, würde ich mich über Feedback freuen. Viel Erfolg!

[ecox]

Gerne, falls Du die Zeit findest, würde ich mich über Feedback freuen. Viel Erfolg!

Läuft bombenmäßig, habe FreeBSD in die VM installiert, udpxy auf Port 4022 gestartet und vom Laptop mit Windows aus den Link http://192.168.10.35:4022/udp/239.35.10.4:10000 geöffnet, fertig. Die HTTP Geschichte bringt natürlich den Vorteil von VPN, also EntertainToGo wäre jetzt überflüssig

Anleitungen gibt es viele, aber am wichtigsten ist

Code: Alles auswählen

cd /usr/ports/net/udpxy
make config && make install clean

Quelle

Nun läuft die Sache auch über WLAN denn udpxy macht das unmögliche möglich

udpxy is a UDP-to-HTTP multicast traffic relay daemon: it forwards UDP traffic from a given multicast subscription to the requesting HTTP client.

Grüße

P.S.: Da ich überall Deny-all fahre habe ich zum test alle Firewalls ausgemacht, aus zeitlichen Gründen, man muss wohl in FreeBSD noch was an der Firewall machen bin dazu aber nicht gekommen, einfach die ipfw ausschalten wenn du auch nur schnell testen willst...

[Chaosphere64]

Sehr schön, vielen Dank für den Erfahrungsbericht. Freut mich, dass mein Tip Dir geholfen hat. Ich nehme mal an, dass die Last von udpxy nicht so groß ist, dass ein RPi2 o.ä. das nicht bewältigt bekäme. Selbst der ASUS hat das damals problemlos mit mehreren Clients gleichzeitig hinbekommen, und der war ja deutlich weniger leistungsstark.

[ua]

Tach Zusammen,

kurze Rückmeldung:
udpxy läuft prima (über WLAN und VPN ) , danke für den Tip!
Habe es auf ein Debian unter Hyper-V geworfen, Prozessorlast lt. Hyper-V: 0-1% (bei einem HD-Stream).
Sollte also auch einem RASPI laufen, da könnte höchstens der Netzwerkport (ist intern nur über USB angebunden) den Flaschenhals bilden.

VG aus OBC

Udo

[ecox]

Dadurch das FreeBSD sogut wie keine Ressourcen brauch und der Pi2 genug Leistung hat, sollte das kein Problem darstellen ich glaube ich muss mir da mal einen Pi zulegen

[Chaosphere64]

Das denke ich auch. Ich habe mehrere RPi2 (unter Linux und BSD) im Einsatz (u.a. für das Network Monitoring mittels NAGIOS sowie PRTG, für DNS und DHCP). Die kleinen Dinger leisten wirklich erstaunlich viel, lediglich die Anbindung der Ethernet Schnittstelle über den USB ist wie schon erwähnt unschön. Einen Fileserver würde ich also nicht unbedingt darauf aufsetzen, für udpxy sollte er ideal sein, solange die Zahl der angehängten Clients nicht die Bandbreite sprengt. Ansonsten könnte man auch einen Banana Pi o.ä. mit Gigabit Ethernet nehmen. FreeBSD Support gibt es für den auch.