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.

    Plex Server@64TB + Kodi ( Homatics Box R 4K Plus @ CoreElec )

  • Ok. Sagen wir mal Du hast zwei Notebooks auf der selben SSID. Auf einem Notebook guckst Du mit Kodi 19 ueber IGMPv3 TV. Hast Du da mal kontrolliert, das da beim zweiten Notebook der Multicaststream NICHT ankommt ?

    Verstehe nicht, wie du das meinst. Habe grade nur 1 Notebook für diesen Test (Dienst-Geräte gehen da nicht ...). Mit Handy und VLC DasErste HD über rtp Multicast-SSM Stream am laufen, auf Notebook läuft der identische Stream auch, egal ob ich es mit Kabel verbunden habe oder mit dem selben WLAN-Band/SSID. Gerade nochmal probiert. Wieso soll das nicht gehen? Der Gag an der Sache ist, dass der Stream nur einmal bei mir zu Hause am Router ankommt durch die Multicast-Technologie (auch ohne dass da Cache/Proxy-Funktionalität ist). Und der eigentliche Vorteil ist, dass der Stream auch nur einmal an den grauen Kasten vor dem Haus übertragen werden muss, wenn alle Nachbarn mit Magenta TV um 20:00 die Tagesschau anschalten.

    ein fettest Notebook mit AC WiFi stoeren die 6Mbps von ARD HD ja nicht)

    Sind übrigens gut 8 Mbit/s (für alle ÖR HD Sender).

    Einfach, weil Router meistens ja nah am WAN stehen muss

    Ist bei mir jetzt nicht relevant. Glasfaser kommt in Sicherungskasten an. Dort steht auch das Fiber-Modem. Der eigentliche WLAN-Router kann dann dorthin, wo ich will (kann ich über Patchfeld da hinleiten).

    Kodi 21.0, 17.6, 20.5, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

  • 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).

  • @te36, alles gut erklärt, nur ...

    Hast Du da mal kontrolliert, das da beim zweiten Notebook der Multicaststream NICHT ankommt ?

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

    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). Nach meiner Erfahrung würde 5 Mal 8 Mbit/s nicht störungsfrei funktionieren. Ich denke, das wird auch im WLnur an die Geräte geschickt, die sich für den SSM Stream registriert haben.

    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.

    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 :) (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).

    Im Endeffekt wird dich jedes zusätzliche WLAN Gerät Latenz kosten da immer auf einen freien Sendeslot gewartet wird.
    [...] Nutze 2 AVM Fritz Repeater

    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.

    Kodi 21.0, 17.6, 20.5, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

  • ... 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.

    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.


    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.


    (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.


    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).

  • 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).

    Wuerde mal wetten, das das mit einem userland BBR von Google oder so besser laufen wuerde.

    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. 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, 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).

    Kodi 21.0, 17.6, 20.5, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

  • 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.


    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.


    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.


    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.

  • 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 :)

    --------------
    Guides nicht mehr verfügbar wegen Youtube unvermögen guten von schlechten Kodi Videos zu unterscheiden.

  • Wuerde mal gucken, ob man inzwischen solche Fritz Repeater auch als Mesh aufbauen kann mit Ethernet uplinks zum router

    Ich bin der Meinung, dass das mittlerweile gehen sollte. 100% sicher bin ich mir aber nicht

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • @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). [ag]

    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.

  • Besten Dank für alle Antworten und Hinweise. Entscheidung fiel letztlich doch auf Speedport Smart 4. Ausschlaggebend: Maximale Anzahl WLAN Geräte dokumentiert, hervorragende Messwerte im connect Vergleichstest (Telekom Speedport Smart 4 im Test - connect), z.B.: bessere Messwerte als das viel teurere Fritz-Gerät, günstiger Preis (kriegt man z.Z. für 120 €) und vermutete beste Kompatibilität/leichteste Konfigurierung an Telekom Anschluss / mit Magenta TV.

    Das empfohlene ASUS Gerät DSL-AC68VG kriegt man nur klein wenig günstiger, ist aber von der Technik etwas älter (Wifi 5 vs. Wifi 6).
    Fritzbox 7590 AX habe ich mir auch angesehen. Doppelt so teuer, Vorteil: ich vermutete, dass mein Telefon Problem machen kann ohne ISDN (nach Meldungen im Telekom-Forum). Hat sonst wohl auch etwas mehr an Ausstattung.

    Telefon bekam ich mit Anruf und Hinweis der Telekom Hotline direkt mit VOIP konfiguriert.
    WLAN-Leistung ist viel besser als erwartet: Überall in großer Wohnung mehr als ausreichender Empfang. Z.B. 2 Wände vom Router entfernt kriege ich volle Internet-Leistung (550 Mbit/s Download, 125 Mbit/s Upload, formal spezifiziert sind 500/100). Zum Fileserver kriege ich 105 MByte/s beim Kopieren großer Datei im Schnitt, nicht unter 50 MByte/s gefallen. Das ist im Prinzip nahe der Grenze des Kabels zum Router vom Switch an dem der Fileserver hängt. Gegenrichtung 75 MByte/s, Einbruch nicht unter 40 MByte/s.

    Einrichtung des Routers selbst war praktisch vollautomatisch. Habe dann noch in 2 SSIDs getrennt für 2,4 und 5 GHz Band, die alten Namen und PW konfiguriert und DHCP/Subnetz konfiguriert wie am alten Router - fertig. Telefon war bisschen trickreicher. Ist kombiniertes VOIP/ISDN Telefon Gigaset DX800A. Lief immer im ISDN-Modus. Für VOIP-Modus musste man einiges eintragen, Benutzername musste man die Haupt-Telefonnummer eintragen (das war mir ohne Hilfe nicht klar).

    Kodi 21.0, 17.6, 20.5, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

  • 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)

  • Telefonie direkt im Gerät nutze ich nicht und brauche ich nicht - daher nicht so wichtig für meinen Use-Case. Sicherlich interessante Info für weitere Interessenten. Mein DX8000A Bürotelefon dient als DECT-Basis für Siemens/Gigaset Mobilteile (denke da ist noch bisschen mehr Funktionalität als bei Standard DECT. Spielt aber bei zunehmender Benutzung von Telefonie im beruflichen Umfeld über Teams, Webex, Goto-Meeting für viele eine abnehmende Rolle gute klassische Telefonie-Funktionalität).

    Weil auch Latenz/Unbrauchbarkeit bei vielen WLAN Geräten diskutiert wurde. 24 h-Test, 19 IoT Geräte jedes im 5 Sekunden-Takt im 2,4 GHz Band ausgelesen. Funktionierte einwandfrei. Connect-Zeit zu den Webservern (die kein Keep-Alive können, daher jeder Aufruf neuer Connect) ca. 10-20 ms, mit etwas Streuung. Übertragungszeit (inkl. Anforderung der Daten) der Statusdaten ca. 100 ms. Aber da ist sicherlich nicht das Netzwerk limitierend, sondern Verarbeitungszeit des Webservers, der ja auf wirklich wenig leistungsfähigem Prozessor läuft. Macht aber nix - die Zeiten sind für mich mehr als ausreichend.

    Kodi 21.0, 17.6, 20.5, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!