GB Switch vor TV und IP-Radio -- Empfehlung?

[neandr]

HabNeFritzbox Hättest die IP nicht einfach im Router ablesen können?

Vllt. wäre es möglich gewesen, aber soweit ich mich entsinne hat das FB RouterIF nix verwertbares angezeigt.

Und per vorgegebener Netgear IP hat sich das WEB-IF nicht geöffnet.
Mit W7/CD und nicht FB/CD ging's dann.

Na, bessere Netzwerk Kenntnisse wären ggf. hilfreich gewesen und hätten den Umweg erspart.

- - - Aktualisiert - - -

Du hättest dir eine IP aus dem Netz des Switches geben können, dann geht das auch

Wie gesagt ... Netzwerkkenntnisse
Aber das konnte ich leider nicht hinkriegen. Wenn ich mal viel Zeit habe werde ich den Switch auf Factory Default setzen und nochmal probieren .. wie gesagt ... viel Zeit

 

[qwertz.asdfgh]

... da die auf dem Gehäuse angegebene IP nix mit meinem Netz zu tun hatte.

Deshalb habe ich auch in Beitrag #14 darauf hingewiesen, dass es sich anbietet, diese IP-Adresse beim neuen Gerät (bei Bedarf) entsprechend zu ändern.

Auf meinem Laptop (den ich für die Konfiguration häufig einsetze) läuft ebenfalls eine Linux-Distribution und sowohl mit Windows als auch mit den üblichen Linux-Distributionen ist es überhaupt kein Problem, (vorübergehend) ein passendes Subnetz einzustellen um die Erstkonfiguration durchzuführen.
Auf dem Laptop habe ich dafür im Netzwerk-Manager bereits für alle häufig verwendeten Subnetze bzw. Default IP-Adressen der Geräte passende Profile angelegt um das gewünschte mit 2 Mausklick auswählen zu können denn verständlicherweise passen die Default IP-Adressen von neuen Geräten nicht immer (eher selten) zu einem bereits bestehenden Subnetz.

Und wenn ein DHCP-Client in der Standardkonfiguration des neuen Gerät aktiv ist, man im Netzwerk einen DHCP-Server hat (i.d.R. auf dem Router) und das neue Gerät in das bestehende Netzwerk integriert/angeschlossen hat, kann man die IP-Adresse, wie HNF erwähnte, z.B. beim DHCP-Server (Router) erfragen und bräuchte somit das Subnetz auf dem Rechner nicht (vorübergehend) für das neue Gerät anpassen. Aber wenn ich ehrlich bin habe ich die IP-Adresse des Rechner i.d.R. schneller angepasst als die zugewiesene IP-Adresse beim Router zu erfragen (bei den meisten Geräten kennt man mittlerweile auch die Standard IP und muss nicht immer erst im Handbuch nachschlagen), abgesehen davon, dass man sich dann immer darauf verlassen müsste, dass auf dem neuen Gerät tatsächlich ein DHCP-Client aktiv ist (was nicht immer der Fall ist).

Auch mit direktem Anschluss per Netzwerkkabel konnte ich den Switch nicht ansprechen.

Da ich das genau so immer mache (auch mit Linux) kann ich nicht nachvollziehen warum es so nicht funktionieren sollte, vermutlich hast du wohl nur vergessen passende manuelle IPv4-Einstellungen auf dem entsprechenden Rechner vorzunehmen oder?

Da ich auf Linux bin war die beliegende CD wertlos

Irgendwelche Tools oder zusätzliche Software ist für die Erstkonfiguration nicht notwendig, egal ob z.B. Windows, Linux oder MacOS X.

Und per vorgegebener Netgear IP hat sich das WEB-IF nicht geöffnet.

Das funktioniert ja auch nur, wenn man auf dem Rechner ein zur IP-Adresse passendes Subnetz konfiguriert hat.


BTW:
Der TP-Link Switch ist bereits eingetroffen, werde ihn heute Abend oder morgen mal ausprobieren.

 

[qwertz.asdfgh]

BTW:
Der TP-Link Switch ist bereits eingetroffen, werde ihn heute Abend oder morgen mal ausprobieren.

Bin jetzt mal wieder daran erinnert worden, hier meine Testergebnisse:

