Kaufberatung WLAN Router

Denke mit einer 7590 und mindestens den FritzRepeatern ab Model 2300 machst nichts falsch.
Habe diese Konstelation bei meiner Schwester im Haus aufgebaut in Verbindung mit einer 250er DSL Leitung.
Fritzbox ist im Wohnzimmer, geht von dort aus via LAN auf ein Netgear Switch. Die Mesh Repeater sind bisauf einer via LAN eingespeist. Ein weiterer im Gartenhaus ist über einen näheren Repeater in Reihe geschaltet.
Bis dato gab es keine Probleme, egal ob Homeoffice,Streaming oder Gaming.
Empfehle vorallem bei Smarthome die SSIDs zu splitten.

Zitat von buers

Verstehe nicht, wie du das meinst.

Ok. Gibt im Prinzip drei Multicastfunktionen, die relevant sind.

1. IGMPv3 support auf dem Router. Einfach so, das der IGMPv3 Anfragen aus dem lokalen Netz ins WAN so weiterleitet das die Telekom damit gluecklich wird und die Datenstroeme zum Router sendet, und der die dann ans LAN weiterleitet.

Das wird die Fritze sicher richtig machen. Ob ein UGS sowas, gerade passend fuer Telekom richtig macht, weiss ich nicht.

Aber mit der Funktion alleine wird das Multicast dann auf alle ethernetports und im WiFi an alle WiFi clients weitergeleitet. Quasi wie ein Broadcast. Bloss wenn Du am Router mehrere LANs einstellen kannst dann wuerde das vom Router auf das LAN begrenzt von dem die Anfrafge kommt. Weiss garnicht, ob man bei der Fritze mehr als 2 LANs machen kann. Normales und Gast-LAN.

2. IGMP Snooping. Das ist dann eine Funktion, die Verteilung des multicast im LAN auf nur die ports/geraete zu beschraenken, die das multicast auch angefragt haben. Bei ethernet ports ist das noch relativ einfach, und die meisten ethernet switches haben dieses IGMP Snooping drin, auch fuer IGMPv3. Die koennen ja kontrollieren, auf welche Ports die jeweils Multicast Pakete replizieren. Ist aber bei >= 100 Mbps Ports gar nicht mehr so schlimm, wenn da mal Multicast irgendwo ankommt, wo es nicht gebraucht wird. Vor allem, weil diese Pakete bei einem rechner mit Ethernet-Port auch gar nicht bis zur CPU gehen, sondern direkt im ethernetchip gefiltert werden.

3. multicast->unicast: Bei WiFi sieht es halt anders aus. Da gibt es halt noch alte Geraete, die halt nicht >= 150 Bps WiFI haben, sondern vielleicht nur 802.1b/g, und die koennen sich evtl. an Multicastpaketen stoeren, die sie nicht wollen, weil die vielleicht auch nicht vom WiFi chip selbst richtig gefiltert werden. Ausserdem haben multicast pakete auf dem wifi auch das fundamentale problem, das so ein wifi access point so ein paket nicht erneut uebertragen kann, wenn es in der luft verloren geht. das machen wifi access points nur bei unicast-paketen. Und die "normale" loesung, die aber nicht standardisiert ist, ist dann, das access points multicast pakte in unicast pakete umwandeln - womit die die nicht nur im Verlust fall nochmal uebertragen koennen, sondern halt auch direkt nur zu den gewuenschten empfaengern schicken koennen. Und klar: wenn dann da 5 notebooks ARD schauen, dann kommt da am AP nur ein multicast paket an, es werden aber 5 unicast pakete rausgeschickt. Aber welches von den konsumergeraeten diese Funktion hat, weiss ich nicht. Gibts vor allem halt bei Profigeraeten (Aruba, Cisco, etc. pp).

Zitat von buers

... wieso erwartest du, dass der Stream nicht ankommt? Ich bin zufrieden damit, dass er ankommt

..nicht ankommt auf Geraeten, die den Stream nicht angefordert haben.

Zitat von buers

Ich denke nicht, dass mein derzeitiger Router die Pakete an alle Geräte, die an der gleiche SSID registriert sind, schickt. Das würde mein betagter Router nicht mitmachen. Während des Tests (hatte während ich den Beitrag schrieb vielleicht 10 Minuten die Streams an 2 Geräten mit WLAN laufen) gab es keine offensichtliche Störung. Gleichzeitig waren das Iphone und das IPad meiner Frau und der MagentaTV Stick an der selben SSID (5 GHz Band).

