[Erledigt] Mesh: Was übernimmt ein Repeater vom Mesh-Master ?

[PeterPawn]

Dann muß man das wohl doch mal mit dem Paketmitschnitt ansehen, was da - mit und ohne aktivierte "Optimierung" - in der WLAN-Steuerung (bzw. ja sogar in den Daten, wenn das wirklich auf "Unicast-Pakete" umschaltet, denn der andere zu verwendende Schlüssel (PTK vs. GTK) bleibt ja weiterhin der Knackpunkt) "über den Äther" geht.

Ich verstehe auch noch, wenn man Broadcasts (im AP) limitiert (niemand kann einen Client (STA) davon abhalten, statt eines UC-Paketes eines mit einer Broadcast-MAC zu senden, wenn er "an der Reihe" ist) ... aber MC-Streams, für die der Client sogar noch extra eine "Anmeldung" machen muß (und ohne Subscription geht der Stream an gar keinen Client des AP), ebenfalls einem Limit zu unterwerfen (in den WLAN-Spezifikationen habe ich nichts von einer "Vorgabe" gefunden, nehme aber entsprechende "Literaturtipps" gerne), erscheint mir nicht einleuchtend und anstatt da einen MC-Stream in mehrere UC-Streams umzuwandeln, wäre doch eine Anhebung des MC-Limits irgendwo logischer.

Ich hatte das mit der Fundstelle in #21 auch zuerst mißverstanden ... das ist also keine (gesonderte) Fundstelle, wo dieses Llimit irgendwo festgelegt oder erläutert wird, sondern genau diese Stelle in dem Heise-Sonderheft. Das ist also nur "selbstreferenziert" ... ich will es jetzt nicht beschwören, aber in früheren Versionen der Firmware glaube ich da auch tatsächlich auch "WMM" gelesen zu haben in den AVM-Einstellungen. Leider sind die ganzen alten Hilfeseiten (über "help.avm.de/fritzbox.php") nicht mehr erreichbar ... die Anzeige bei den Clients in neuer Firmware gibt m.E. nur das wieder, was der Client benutzen könnte (hier eben auch WMM oder auch die erweiterten Stromspareinstellungen aus der entsprechenden Erweiterung der Spezifikation) und nicht das, was da gerade verwendet wird - aber auch da ist die Beschreibung leider nicht eindeutig.

Jedoch wenn man sich mal die Konsequenzen überlegt, was das in einem Haushalt mit zwei T-Entertain-Receivern in zwei Räumen heißt, wenn da zweimal derselbe HD-Stream geschaut werden soll, macht es ja irgendwo keinen Sinn, wenn man die Übertragung der doppelten Datenmenge über das WLAN als "Optimierung" ansehen will.

Leider geht auch aus der jeweils erzeugten "/var/tmp/wlan_dynamic.cfg" nicht genauer hervor, was das Ergebnis der Änderung ist, weil die Einstellung auch da nur unter dem Namen "IPTVoptimize" firmiert. Auch in den Symbolen des "wland" findet sich praktisch nichts, was irgendwo auf eine Konvertierung von Multicast-Streams in mehrere Unicast-Streams hindeuten würde ... bleibt wohl doch nur der Paketmitschnitt.

 

[BlueEx]

Im Falle einer tatsächlichen Limitierung von Multicasts ins WLAN (als Broadcast, max. 6Mbit) würde der doppelt gesendete Stream in deinem Beispiel Sinn machen - es käme netto immer noch wesentlich mehr Bandbreite raus als bei MC.

Man könnte zu diesem Thema natürlich auch nochmal detailliert bei Heise und AVM nachfragen.

 

[Theo Tintensich]

MESH ist doch 802.77r, und damit auch anfällig für
https://www.heise.de/security/meldu...en-aber-nicht-gaenzlich-geknackt-3862571.html
Wobei AVM in ihrer Mitteilung zu diesem Thema
https://avm.de/aktuelles/kurz-notiert/2017/wpa2-luecke-fritzbox-am-breitbandanschluss-ist-sicher/
sagt, dass ja nur 802.11r betroffen sein, also nicht ihre APs.
Es sind aber auch die WiFi-Clients, (ohne 'r') betroffen, und FritzBoxen kann man als Clients verwenden bzw die Repeater, die dann Clients sind, einbinden.