Ich hatte einen Netgear GS108Ev3 (Firmware-Version: 2.00.08 vom 11.11.2015?) und einen TP-Link TL-SG108Ev2 (Firmware-Version: 1.02 Rel. 34615 vom 26.05.2016) bzgl. IGMPv3-Snooping (getestet mit Entertain v1 und v2 Multicaststreams incl. SSM) verglichen (Firmware zum Testzeitpunkt vor ein paar Wochen jeweils aktuell lt. jeweiliger Hersteller-Website, für den Netgear gibt es mittlerweile eine aktuellere, Ver. 2.00.09).
Äußerlich ist (von Farbgebung/Beschriftung mal abgesehen) kein Unterschied zu erkennen, auch die Gehäuseabmessungen sind identisch, die unterschiedlichen Angaben in den Datenblättern bzgl. Gehäusehöhe kommen nur daher zustande, da Netgear mit Gummifüßen misst und TP-Link ohne. Die Gummifüße müssen beim TP-Link, im Gegensatz zum Netgear, auch vom Nutzer erst selbst angebracht werden (selbstklebend, beiliegend).

Ein weiterer Unterschied ist, dass der TP-Link ein 9V DC Netzteil verwendet und das Netgear-Modell ein 12V DC Netzteil, mir wäre ein 12V Netzteil lieber da es so einfacher auszutauschen ist (hat man bzw. ich i.d.R. passend "herumliegen"), den normalen/durchschnittlichen Nutzer wird das aber wohl eher weniger interessieren. Die Leistungsaufnahmen sind ebenfalls vergleichbar (maximal ca. 4-5W bei wenn alle 8 GbE-Ports im GbE-Modus betrieben werden und die Kabel auch nicht zu kurz sind, im "Leerlauf" <=2W, bzgl. Energieverbrauch sind also beide Modelle m.E. positiv einzuordnen).

Ansonsten gibt es bzgl. Hardware keine weiteren Unterschiede (bei Gelegenheit schaue ich mal nach aber es würde mich nicht wundern, wenn beide sogar den gleichen Chipsatz verwenden), weitere Unterschiede sind also eher bei der Firmware zu suchen.

Beide Produkte lassen sich mit aktueller Firmware per Webinterface einrichten (bei den Netgear-Modellen erst ab HW-Ver. 2, allerdings ist HW-Ver. 1 schon länger nicht mehr auf dem Markt). Allerdings gibt es sowohl für das Netgear als auch für das TP-Link Modell jeweils vom Hersteller ein separates Tool zum einrichten, diese Tools habe ich allerdings nicht getestet (sind ihmo auch unnötig).

Überrascht war ich davon, dass auch das TP-Link Modell für IGMP-Snooping bereits passend vorkonfiguriert ist, also einfach anschließen und es funktioniert (sowohl beim Netgear als auch beim TP-Link). Hier die werksmäßige Voreinstellung bzgl. IGMP-Snooping beim TP-Link:


Und die des Netgear:


Ansonsten gab es mit beiden Modellen keine Probleme bzgl. IGMPv3-Snooping (jeweils mit den Werkseinstellungen bzgl. IGMP getestet) beim Einsatz von Entertain, auch wenn SSM eingesetzt wurde (Entertain v2), die Multicast-Pakete wurden nur an die jeweiligen Ports weitergeleitet.


Noch ein paar weitere Bemerkungen:

Ich bündel ja Port vom NAS und später wohl auch am PC wenn ich neuen hole mit Team NIC / Trunk wie auch immer, und da sind die Switche ja gleich noch teurer ab 60-200€.

Nicht unbedingt, dbzgl. gibt es beim günstigeren Modell von TP-Link eine kleine Überraschung:

Man kann allerdings auch nur max. 2 Trunk-Gruppen einrichten aber für diese Preisklasse dennoch eine kleine Überraschung.

Bei TP Link musst Snooping doppelt aktivieren, einmal global und einmal für den Port selbst, und noch Angaben welcher der Router Port ist.

Auch das ist nicht korrekt, gilt nur für die "größeren" TP-Link Modelle aber nicht für die günstige TL-SG10x-Serie (s.o.).


Fazit:
Wer einen GbE-Switch i.V.m. Entertain sucht kann durchaus zur TL-SG10x-Serie von TP-Link greifen, ist bzgl. Preis-/Leistung derzeit imo unschlagbar. Die Netgear GS10xE-Reihe bekommt bzgl. Preis-/Leistung einen guten 2. Platz.


