Kein IPv6 nach Update: disable_ipv6=1 auf Hardware Ports #272
Labels
No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: freifunk-franken/firmware#272
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ich habe das Problem jetzt schon mehrfach gehabt (
ER-X
undER-X-SFP
), dass nach einen Update (fff-upgrade.sh
) kein IPv6 auf dem WAN Interface verfügbar war. Jetzt habe ich noch einmal so eine Maschine erwischt und dabei ist mir folgendes auf einemER-X-SFP
aufgefallen:Ausschnitte aus der
/etc/config/gateway
:Ein
reboot
löst das Problem.configure-layer3
,reload_config
und sämtliche Kombinationen fürifup
nicht.Ich glaube ich habe eine grobe Ahnung wann das passiert. Es müssten allesamt Maschinen gewesen sein, die auf
DSA
upgedated wurden.Hier
dmesg | grep eth0
vom Gerät oben:Man sieht, dass
eth0
(wan
) nach dem ersten boot direkt nach dem Update erst noch einmal inswitch0
gepackt wird. Es sieht so aus, als würde auf allen Switchportsdisable_ipv6=1
gesetzt. Ich nehme an, um so keine (unnötigen) Link-Local Adressen zu erzeugen.Nach dem Umbau auf die neue config liegt
eth0
nicht mehr inswitch0
, bekommt aber dabei nichtdisable_ipv6=0
gesetzt.Auf "bridge members" wird tatsächlich IPv6 abgeschalten:
Im Rest der Datei findet man allerdings nichts mehr zu
ipv6
.Ansonsten habe ich nur noch folgende Stellen in
netifd
zu dem Thema gefunden:Das Problem passiert nur, wenn man ein Interface, was vorher bridge member war, in einem einzigen Schritt aus der Bridge entfernt und gleichzeitig in einen
config interface
-Block übernimmt. Entfernt man zuerst das Interface aus der Bridge, macht einreload_config
und legt erst dann denconfig interface
-Block an, funktioniert das reaktivieren von IPv6 einwandfrei.Der Call Stack beim Zurücksetzen der
disable_ipv6
-Eigenschaft für "enfernen, reload, hinzufügen" im reload-Schritt müsste ungefähr so aussehen:Bei "enfernen, hinzufügen" ohne reload kommt es nicht so weit, da das Device sowohl in der alten als auch in der neuen Konfiguration steht, daher ist
dev->current_config
gesetzt und das Device wird indevice_reset_old()
übersprungen.