Jo, da gehe ich auch davon aus, das der alte router da die 8 Mbps genau einmal als Multicast ins WLAN schickt, und all die Geraete diese 8 Mbps sehen. Und nachdem das alles relativ aktuelle Geraete sind, werden die wifi chips die pakete sicherlich direkt filtern, so das du wahrscheinlich schwierigkeiten haettest ueberhaupt zu diagnostizieren, ob die Pakete empfangen und weggeschmissen wurden.

Wenn ueberhaupt, dann macht bei so modernen Geraeten, Multicast vor allem Probleme, indem es den gesamtdurchsatz senken kann. Sagen wir mal, du haettest normalerweise 200 Mbps Kanalrate, aber das Multicast wird mit einer Kanalrate von 20 Mbps geschickt, dann hast Du da effektiv einen Einbruch um einen Faktor 10. Den koennte man auch messen wenn man da gleichzeitig was anderes schickt.

Zitat von buers

Hmm. Die Multicast SSM Streams basieren auf UDP mit rtp Protokoll. Ich würde da nicht erwarten, dass da was automatisch erneut übertragen wird, wenn es verloren geht - weder im LAN noch im WLAN. Und das ist auch gut so

Es geht um retransmission von L2 wifi paketen vom access-point zum wifi-client. Das ist mehr oder weniger die wichtigste Funktion von Wifi, warum das WiFi ueberhaupt halbwegs als zuverlaessig angesehen wird vom Kunden. Das ist IMMER aktiv fuer ALLE wifi unicast pakete. Wenn Du das auch nur einmal ausschalten wuerdest waerst Du entsetzt darueber wieviele WiFi Pakete wirklich verloren gehen.

Zitat von buers

(Entgegen weitläufiger Meinung ist das grade bei Live-Streaming ein großer Vorteil von UDP vs. TCP. Die Clients wissen auch, wie sie mit der Lücke umgehen sollen. Man kann das auch leicht an der altbackenen TCP Übertragungsweise der puren Transport-Streams von Enigma2 Boxen erkennen: die hängt oft der Stream dauerhaft nach dem ersten fehlerhaften Bit).

Naja, Auf den Magenta Set Top Boxen sollte es auch immer noch RTP retransmission requirest geben, wenn da mal Pakete verloren gehen. Und das fast-channel-change fuer die Multicastkanaele arbeitet auch uebre diese RTP retransmission. Aber im Prinzip stimmt natuerlich das man end-to-end retransmissions bei realzeitstreamen vermeiden will, weil die zuviel Latenz erzeugen. Deswegen ist ja gerade die lokale retransmission im wifi so wichtig.

Solche RTP Profiloesungen kannste nicht mit der handbackenen Moppelkotze von einer Enigma vergleichen. Da haben sicherlich keine Entwickler jahre damit verbracht, die TCP Uebertragung absturzfest gegen Fehler zu machen. Zum grossen Teil sicherlich auch ein Problem davon, das die einfach das TCP vom Linux Kernel nehmen. Wuerde mal wetten, das das mit einem userland BBR von Google oder so besser laufen wuerde. Aber ja, genau solche Probleme machen mir ja auch solche Enigm Loesungen eher problematisch.

Zitat von buers

Die Repeater (zumindest wenn in normalem Repeater-Modus betrieben) kosten zweifellos Bandbreite und Latenz, viel mehr als Access-Points. Liegt halt daran, dass Sie über den Äther zusätzlich zum direkten Empfangsweg jedes Paket einmal empfangen und einmal senden müssen.
In meinem Usecase im 2,4 GHz Band (sehr moderate Datenraten von IoT-Geräten) spielt übrigens Bandbreite und Latenz keine signifikante Rolle.

Wuerde mal gucken, ob man inzwischen solche Fritz Repeater auch als Mesh aufbauen kann mit Ethernet uplinks zum router. Wenn man denn halt mehr als einen access point braucht. Wireless uplink sollte man auf jeden fall nicht machen, wenn man es vermeiden kann (IMHO).

Zitat von buers

Danke, wieder was gelernt, insbesondere zu WiFi Retransmission.

Habe selbst Programm geschrieben zum Aufnehmen der SSM-Multicast-Streams. Ich bin in 24 h Test nicht ein Mal auf ein fehlendes Paket gestoßen (das man an der rtp Sequence Number erkennen würde).

Leg doch mal auf einen github. Rein schon aus prinzip.

Ich schlage mich ja mir verlorenen Paketen von meiner DD PCIe DVB-S2 Karte rum. Muss endlich mal Linux kernel updaten und hoffen das das da weniger auftritt *seufz*. Keine Retransmissions vom Astra satelliten.

Zitat von buers

Ja. Gestern beim Testen mit meinen Smart-Plugs (und der Problematik mit dem überschrittenen Maximum der WLAN-Geräte) habe ich Router leichtfertig rebootet, während meine Frau Netflix schaute auf FireTV Stick. Wollte mich entschuldigen. Was soll ich sagen - absolut kein Ausfall des Netflix Streams.