PS:
Wer sich mal durch das WebIf (bis auf ein paar grundsätzliche Einstellungen alles Standardeinstellungen) der beiden Modelle "klicken" möchte:
Anhang anzeigen Netgear GS108Ev3.zip
Anhang anzeigen TP-Link TL-SG108Ev2.zip

 

[HabNeFritzbox]

Also bei meinem musste ich es aktivieren.

Der TL-SG108E für 27€ bei Amazon ist wohl neuer, bei meinem ist letzte Firmware schon paar Jahre alt. Aber ist doch gut, wenn aktuelle es aktiv haben.

 

[qwertz.asdfgh]

Früher™ musste man es auch bei den Netgear-Modellen noch separat aktivieren, nicht alles war wohl früher besser...

Ist dein TL-SG108E eigentlich v1 oder v2? Lt. Website gibt es angeblich sogar schon eine v3.

 

[Pom-Fritz!]

@qwertz.asdfgh

Du hast die Flow Control auf "Disable" eingestellt. Ich habe bei meinen beiden Netgear 105Ev2 die Flow Control aktiviert. Was ist die bessere Einstellung für die FritzBox? Port1=FS-Gerät (100MBit/s), Port2=Repeater 1750E (LAN-Brücke), Port3=Laptop, Port4=Frei, Port5=Uplink. Alle Kabel ab Switch CAT6, max. 3 Meter.

Wie du siehst, macht mein Repeater ein paar CRC-Errors. Dieses passiert aber nicht während er viele Daten überträgt, sondern eher in den Ruhephasen. Kann das vielleicht mal jemand gegentesten?

 

[qwertz.asdfgh]

Du hast die Flow Control auf "Disable" eingestellt.

Das ist Werkeinstellung, bis auf Username, Password und die IP-Adresseinstellungen für das WebIf ist bei beiden Modellen alles auf Default-Einstellungen geblieben für den Test/Vergleich und die Screenshots.

Ich habe bei meinen beiden Netgear 105Ev2 die Flow Control aktiviert. Was ist die bessere Einstellung für die FritzBox?

Im Zweifel die Default-Einstellung.

Wie du siehst, macht mein Repeater ein paar CRC-Errors. Dieses passiert aber nicht während er viele Daten überträgt, sondern eher in den Ruhephasen.

Ein paar CRC-Fehler müssen nicht per se unberuhigend sein (Fehlerkorrekturverfahren wurden nicht umsonst erfunden).

Kann das vielleicht mal jemand gegentesten?

Ich nicht, beide Geräte sind bei mir mittlerweile nicht mehr im Einsatz (das war nur für den Vergleichstest), der Netgear erfüllt jetzt in einem anderen Netzwerk seinen Dienst und der TP-Link wurde weggepackt und wartet auf eine zukünftige Aufgabe...

 

[Pom-Fritz!]

Bei mir war die Werkseinstellung bei Switch 1 "Flow Control Enabled" und Switch 2 (V1.4.0.9 der neuere) auf "Disabled". Im Netgear Forum wird "Flow Control Enabled" empfohlen, obwohl die Werkseinstellung "Disabled" ist. Was ist also in welcher Situation die bessere Einstellung? Wer kennt sich aus?

Nach Analyse der Export-Datei der FB glaube ich, dass Flow Control hier nicht unterstützt wird, während IGMP Snooping wohl unterstütz wird.

 

[sertkom]

Z.B. gibt es Geräte im Standby die dann von GbE oder FE auf den 10Mb/s Modus (10Base-T) wechseln (hatte schon solche Fälle wo dies zu Problemen führte i.V.m. Entertain, konnte den Geräten auch nicht abgewöhnt werden außer sie komplett vom Netz zu trennen).

Und wenn der TE dann noch einen (einfachen) WLAN-AP (für 20,- Eur) anschließen möchte geht es wieder von vorne los... Nichts gespart. Zudem die o.g. Beispiel zu den relativ preisgünstigen Modellen zählen die IGMPv3-Snoping unterstützen (das 5-Port Modell gibt es bereits für knapp über 30,- Eur), so viel falsch macht man da also nicht wenn sich da gleich für das passende entscheidet.

