Ein bug? Nein viele bugs, zumindest bei der 5590.
- Beispiel 1: Sicherungsdatei erstellen - Ergebnis ist ein pdf file (!)
...
Das kann ich nicht bestätigen. Hab's gerade getestet:
Output von file(1):
Ein bug? Nein viele bugs, zumindest bei der 5590.
- Beispiel 1: Sicherungsdatei erstellen - Ergebnis ist ein pdf file (!)
...
Das kann ich nicht bestätigen. Hab's gerade getestet:
Output von file(1):
GVG scheint's wieder besser zu gehen.
Hier ein ganz interessanter Kommentar von heise zu Hustons Artikel aus dem OP:
Auszug:
ZitatStattdessen schlug man sich mit CGNAT der übelsten Sorte herum, und selbst das Hinzubuchen einer fixen IPv4 half nicht: Dann war man zwar per IPv4 zu erreichen, allerdings nur durch ein wirres DNAT-Konstrukt auf Providerseite.
Das ist mir bisher noch nicht begegnet. Mein Provider bietet auch die Zubuch-Option einer dynamischen IPv4-Adresse an, aber in der Schnittstellen- bzw. Leistungsbeschreibung stehen bzgl. der konkreten Umsetzung keine Details.
Falls man sowas dazubucht, sollte man wohl besser vorher beim Anbieter explizit nachfragen.
Das ist dann aber eigentlich ein Bug im Chrome OS. Eigentlich sollten die Geräte in der Lage sein, die richtige Quelladresse zu setzen.
Absolut! Ist zum Glück auch bereits gefixt für v130.
Der Grund für die Änderung ist die neue Unterstützung für IPv6 im VPN Tunnel.
Danke, das leuchtet ein! An Wireguard hatte ich nicht gedacht, weil ich das nicht auf der Fritzbox benutze.
Hallo zusammen,
tl;dr FritzOS 8.00 hat die Standardeinstellung für die Vergabe von IPv6 ULAs im Heimnetzwerk geändert, was eventuell zu Endnutzerproblemen bei der IPv6-Internetkonnektivität führen kann.
----------------------------
Die längere Version:
Nach dem automatischen Update auf FritzOS 8.00 habe ich bei meinem Chromebook Probleme bei der IPv6-Konnektivität bemerkt und beim Nachforschen einen Bug in ChromeOS gefunden. Jemand anders war schneller und hat die Problematik bereits hier ausführlich beschrieben.
Kurzfassung: Wenn im RA (Router Advertisement) GUAs und ULAs verteilt werden, ordnet ChromeOS beide Adressen dem Standardnetzwerkinterface zu. Der Browser und die Systemshell `crosh` (und vielleicht noch weitere Tools) wählen fälschlicherweise immer nur die erstbeste Adresse nichtdeterministisch aus anstatt alle vorhandenen in Betracht zu ziehen. Falls dies die ULA ist, hat man Pech und keine Internetkonnektivität über IPv6.
Mir kam es komisch vor, dass ich genau einen Tag nach dem FritzOS-Update auf diese Problematik gestoßen bin. Auch kann ich mich nicht entsinnen, vorher ULA-Adressen an den Interfaces meiner Geräte gesehen zu haben.
Und tatsächlich: Eine Änderung im FritzOS hat den ChromeOS-Fehler erst demaskiert. Das ist auch der Grund für meinen Post hier.
AVM schreibt im Changelog:
"Die IPv6-Option "ULA (Unique Local Address) zuweisen, solange keine IPv6-Internetverbindung besteht (empfohlen)" entfällt".
Im Konfigurationsexport spiegelt sich das wider als ulamode = ulamode_persist. Der default-Wert war vorher ulamode_dynamic.
Mit FritzOS 8.00 werden nun also standardmäßig immer ULAs zugewiesen. Zuvor geschah dies nur bei fehlender IPv6-Internetkonnektivität.
Vielleicht hilft dieser Post dem einen oder anderen weiter.