Der DHCPv6 Server der Kabelbox CH7485E verhält sich offenbar nicht so wie er es nach RFC 3315 tun sollte.
https://bugzilla.redhat.com/show_bug.cgi?id=1334050
Ich habe im Communityforum von Red Hat ein Ticket geöffnet. Allerdings liegt es an der Box oder genauer gesagt der Firmware.
Hat jemand ähnliche Probleme oder kennt eine Lösung dafür?
Meine Firmwareversion ist CH7485E-5.510.5.7-NOSH.
CH7485E Kabelbox: DHCPv6 server broken
Anzeige zu CH7485E Kabelbox: DHCPv6 server broken
von PŸUR »
Hallo fansari, schau doch mal ob du bei
PŸUR Internet
oder
Gigabit Internet
fündig wirst.
Re: CH7485E Kabelbox: DHCPv6 server broken
Wie macht sich das Problem denn bemerkbar? Ich habe bisher mit verschiedenen Linux-Distributionen und verschiedenen Windows-Versionen keine Probleme bemerkt. DHCPv6 steht auch auf stateless.
Der DHCPv6 ist wahrscheinlich notwendig, weil ältere Clients sonst keinen DNS-Server mitgeteilt bekommen (ich habe da vor allem Windows 7 in Verdacht, weil der DNS-Server erst seit 2010 in den Router-Advertisements offiziell unterstützt wird - und Windows 7 ist von 2009). Android hingegen ignoriert DHCPv6, weil der zuständige Programmierer bei Google sich dafür entschieden hat
Das mitteilen eines DNS-Servers ist aber momentan auch vernachlässigbar, da nahezu ausnahmslos alle Clients auch eine IPv4 beziehen und die Auflösung von IPv6 auch über diesen möglich ist. Allerdings habe ich bei Linux beobachtet, dass bei verschiedenen NICs für v4 und v6 Adressen möglicherweise nur nach v4 aufgelöst werden, bzw. ein Fallback von v6 auf v4 stattfindet, weil die für die Auflösung über IPv4 verwendete NIC kein v6 kann. Aber dieses Verhalten bei der Namensauflösung habe ich nicht weiter untersucht und es bleibt eine Vermutung.
Der DHCPv6 ist wahrscheinlich notwendig, weil ältere Clients sonst keinen DNS-Server mitgeteilt bekommen (ich habe da vor allem Windows 7 in Verdacht, weil der DNS-Server erst seit 2010 in den Router-Advertisements offiziell unterstützt wird - und Windows 7 ist von 2009). Android hingegen ignoriert DHCPv6, weil der zuständige Programmierer bei Google sich dafür entschieden hat
Das mitteilen eines DNS-Servers ist aber momentan auch vernachlässigbar, da nahezu ausnahmslos alle Clients auch eine IPv4 beziehen und die Auflösung von IPv6 auch über diesen möglich ist. Allerdings habe ich bei Linux beobachtet, dass bei verschiedenen NICs für v4 und v6 Adressen möglicherweise nur nach v4 aufgelöst werden, bzw. ein Fallback von v6 auf v4 stattfindet, weil die für die Auflösung über IPv4 verwendete NIC kein v6 kann. Aber dieses Verhalten bei der Namensauflösung habe ich nicht weiter untersucht und es bleibt eine Vermutung.Re: CH7485E Kabelbox: DHCPv6 server broken
Die Frage ist, was du unter "bemerkbar" verstehst. Um es gleich zu sagen: nein, es führt nicht dazu, dass das Netzwerk nach dem Bootvorgang nicht richtig konfiguriert ist. Das Advertising funktioniert offenbar, denn der Präfix wird zugewiesen (das Interface ist nicht statisch konfiguriert), eine Default Route wird gesetzt (DNS braucht nicht konfiguriert zu werden, da ich bind laufen lasse).
Wenn ich allerdings jedesmal beim Booten eine Fehlermeldung vom NetworkManager bkomme und dann in den Logfiles einen Timeout nach 45s sehe, dann nervt mich das irgendwann und veranlasst mich der Sache nachzugehen.
Wenn dann rauskommt, dass ich auch mit Configänderungen nichts dagegen tun kann, sondern dass sich da so ein blöder Router nicht an die RFC 3315 hält - wogegen ich auch nichts machen kann - dann ist das schon frustierend.
Die einfachste Lösung wäre für mich, wenn ich am Router das DHCPv6 einfach abschalten könnte. Keine Ahnung warum nicht wenigstens das geht.
Diese Firmware sollte drignend mal überarbeitet werden. Das ist jetzt das zweite Problem, das ich feststelle (das erste hatte ich ja schon gepostet: schaltet man die IPv6 Firewall an, geht gar kein IPv6 Traffic mehr - auch nicht raus. Sehr sinnvoll).
Wenn ich allerdings jedesmal beim Booten eine Fehlermeldung vom NetworkManager bkomme und dann in den Logfiles einen Timeout nach 45s sehe, dann nervt mich das irgendwann und veranlasst mich der Sache nachzugehen.
Wenn dann rauskommt, dass ich auch mit Configänderungen nichts dagegen tun kann, sondern dass sich da so ein blöder Router nicht an die RFC 3315 hält - wogegen ich auch nichts machen kann - dann ist das schon frustierend.
Die einfachste Lösung wäre für mich, wenn ich am Router das DHCPv6 einfach abschalten könnte. Keine Ahnung warum nicht wenigstens das geht.
Diese Firmware sollte drignend mal überarbeitet werden. Das ist jetzt das zweite Problem, das ich feststelle (das erste hatte ich ja schon gepostet: schaltet man die IPv6 Firewall an, geht gar kein IPv6 Traffic mehr - auch nicht raus. Sehr sinnvoll).
Re: CH7485E Kabelbox: DHCPv6 server broken
Wenn dann rauskommt, dass ich auch mit Configänderungen nichts dagegen tun kann, sondern dass sich da so ein blöder Router nicht an die RFC 3315 hält - wogegen ich auch nichts machen kann - dann ist das schon frustierend.[/quote]fansari hat geschrieben:Die Frage ist, was du unter "bemerkbar" verstehst. Um es gleich zu sagen: nein, es führt nicht dazu, dass das Netzwerk nach dem Bootvorgang nicht richtig konfiguriert ist. Das Advertising funktioniert offenbar, denn der Präfix wird zugewiesen (das Interface ist nicht statisch konfiguriert), eine Default Route wird gesetzt (DNS braucht nicht konfiguriert zu werden, da ich bind laufen lasse).
Wenn ich allerdings jedesmal beim Booten eine Fehlermeldung vom NetworkManager bkomme und dann in den Logfiles einen Timeout nach 45s sehe, dann nervt mich das irgendwann und veranlasst mich der Sache nachzugehen.
Ok, verstehe. Bzw. verstehe nicht. Die Fehlermeldung ist nervig, klar. Aber ich habe noch nicht ganz verstanden, was der DHCPv6 eigentlich machen sollte.
Weil Windows einschließlich Windows 10 nicht damit umgehen kann, wenn der DNS-Server per Router Advertisement mitgeteilt wird. Daher ist in einer Windows-Umgebung zwingend ein DHCPv6 von Nöten, wenn man Auto-Configuration benutzen möchte. Die DNS-Server per Hand einzutragen wäre zwar möglich, ist aber gerade bei mobilen Clients nervig. Und aus dem Grund wurde es ja eigentlich auch erst ins RFC aufgenommen. Deswegen ergibt es für TeleColumbus keinen Sinn, eine Firmware ohne DHCPv6 zu entwickeln. Denn ich schätze mal grob 99,99% der Nutzer werden ihn benötigen.Die einfachste Lösung wäre für mich, wenn ich am Router das DHCPv6 einfach abschalten könnte. Keine Ahnung warum nicht wenigstens das geht.
Das war mir auch aufgefallen. Da verstehe ich wirklich nicht, wie das so durchgehen konnte.Diese Firmware sollte drignend mal überarbeitet werden. Das ist jetzt das zweite Problem, das ich feststelle (das erste hatte ich ja schon gepostet: schaltet man die IPv6 Firewall an, geht gar kein IPv6 Traffic mehr - auch nicht raus. Sehr sinnvoll).