Wer also Entertain oder einen vergleichbaren IPTV-Service nutzt oder alsbald nutzen möchte und die Anschaffung eines neuen Ethernetswitches plant sollte also unbedingt darauf achten, dass dieser IGMPv3-Snooping beherrscht um potentiellen Problemen aus dem Weg zu gehen.

Ich kenne dieses Modell (im Gegensatz zu den o.g.) nicht aus dem realen Einsatz. Hatte mal vor längerer Zeit irgendwo gelesen, dass diese Modellreihe von TP-Link zwar IGMP-Snooping unterstützen aber angeblich nur IGMPv2 und nicht IGMPv3 (das war auch der Grund weshalb ich diese Modellreihe von TP-Link nicht mit erwähnt hatte). Kann jemand dazu was genaueres sagen?

Hier hätte ich gerne fundiert erklärt warum Lanseitig "unbedingt" IGMPv3 Snooping erforderlich ist und IGMPv2 nicht ausreicht. An der SSM Adresse kann es ja nicht liegen da diese nur WANseitig gefordert ist. Anmeldung zu Multicastgruppe IGMPv1, Abmeldung von der Multicastgruppe IGMPv2 ist das einzige Erfordernis im LAN und eben das kann von IGMPv2 fähigen Switches problemlos erledigt werden.

 

[qwertz.asdfgh]

Seit Entertain v2 kommen Multicast-Adressen incl. expliziter Quellenangabe (SSM) zum Einsatz, auch LAN-seitig.

An der SSM Adresse kann es ja nicht liegen da diese nur WANseitig gefordert ist.

Bei z.B. einer FritzBox funktionieren die Entertain v2 Multicast-Adressen auch ohne SSM-Erweiterung LAN-seitig, allerdings nicht bei Routern welche von der Telekom supported werden (z.B. Speedports oder Zyxel Speedlinks), hier sind auch LAN-seitig die Multicastadressen incl. SSM-Erweiterung zwingend erforderlich, die Multicast-Adressen ohne SSM-Erweiterung funktionieren dort LAN-seitig schlicht nicht. Die v2 MRs (MR200 und 400) verwenden dementsprechend ausschließlich die Multicast-Adressen incl. SSM-Erweiterung (auch wenn ein anderer Router zum Einsatz kommt).

Eine Begründung/Erklärung meinerseits wirst du dafür nicht bekommen, das kannst du gerne die Telekom direkt fragen, ist schließlich ihre Entscheidung. Fakt ist, IGMPv3 ist erforderlich, ob man es nun einsieht oder nicht.

BTW:
Gibt es eigentlich von dir eine fundierte Erklärung für das Fullquote deinerseits?

 

[sertkom]

Das Fullquote ist für dich ein Problem? Na gut, wenn es für dich so einfacher ist deine Ahnungslosigkeit zu kaschieren, bitte.

Die AVM Kisten haben im übrigen damit erstmal gar nichts zu tun. Dort ist wie in den Speedports ein IGMP-Proxy WANseitig tätig der in der Tat IGMPv3 für entertainTV können muß.
Deine Aussage ist schlicht Unsinn. Ansonsten interessiert kein client im Lan sich für SSM oder auch nicht. Die MR fordern mittels RTP Protokoll als UDP Paket über unicast den multicast von einer mit der SSM spezifizierten Quelle an. Diese SSM ist im übrigen eine öffentliche Adresse, die der swich gar nicht sieht, da er nur den ankommenden Multicast bzw. die join und leave in seine Forwardingtabelle ein und austrägt und damit die Ports bestimmt an denen der multicast geliefert wird..

Da egal ob Schrottbox von AVM oder Müllbox von der Telekom im LAN nur IGMPv2 benötigt wird, andernfalls hätte ich mit meinem Switch der nur IGMPv2 - Snooping kann, ein mit Multicast geflutetes Netz, das ist aber nicht der Fall, auch mit dem Empfang des Programms, gibt es, und hier ist es dann völlig egal ob der switch IGMP snooping fähig ist, keine Probleme.

Deine Weigerung für deine Annahme eine sachlich richtige Begründung zu liefern disqualifiziert dich. Der einzige Grund weshalb du diese Begründung nicht lieferst ist einzig deine Unkenntnis über die von dir besprochenen Materie.

 

[qwertz.asdfgh]

Das Fullquote ist für dich ein Problem?

Wie kommst du darauf?

