Kein IPv6 nach Update: disable_ipv6=1 auf Hardware Ports #272

Open
opened 2022-11-29 10:06:01 +01:00 by jkimmel · 3 comments
Owner

Ich habe das Problem jetzt schon mehrfach gehabt (ER-X und ER-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 einem ER-X-SFP aufgefallen:

grep -r . /proc/sys/net/ipv6/conf/*/disable_ipv6
/proc/sys/net/ipv6/conf/all/disable_ipv6:0
/proc/sys/net/ipv6/conf/br-client/disable_ipv6:0
/proc/sys/net/ipv6/conf/default/disable_ipv6:0
/proc/sys/net/ipv6/conf/dsa/disable_ipv6:0
/proc/sys/net/ipv6/conf/erspan0/disable_ipv6:0
/proc/sys/net/ipv6/conf/eth0/disable_ipv6:1      # <- ???
/proc/sys/net/ipv6/conf/eth1/disable_ipv6:1
/proc/sys/net/ipv6/conf/eth2/disable_ipv6:1
/proc/sys/net/ipv6/conf/eth3/disable_ipv6:1
/proc/sys/net/ipv6/conf/eth4/disable_ipv6:1
/proc/sys/net/ipv6/conf/eth5/disable_ipv6:0
/proc/sys/net/ipv6/conf/gretap0/disable_ipv6:0
/proc/sys/net/ipv6/conf/ip6gre0/disable_ipv6:0
/proc/sys/net/ipv6/conf/ip6tnl0/disable_ipv6:0
/proc/sys/net/ipv6/conf/lo/disable_ipv6:0
/proc/sys/net/ipv6/conf/switch0.3/disable_ipv6:0
/proc/sys/net/ipv6/conf/switch0/disable_ipv6:0
/proc/sys/net/ipv6/conf/teql0/disable_ipv6:0
# ... wireguard peers

Ausschnitte aus der /etc/config/gateway:

config wan
	option iface 'eth0'

config client
	option iface 'eth1 eth2 eth3 eth4'
	...

config dns
	...

Ein reboot löst das Problem. configure-layer3, reload_config und sämtliche Kombinationen für ifup nicht.

Ich habe das Problem jetzt schon mehrfach gehabt (`ER-X` und `ER-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 einem `ER-X-SFP` aufgefallen: ```shell grep -r . /proc/sys/net/ipv6/conf/*/disable_ipv6 ``` ``` /proc/sys/net/ipv6/conf/all/disable_ipv6:0 /proc/sys/net/ipv6/conf/br-client/disable_ipv6:0 /proc/sys/net/ipv6/conf/default/disable_ipv6:0 /proc/sys/net/ipv6/conf/dsa/disable_ipv6:0 /proc/sys/net/ipv6/conf/erspan0/disable_ipv6:0 /proc/sys/net/ipv6/conf/eth0/disable_ipv6:1 # <- ??? /proc/sys/net/ipv6/conf/eth1/disable_ipv6:1 /proc/sys/net/ipv6/conf/eth2/disable_ipv6:1 /proc/sys/net/ipv6/conf/eth3/disable_ipv6:1 /proc/sys/net/ipv6/conf/eth4/disable_ipv6:1 /proc/sys/net/ipv6/conf/eth5/disable_ipv6:0 /proc/sys/net/ipv6/conf/gretap0/disable_ipv6:0 /proc/sys/net/ipv6/conf/ip6gre0/disable_ipv6:0 /proc/sys/net/ipv6/conf/ip6tnl0/disable_ipv6:0 /proc/sys/net/ipv6/conf/lo/disable_ipv6:0 /proc/sys/net/ipv6/conf/switch0.3/disable_ipv6:0 /proc/sys/net/ipv6/conf/switch0/disable_ipv6:0 /proc/sys/net/ipv6/conf/teql0/disable_ipv6:0 # ... wireguard peers ``` Ausschnitte aus der `/etc/config/gateway`: ``` config wan option iface 'eth0' config client option iface 'eth1 eth2 eth3 eth4' ... config dns ... ``` Ein `reboot` löst das Problem. `configure-layer3`, `reload_config` und sämtliche Kombinationen für `ifup` nicht.
jkimmel added the
bug
label 2022-11-29 10:06:01 +01:00
Author
Owner

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:

[    3.834165] mt7530 mdio-bus:1f eth0 (uninitialized): PHY [dsa-0.0:00] driver [Generic PHY]
[   26.330529] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode
[   26.344491] 8021q: adding VLAN 0 to HW filter on device eth0
[   26.359912] switch0: port 4(eth0) entered blocking state
[   26.370615] switch0: port 4(eth0) entered disabled state
[   26.384581] device eth0 entered promiscuous mode
[   29.513054] mt7530 mdio-bus:1f eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   29.543011] switch0: port 4(eth0) entered blocking state
[   29.553625] switch0: port 4(eth0) entered forwarding state
[   50.787413] switch0: port 4(eth0) entered disabled state
[   50.804363] device eth0 left promiscuous mode
[   50.813583] switch0: port 4(eth0) entered disabled state
[   50.844723] mt7530 mdio-bus:1f eth0: Link is Down
[   51.214343] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode
[   51.238808] 8021q: adding VLAN 0 to HW filter on device eth0
[   51.266956] switch0: port 1(eth0) entered blocking state
[   51.277650] switch0: port 1(eth0) entered disabled state
[   51.289415] device eth0 entered promiscuous mode
[   52.059594] device eth0 left promiscuous mode
[   52.068941] switch0: port 1(eth0) entered disabled state
[   52.107646] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode
[   52.121581] 8021q: adding VLAN 0 to HW filter on device eth0
[   52.797803] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode
[   52.811599] 8021q: adding VLAN 0 to HW filter on device eth0
[   55.881080] mt7530 mdio-bus:1f eth0: Link is Up - 1Gbps/Full - flow control rx/tx