Eine FRITZ!Box am Breitbandanschluss ist nach aktuellem Stand nicht von der "Krack" genannten WLAN-Sicherheitslücke betroffen, da sie als Access Point die betroffene Norm 802.11r nicht verwendet. Ein möglicher theoretischer Krack-Angriff richtet sich gegen die WLAN-Verbindung eines Klienten, der sich im WLAN anmeldet....

 

[BlueEx]

Selbst bei Wikipedia gibt es einen Eintrag zu der Multicast / Broadcast Problematik im WLAN einen Eintrag:

https://de.wikipedia.org/wiki/Sat-over-IP-Technik

Probleme
Wenn mehrere SAT>IP-Clients dasselbe Programm anfragen und der Sat>IP-Server den Datenstrom per Multicast verschickt, so fallen viele WLAN-Basisstationen gemäß WLAN-Spezifikation auf einen speziellen Multicast-Modus zurück, der ein besonders sicheres Versenden garantieren soll. Für diesen Modus ist eine Brutto-Datenrate von nur 6 MBit vorgesehen, was selbst für ein SD-Programm nicht ausreichend ist. Daher lässt sich in neueren WLAN-Basisstationen (sowie in manchen Routern) einstellen, dass Multicast-Pakete von ihnen in Unicast-Pakete gewandelt werden sollen (für jeden einzelnen der Empfänger). Dies vervielfacht zwar das Übertragungsvolumen, erlaubt einer WLAN-Basisstation aber, im (sehr viel) schnelleren Unicast-Modus zu bleiben, in dem jeder Client dann mit ausreichender Bandbreite versorgt werden kann.

Scheint also nicht so abwegig zu sein die Aussage.

 

[PeterPawn]

Inzwischen hatte ich auch ein entsprechendes Paper gefunden und da steht dann auch tatsächlich die Erklärung drin, warum solche Aussendungen als Multicast/Broadcast langsamer sind (genauer eigentlich: sein können) und mit diesem Wissen ergibt dann auch die Umsetzung auf Unicast-Streams wieder einen Sinn.

Da eben auch die am schlechtesten empfangende Station so eine MC-/BC-Übertragung noch erhalten muß/soll, wird hier immer (eigentlich logisch, aber da hatte ich Scheuklappen bzw. nicht daran gedacht) mit der geringst möglichen gemeinsamen Rate (basic rate) gesendet und damti belegt so eine MC-/BC-Aussendung tatsächlich länger das Übertragungsmedium, als sie es bei der (sequentiellen) Aussendung an mehrere STA, aber mit wesentlich höheren Datenraten, belegen würde.

Auch der Management-Traffic im WLAN geht normalerweise nur mit dieser "basic rate" auf die Reise. Diese ist aber auch nicht "fest vorgegeben" vom Standard, es gibt auch APs/Router, wo man diese Basis-Datenrate einstellen kann anhand der Möglichkeiten der eingesetzten Geräte. Wichtig ist halt nur, daß alle Teilnehmer im WLAN auch diesen Wert unterstützen als kleinsten gemeinsamen Nenner, damit sie wenigstens eine Möglichkeit der Kommunikation haben.

Hier bürdet sich also der AP (oder der Router) ein Vielfaches an Arbeit auf (er muß ja mehrfach verschlüsseln), aber dafür belegt er tatsächlich am Ende weniger den Kanal (bis zu einer gewissen Zahl von Zielen jedenfalls), als wenn er das als Multicast-Stream mit der "basic rate" verschickt. Dazu muß er allerdings auch selbst verwalten, welche STA jetzt welche MC-Adressen abonniert hat.

Und natürlich hat das nur dann einen Effekt, wenn nicht einer der zu versorgenden Clients ohnehin nur mit einer Datenrate erreicht werden kann, die nur wenig über der "basic rate" liegt ... dann belegt die Übertragung zu diesem Client dieselbe Zeit das Medium (zumindest annähernd), wie die Multicast-Aussendung es tun würde und die anderen Sendevorgänge kämen noch dazu.

 