Na gut, wenn es für dich so einfacher ist deine Ahnungslosigkeit zu kaschieren, bitte.

Wenn du meinst.

Die AVM Kisten haben im übrigen damit erstmal gar nichts zu tun.

Wurde auch nicht behauptet oder stört dich etwas an diesem (Praxis)-Beispiel?

[...] Da egal ob Schrottbox von AVM oder Müllbox von der Telekom im LAN nur IGMPv2 benötigt wird, andernfalls hätte ich mit meinem Switch der nur IGMPv2 - Snooping kann, ein mit Multicast geflutetes Netz, das ist aber nicht der Fall, auch mit dem Empfang des Programms, gibt es, und hier ist es dann völlig egal ob der switch IGMP snooping fähig ist, keine Probleme.

Das mag noch funktionieren, wenn man einen Einfluss auf den verwendeten IGMP-Proxy im Router hat, den hat aber nicht jeder (bzw. will/kann nicht jeder haben). Und wenn der Router intern IGMPv3 verwendet gibt es keine Garantie dafür, dass ein Switch, der nur IGMPv2-Snooping unterstützt, keine Probleme bereitet.

Deine Weigerung für deine Annahme eine sachlich richtige Begründung zu liefern disqualifiziert dich. Der einzige Grund weshalb du diese Begründung nicht lieferst ist einzig deine Unkenntnis über die von dir besprochenen Materie.

Gut, dann werde ich hier wohl nicht mehr benötigt...

 

[sertkom]

Wie kommst du darauf?

Das mag noch funktionieren, wenn man einen Einfluss auf den verwendeten IGMP-Proxy im Router hat, den hat aber nicht jeder (bzw. will/kann nicht jeder haben). Und wenn der Router intern IGMPv3 verwendet gibt es keine Garantie dafür, dass ein Switch, der nur IGMPv2-Snooping unterstützt, keine Probleme bereitet.

Gut, dann werde ich hier wohl nicht mehr benötigt...

Du hast es also immer noch nicht begriffen! Ohne IGMPv3-proxy im Router kein Entertain egal ob Entertain alt, oder Entertain TV, dem Switch ist vollkommen egal ob IGMPv3 oder igmpv2 übertragen wird und auch die Quelle ist ihm schnuppe denn übliche Switche führen keine ACL die bei IGMPv3 Bestandteil ist den Sender auszuwählen. Einzig join und leave des routers im Igmp Protokoll interessiern den Switch.

Also versuche doch nicht durch untaugliche Beiträge deine Unkenntniss zu verschleiern.

 

[qwertz.asdfgh]

Du hast es also immer noch nicht begriffen!

Dito.

1234567890

 

[HabNeFritzbox]

@sertkom Hast du belegbare Quellen für deine Behauptung? Also dass z.B. udpxy zwingend im Router laufen muss, sonst kein IPTV.

Wenn Switch kein igmpv3 kann, geht Multicast an alle Ports, klar geht es, flutet aber auch andere Geräte mit Daten die es nicht brauchen, das macht doch das v3 aus.

qwertz.asdfgh schrieb auch nicht, dass es nicht geht, sondern um "potentiellen Problemen aus dem Weg zu gehen". Aktuelle Geräte haben können auch v3, also eher quatsch wenn es um Neuanschaffung geht alte Geräte zu verwenden die nur v2 können. Selbst gemanagte GBit Switch mit 8 Port gibt es unter 30€, ungemanagte für etwa die Hälfte.

Sehe in FB Support Datei nur Interface und Routing Anweisungen.

Wegen Fullquote siehe Forum Regeln.

 

[sertkom]

Aber natürlich, schaue und verstehe die RFC 2236, rfc4541 und RFC 3376 dort kannst du alles nachlesen.

Erkläre doch mal was genau du mit "udpxy" meinst, mir ist weder ein Protokoll noch ein Dienst solchen Namens bekannt. Falls du UDP meinst, das ist ein verbindungsloses Transportprotokoll, welches alle möglichen Daten transportiert und mit IGMP nichts zu tun hat.

Wenn Switch kein igmpv3 kann, geht Multicast an alle Ports, klar geht es, flutet aber auch andere Geräte mit Daten die es nicht brauchen, das macht doch das v3 aus.

