Hinweis:
Dieser Inhalt wurde für MagentaTV 2.0 erstellt und ist möglicherweise nicht für MagentaTV gültig.
Wie finde ich heraus, welches MagentaTV ich nutze?Magenta TV Stick (2. Generation) - DHCP fallback IPv4 192.168.178.x mit FritzBox
vor einem Tag
In einem separaten Test zieht sich der TVstick/Gen2 mit DHCP für alle privaten Netze (Klasse A,B,C) eine dyn.IPv4 korrekt, wenn die FritzBox als Router sowohl das WLAN aufspannt und der DHCP-Dienst einen DHCPOFFER anbieten kann.
In privaten Netzen verwendbare Adressbereiche sind:
Klasse A: 10.0.0.0 bis 10.255.255.255.
Klasse B: 172.16.0.0 bis 172.31.255.255.
Klasse C: 192.168.0.0 bis 192.168.255.255.
PROBLEM / FEHLER:
Der MagentaTVstick erhält keine dynamische IPv4/DHCP, wenn der Router / die FritzBox (7490_07.60) mit DHCP so konfiguriert ist, dass für den Magenta-TVstick keine IPv4 reserviert ist bzw. vergeben werden kann. An der FritzBox ist der DHCP-Dienst nur aktiv, um das Netz für den Router zu bestimmen. Alle relevanten DHCPOFFER kommen von einem zweiten DHCP-Dienst im LAN, z.B. einem pi-hole.
Die Situation:
An einer (weiteren) FritzBox mit WLAN im IP-Client-Modus (Accesspoint) zieht sich der MagentaTVstick die dyn.IPv4 über DHCP nicht vom zweiten / zusätzlichen DHCP-Dienst, der auf einem pi-hole läuft.
Vermutlich hat der Stick in der Firmware einen Fehler im DHCP-Handshake (Discover, Offer, Request, Acknowledge) oder ein sehr kurzes Timing. Offensichtlich fällt "during SELECTING state" mit "multiple DHCPOFFER" der TVstick/Firmware die falsche (nicht die beste) Entscheidung. Sofern überhaupt berücksichtigt wurde, dass DHCPDISCOVER auf Layer 2 bei allen DHCP-Diensten im LAN ankommen muss, um dann entweder positiv oder gar nicht beantwortet zu werden.
Clients send DHCPREQUEST messages as follows:
o DHCPREQUEST generated during SELECTING state:
"Note that the client may choose to collect several DHCPOFFER
messages and select the "best" offer. The client indicates its
selection by identifying the offering server in the DHCPREQUEST
message. If the client receives no acceptable offers, the client
may choose to try another DHCPDISCOVER message." page 30, RFC 2131
"When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator." page 26, RFC 2131
"It is important for all DHCP servers to return the same
parameters (with the possible exception of a newly allocated network
address) to ensure predictable client behavior regardless of which
server the client selects." page 28, RFC 2131
"The server MAY choose to return the 'vendor class identifier' used to
determine the parameters in the DHCPOFFER message to assist the
client in selecting which DHCPOFFER to accept." page 29, RFC 2131
Jedenfalls bastelt sich die TVstick-Firmware (für das ausgewählte WLAN mit korrektem Passwort) aus dem "refuse to allocate an address to a particular client even though free addresses are available" der FritzBox anhand der "vendor ci" eine "falsche" fallback IPv4 192.168.178.x , anstatt "die beste (weil einzige) DHCPOFFER" als DHCPREQUEST auszuwählen, um ein DHCPACK zu erhalten.
Mit der fallback-IP 192.168.178.26 bekommt der TVStick zwar eine WLAN Verbindung, funktioniert aber nicht im LAN, einem 21-er Klasse A Netz, also "kein Internet" "kein TV". Mit allen anderen Geräten, wie PS2, Xbox, handys, tablets, PC's, funktioniert diese LAN-Konfiguration völlig problemlos. Immer kommt die zugeordnete IPv4 für eine WLAN-Verbindung mit bekanntem WLAN-Interface (der hardware MAC-Adresse) korrekt und standardkonform vom zweiten DHCP-Dienst/pi-hole.
"predictable client behavior regardless of which server the client selects" (https://datatracker.ietf.org/doc/html/rfc2131)
Mein "würg around", die korrekte IPv4 wird statisch/fest eintragen, mit 10.0.x.y/21 Gateway 10.0.0.1, und funktionierte auch erst mit den Standardvorgaben für die DNS-Server: 8.8.8.8 und 8.8.4.4, beidemale Google. Im LAN wird dieser Dienst von der FritzBox bzw. von pi-hole bedient und per DHCP verteilt. Mit statischer IPv4/21, Gateway und (nur mit) Google als DNS-Dienst steht jetzt die Internetverbindung mit TV. Der Stick hat die aktuellste Firmware beim anschließenden Updateversuch gemeldet, siehe Anhang.
71
5
Das könnte Ihnen auch weiterhelfen
in
560
0
6
vor einem Jahr
in
358
0
4
in
392
0
5
in
2022
0
8
in
460
0
3
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen TV-Angebote.
vor einem Tag
Einfach nicht das gesamte Heimnetz mit Comsumer HW zerfriemeln wollen.
Problem gelöst.
Das ich echt mal jemanden sehe, welcher die DHCP Funktion im PiHole nutzt. 😅
3
Antwort
von
vor einem Tag
Was hat Consumer HW mit einem technischen Problem "nicht standardkonform" zu tun? off topic? Eine Bastellösung wie pi-hole ist ebenfalls Consumer. Das war jetzt off topic. Zurück zum Thema: Es geht um nicht standardkonformes Verhalten eines Produkts als DHCP-Clients auf Layer 2 von einem großen dt. Consumer Konzern. Werde mir wohl mal einen FireTVstick besorgen. Vielleicht funktioniert internationale ConsumerHW besser?
Antwort
von
vor einem Tag
Die HW ist darauf ausgelegt, dass du ein klassisches Heimnetz mit einem DHCP Server hast.
Wenn du 2 Stück betreibst, isses halt einfach dein eigenes Problem.
Und die kleine Anmerkung am Ende war darauf bezogen, dass es eigentlich keinen Grund gibt, dass PiHole DHCP spielen zu lassen.
Das PiHole selbst kannst du per DHCP als DNS an die Clients verteilen lassen.
Funktioniert top.
Wenn es dir evtl. um die IPv6 Adressen geht, die du dann regelmäßig wechselnd im PiHole reinbekommst:
Einfach den DHCPv6 in der Fritz!Box deaktivieren und die Clients sich per SLAAC selbst die Adressen besorgen lassen.
Die nutzen dann zur DNS Anfrage die IPv4 Verbindung zum PiHole und nutzen die ggf. erhaltenen AAAA-Records dann um die Ziele per IPv6 zu erreichen.
Antwort
von
vor 5 Stunden
Und die kleine Anmerkung am Ende war darauf bezogen, dass es eigentlich keinen Grund gibt, dass PiHole DHCP spielen zu lassen.
Die HW ist darauf ausgelegt, dass du ein klassisches Heimnetz mit einem DHCP Server hast.
Wenn du 2 Stück betreibst, isses halt einfach dein eigenes Problem.
Und die kleine Anmerkung am Ende war darauf bezogen, dass es eigentlich keinen Grund gibt, dass PiHole DHCP spielen zu lassen.
Das PiHole selbst kannst du per DHCP als DNS an die Clients verteilen lassen.
Funktioniert top.
Wenn es dir evtl. um die IPv6 Adressen geht, die du dann regelmäßig wechselnd im PiHole reinbekommst:
Einfach den DHCPv6 in der Fritz!Box deaktivieren und die Clients sich per SLAAC selbst die Adressen besorgen lassen.
Die nutzen dann zur DNS Anfrage die IPv4 Verbindung zum PiHole und nutzen die ggf. erhaltenen AAAA-Records dann um die Ziele per IPv6 zu erreichen.
Es gibt mind. einen guten Grund (für mich) der FritzBox (als Router) den DHCP-Dienst zu entziehen (und ggfs. noch weitere Dienste wie DNS, ntp, usw.). Bei deiner Lösung (die schon einmal gelaufen ist) nervt auch die langsame GUI auf der FB , wenn man die Buchhaltung der festen statischen Zuordnung von MAC-Adresse und IPv4-Adresse für ca. 80 Clients durchführt. Das Grauen ist z.B. mit einer FB 4050_08.xx zwar schneller, aber in summa nicht besser. Die Produktpolitik von AVM weißt unzweifelhaft in eine Richtung. Produkte als Consumer-HW sind nicht minderwertig, die Zielgruppe ist eben der DAU. Im pi-hole ist das zackig mit einer Zeile erledigt: fc:d5:d9:ab:cd:de,10.0.6.135,6-135-NameVorname-MagentaTVstick-FCD5-D9AB-CDDE
Recht hast du damit: Je größer "das klassische Heimnetz" wird, umso wichtiger wird die altbekannte Aussage:
"Ein Router ist ein Router - zum WAN." und folgerichtig
"Das LAN (und WLAN) wird eigenständig administriert, z.B. mit separater Hardware."
Ich fordere "standardkonformes Verhalten" für Consumer-HW. Ist das unlauter oder etwas besonderes? Der Fehler ist ausreichend beschrieben, kann reproduziert werden und vom Hersteller des Consumer-Produkts in einem Update der Firmware behoben werden.
Nachtrag: In dieser Netzstruktur laufen bereits knapp eine handvoll FireTVsticks völlig problemlos.
Wer kann das (falsche) Verhalten des MagentaTVstick als DHCP-Client bei multiple DHCPOFFER bestätigen?
Du forderst eine Einschränkung für das klassische Heimnetz "nur ein DHCP-Dienst". In welchem Standard kann man das nachlesen?
Dann wäre eine mögliche Lösung (würg around?): Im Router/FritzBox den DHCP-Dienst zu deaktivieren. Wird im FritzBox-Router der DHCP-Dienst deaktiviert, dann wird eine statische Route benötigt, weil der FB -Router "sein Netz / LAN" nicht mehr kennt, welches er mit dem WAN verbinden soll. Das wäre kein "zerfriemeln", sondern ein sauber strukturiertes Heimnetz und der Router wäre ein Router (eine FritzBox).
IPv6 ist derzeit (noch) kein Thema, deshalb vielen Dank für den Hinweis im Voraus.
Uneingeloggter Nutzer
Antwort
von
vor einem Tag
Hallo @Ldwg2002 👋
ja, das mit mehren DHCP Server\Fallback und RFC (Empfehlungen) ist so eine Sache im allgemein wo ich auch öfter kämpfe.
Habe leider dafür keine Lösung parat 🤷
Aber unabhängig von diesem Problem☝️ in deinem Foto ist mir das "COMPILED_WITH_PROFILE_NON_MATCHING" ins
Auge gestochen, was zu Geschwindigkeitseinbußen, etc. im Launcher führen kann.
Mit Cache und Daten löschen in der MagentaTV: TV & Streaming unter "Einstellungen -> Systemeinstellungen -> Apps"
kann man das lösen. Nach der Löschung kommt die System Optimierung erneut und danach bitte einmal die
MagentaTV Einstellungen prüfen.
--
Cu
Chris
0
Uneingeloggter Nutzer
Frage
von