Naja, bei HLSstreaming mit ca. 20 sekunden verzoegerung usw. (netflix und alle anderen streamer) ist das eine komplett andere Herausforderung das zuverlaessig zu machen, als wenn man versucht einen fixed-resolution stream vom satelliten oder so moeglichst ohne latenz ueber TCP weiterzuleiten. Auf der anderen Seite arbeiten bei Netflix ja auch Top Protokollentwickler, teilweise mit Jahrzehnten Erfahrung.

Angeblich macht AppleTV+ noch am besten low-latency streaming, bin deswegen ja immer noch versucht mal eine Apple TV Kiste zu kaufen, bloss um das mal zu sehen.

Zitat von buers

Liegt aber bei dem E2 Streaming nicht nur an der Programmierung sondern auch an dem fehlenden Protokoll meines Erachtens (wird halt, wie bei DVB über Äther, der pure Transportstream übertragen. Redundanz/Fehlerkorrektur/Fehlerdetektion von DVB wird allerdings weggelassen.

Wobei die Fehlerkorrektur im TS wohl eher fuer Bitfehler, aber icht fuer Paketverluste geeignet sind, dafuer wurde das ja nie gemacht. Aber das Verklemmen, was Du beobachtet hast ist sicher bloss popelige implementierung von schreiben der DVB Daten in den TCP socket und dann blockiert sich das, wenn mal was schiefgeht und die App merkt nicht, das sie schon ewig hinterher ist, und erstmal einen Sack Pakete lieber wegschmeissen, statt senden sollte.

Zitat von buers

Aufsetzpunkte wie bei HLS durch die Segmente gibt es nicht. UDP ist meines Erachtens gute Einschränkung und Übung für Programmierer - da muss man halt mit fehlenden Paketen rechnen und von vorne herein robuster programmieren).

Naja, die Marktkapitalisierung der Firmen, die HLS machen, gegenueber denen, die RTP machen spricht leider eine klare Sprache. Wobei halt RTCweb auch schon ein interessanter, bloss bei weitem nicht so ertragsreicher Markt ist.

Zitat von buers

Die Aussage, dass es Humbug ist, ist etwas despektierlich gegenüber demjenigen, der die Frage stellt

Nicht despektierlich, irgendwann sind aber halt die Grenzen erreicht - Dann lohnen sich halt Lösungen wie KNX oder Loxone. Gerade in diesem Fall würd ich Geräte mit Mesh Funktion verwenden - denn dazu gehört auch das umsteuern auf einen anderen AP.
Und noch etwas: Nutz eine eigene SSID fürs IoT Netz

Als Mesh ja. Diese quadratischen sind ja als Upgrade für Meh gebaut worden.
Funktioniert bei mir sehr gut.
Was nun ein Ethernet Uplink zum Router ist, frag ich erst gar nicht.

@don

downlink: wifi oder ethernet verbindung nach "unten",
also im einfachsten fall zu den benutzergeraeten im haus.
'uplink' => wifi oder ethernet verbindung zum router

gerade mal bei avm.de gelesen, die repeater haben einen ethernet port, und den kann man als uplink konfigurieren, so das man den repeater dann halt per ethernet mit dem router verbinden kann. Wenn das kabeltechnisch machbar ist, ist das die stabilste loesung. Da wird der repeater dann zum access-point, und die 'mesh' funktion ist dann vor allem, das man sich nicht weiter um die config der kiste kuemmern muss, und das router und repeater untereinander verhandeln wer sich denn um welches benutzergeraet kuemmert.

das wichtigste am mesh ist, das es dich halt an einen hersteller bindet, weil man da nicht mischen kann. Muss man sich also entscheiden, ob man AVM oder Ubiquity Sklave werden will.

(Verkaeufer: Sprechen Sie mal "Ubiquity" aus..... Ah, ok. Danke. Wir empfehlen AVM).

Ich finde die AVM repeater nicht so toll vom formfaktor. Bei mir kleben solche teile unter der Decke, nicht in Steckdose, aber immerhin haben die damit auch ein gutes funktionales unterscheidungsmerkmal.

Die Speedports laufen. Haben halt nur fast keine "coolen Features".
Bei Anruf oder auch nur bei verpaßtem Anruf eine email bekommen geht zB nicht.
Nur bei Einträgen auf dem AB.
Aber das WLAN und auch Telefonie mit dem internen DECT laufen.
Dann ist aber wiederum das Telefonbuch total lahm. Also so richtig nervig lahm.

Irgendwas ist ja immer.

(bei mir ist es ein Speedport Hybrid)