Nicht ganz richtig, Wenn Switch kein "IGMP snooping" kann" muß es heißen.
"...das macht doch das v3 aus." Das ist bul...t


Die Switches von denen hier gesprochen wird können durch die Bank mit dem IGMP Protokoll nichts anfangen, sie arbeiten nicht auf dieser Ebene!

IGMP snooping hat mit dem IGMP Protokoll, zugehörig zur TCP/IP suit, egal ob Version 2 oder 3 nur insoweit zu tun das der Switch, hier die Snooping funktion, den Header des Layer 3 Protokolls analysiert und die Leave, join Information genutzt wird, den Multicast an den anfordernden Port zu leiten. Das IGMP Protokoll ist auf Layer 3 angesiedelt, die Switche die hier besprochen werden agieren alle auf Layer 2.

Sehe in FB Support Datei nur Interface und Routing Anweisungen.

Vielleicht, solltest du geeignetes Material benutzen, den Netzwerkverkehr zu analysieren. Diese Spielekisten sind wohl gänzlich ungeeignet.

 

[unrealzocker]

Erkläre doch mal was genau du mit "udpxy" meinst, mir ist weder ein Protokoll noch ein Dienst solchen Namens bekannt. Falls du UDP meinst, das ist ein verbindungsloses Transportprotokoll, welches alle möglichen Daten transportiert und mit IGMP nichts zu tun hat.

Googlen hilft, aber ich schätze mal dass das hier damit gemeint ist: http://www.udpxy.com/index-en.html

Wegen Fullquote siehe Forum Regeln.

Da braucht man nicht so empfindlich sein. Fullquotes haben schon einen Zweck, natürlich nicht gleich im nächsten Beitrag.

 

[qwertz.asdfgh]

Aber natürlich, schaue und verstehe die RFC 2236, rfc4541 und RFC 3376 dort kannst du alles nachlesen.

Vielleicht könnte man ja über Pkt. 2.2 der RFC 4541 (IGMP Snooping-Related Problems) schwadronieren.

- - - Aktualisiert - - -

BTW:

Da braucht man nicht so empfindlich sein. Fullquotes haben schon einen Zweck, [...]

Muss man mittlerweile eigentlich die Forenregeln beim registrieren im IPPF nicht mehr bestätigen? Ich habe diese nicht erstellt und ich habe auch nicht behauptet, dass ich selbst mit allen Forenregeln 100% einverstanden bin aber ich dachte bisher, ich hätte sie (wenigstens) zu akzeptieren...

 

[unrealzocker]

Muss man mittlerweile eigentlich die Forenregeln beim registrieren im IPPF nicht mehr bestätigen? Ich habe diese nicht erstellt und ich habe auch nicht behauptet, dass ich selbst mit allen Forenregeln 100% einverstanden bin aber ich dachte bisher, ich hätte sie (wenigstens) zu akzeptieren...

Wird zwar leider etwas OT:

Der Fullquote war von einem Beitrag auf einer anderen Seite (20 Posts pro Seite). Es ist sinnvoller wenn man einen Fullquote macht, anstatt nur auf den Post zu verweisen. Zumindest wenn man die meisten Punkte vom Post behandelt, was hier ... eher nicht der Fall war.
Gefühlt stören sich aber immer die gleichen an Fullquotes, egal ob diese sinnvoll oder nicht waren.

 

[Pom-Fritz!]

Ein paar CRC-Fehler müssen nicht per se unberuhigend sein (Fehlerkorrekturverfahren wurden nicht umsonst erfunden).

Das ist richtig. Trotzdem ist es doch merkwürdig, dass die CRC-Fehler nur am Port des Repeaters auftreten (siehe #26). Port und Kabeltausch brachten keine Besserung. Habe deshalb erst mal "Flow Control" auf Disabled (Default) gestellt, was aber auch keine Änderung brachte. Also hab ich mal ein wenig mit den Optionen des Netgear GS105Ev2 gespielt. Und siehe da, wenn ich den "Power Saving Mode" deaktiviere, sind die Fehler verschwunden! Dies ist sicherlich für einige User intersannt. Die "worst case" Leistungsaufnahme des Switch soll ja max. 2,6 Watt betragen, ein Wert den man nicht unbedingt durch Power Management weiter reduzieren muss.

Dieser Fehler soll auch beim Fritz Repeater-450E im Zusammenhang mit Netgear Switche auftreten.