[KunterBunter]

Der Link lautet: https://tools.ietf.org/html/draft-perkins-intarea-multicast-ieee802-00

 

[BlueEx]

Es gibt wohl auch Router, welche die höchstmögliche Datenrate des am schlechtesten erreichbaren WLAN-Clients automatisch ermitteln (über die UC Verbindung eines jeden Clients) und die Multi-/Broadcast Rate darauf anpassen, anstatt einen fest eingestellten Wert von beispielsweise 6Mbit zu verwenden (so wie es vermutlich die Fritzbox bei deaktivierter Optimierungsoption macht).

Gut, das nun zumindest mal der Sinn und die Funktionsweise dieser Funktion geklärt werden konnte - ergo sollte man diese Option bei der Fritte immer aktiviert haben, wenn man per WLAN IPTV schaut.

Abseits dieses Szenarios sollte die Option keinerlei Auswirkungen haben, nachdem was wir jetzt wissen.

 

[PeterPawn]

Außer man hat tatsächlich einen Client (meinetwegen ein Tablet), mit dem man auch unter schlechten Empfangsbedingungen (z.B. im Garten und in Bewegung) solche Streams schaut, während parallel auf festen Geräten auch noch derselbe Stream gesehen wird. Zugegebenermaßen ein recht konstruiertes Szenario, aber "denkbar".

Als Frage bliebe für mich trotzdem noch offen, ob die Box dabei wirklich ausschließlich MCs mit IPTV-Streams in UC wandelt oder einfach alles. Dazu müßte sie entweder den Inhalt analysieren oder anhand anderer Merkmale feststellen (z.B. anhand bekannter Adressen beim Entertain-TV), daß es sich um IPTV handelt.

Macht man das an der MC-Adresse fest, funktioniert das (vermutlich) auch wieder nur für der AVM-Firmware bekannte Adressen (auch die Logos werden bei der IPTV-Funktion ja direkt vom AVM-Server geladen ... ob da inzwischen ein Cache dazwischen ist, weiß ich gar nicht) und bei eigenen MC-Aussendungen (z.B. mit einem Mediaserver im Netzwerk, der ebenfalls Multicast-Streams sendet) würde das nicht wirken.

Wie stellt man jetzt bei einem Datenpaket fest, ob es zu einem IPTV-Stream gehört? So eine Subscription für eine MC-Adresse kann zu jedem beliebigen Zeitpunkt beim AP/Router eintreffen, der muß dann seinerseits diese Abonnements per IGMP weiterreichen. Damit gibt es aber hier keinen "Anfang" eines Streams ... und da Adressen und Ports "frei wählbar" sind (im Rahmen des zulässigen für Multicast-Adressen), kann man es auch daran nicht festmachen.

Wenn das aber am Ende alle MC-Pakete betrifft (also auch die, welche keinen IPTV-Traffic transportieren), dann gehen auch mDNS-Announcements, UPnP-Verwaltung und sogar IPv6-"Absprachen" im lokalen Netz nur noch als UC an jede einzelne Station und das kann dann trotzdem wieder langsamer werden (bei aktivierter Option), wenn auch nur ein Client mit Empfangsbedingungen existiert, die nur wenig über der "basic rate" zulassen und der aber solche Adressen seinerseits abonniert (das macht heute jedes IPv6-fähige Gerät, jeder Windows-PC, jedes Gerät mit "avahi"-Support unter Linux, usw.).

Daher bin ich bei dem "ansonsten keine Auswirkungen" noch nicht so ganz überzeugt ... die (sichere) "Erkennung" von Multicast-Traffic als IPTV-Streams dürfte recht schwierig sein und da würde mich schon noch interessieren, wie die Box das handhabt für andere Multicast-Pakete. Es wäre natürlich auch denkbar, daß explizit bestimmte, bekannte Protokolle/Adressen von dieser Umsetzung ausgenommen werden und deshalb dann mDNS, UPnP und IPv6-Management (um mal bei den Beispielen zu bleiben) weiterhin als Multicast-Traffic gesendet werden.