Man sieht, dass eth0 (wan) nach dem ersten boot direkt nach dem Update erst noch einmal in switch0 gepackt wird. Es sieht so aus, als würde auf allen Switchports disable_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 in switch0, bekommt aber dabei nicht disable_ipv6=0 gesetzt.

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: ``` [ 3.834165] mt7530 mdio-bus:1f eth0 (uninitialized): PHY [dsa-0.0:00] driver [Generic PHY] [ 26.330529] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode [ 26.344491] 8021q: adding VLAN 0 to HW filter on device eth0 [ 26.359912] switch0: port 4(eth0) entered blocking state [ 26.370615] switch0: port 4(eth0) entered disabled state [ 26.384581] device eth0 entered promiscuous mode [ 29.513054] mt7530 mdio-bus:1f eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 29.543011] switch0: port 4(eth0) entered blocking state [ 29.553625] switch0: port 4(eth0) entered forwarding state [ 50.787413] switch0: port 4(eth0) entered disabled state [ 50.804363] device eth0 left promiscuous mode [ 50.813583] switch0: port 4(eth0) entered disabled state [ 50.844723] mt7530 mdio-bus:1f eth0: Link is Down [ 51.214343] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode [ 51.238808] 8021q: adding VLAN 0 to HW filter on device eth0 [ 51.266956] switch0: port 1(eth0) entered blocking state [ 51.277650] switch0: port 1(eth0) entered disabled state [ 51.289415] device eth0 entered promiscuous mode [ 52.059594] device eth0 left promiscuous mode [ 52.068941] switch0: port 1(eth0) entered disabled state [ 52.107646] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode [ 52.121581] 8021q: adding VLAN 0 to HW filter on device eth0 [ 52.797803] mt7530 mdio-bus:1f eth0: configuring for phy/gmii link mode [ 52.811599] 8021q: adding VLAN 0 to HW filter on device eth0 [ 55.881080] mt7530 mdio-bus:1f eth0: Link is Up - 1Gbps/Full - flow control rx/tx ``` Man sieht, dass `eth0` (`wan`) nach dem ersten boot direkt nach dem Update erst noch einmal in `switch0` gepackt wird. Es sieht so aus, als würde auf allen Switchports `disable_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 in `switch0`, bekommt aber dabei nicht `disable_ipv6=0` gesetzt.
Author
Owner

Auf "bridge members" wird tatsächlich IPv6 abgeschalten:

# bridge.c:412
    /* Disable IPv6 for bridge members */
    if (!(bm->dev.dev->settings.flags & DEV_OPT_IPV6)) {
        bm->dev.dev->settings.ipv6 = 0;
        bm->dev.dev->settings.flags |= DEV_OPT_IPV6;
    }

Im Rest der Datei findet man allerdings nichts mehr zu ipv6.

Ansonsten habe ich nur noch folgende Stellen in netifd zu dem Thema gefunden:

Auf "bridge members" wird [tatsächlich IPv6 abgeschalten](https://git.openwrt.org/?p=project/netifd.git;a=blob;f=bridge.c;h=7e61b9df8326175d8e28cbdd0bacbfc8e0a693c1;hb=HEAD#l412): ```C # bridge.c:412 /* Disable IPv6 for bridge members */ if (!(bm->dev.dev->settings.flags & DEV_OPT_IPV6)) { bm->dev.dev->settings.ipv6 = 0; bm->dev.dev->settings.flags |= DEV_OPT_IPV6; } ``` Im Rest der Datei findet man allerdings nichts mehr zu `ipv6`. Ansonsten habe ich nur noch folgende Stellen in `netifd` zu dem Thema gefunden: - https://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c;h=0f13a99f135b607ae1c718ba54f3e479e6741dfc;hb=HEAD#l1830 - https://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c;h=0f13a99f135b607ae1c718ba54f3e479e6741dfc;hb=HEAD#l1274
Owner

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 ein reload_config und legt erst dann den config 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:

system_if_clear_state()
device_init()
device_cleanup()
device_create_default()
device_reset_old()
config_init_all()

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 in device_reset_old() übersprungen.

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 ein `reload_config` und legt erst dann den `config 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: ``` system_if_clear_state() device_init() device_cleanup() device_create_default() device_reset_old() config_init_all() ``` 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 in `device_reset_old()` übersprungen.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: freifunk-franken/firmware#272
No description provided.