beta wdr4900 node: kein ipv4 an wan #315

New Issue

rohammer · 2024-03-07T11:40:59+01:00

rohammer commented

2024-03-07 11:40:59 +01:00

der Router holt sich keine ipv4 an wan / switch0.2

`
switch0.2@switch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f8:1a:67:a5:f8:0d brd ff:ff:ff:ff:ff:ff
inet6 fd2f:d46b:e9f9:0:fa1a:67ff:fea5:f80d/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 2003:d2:572d:a268:fa1a:67ff:fea5:f80d/64 scope global dynamic noprefixroute
valid_lft 604763sec preferred_lft 86363sec
inet6 fe80::fa1a:67ff:fea5:f80d/64 scope link
valid_lft forever preferred_lft forever
'

der Router holt sich keine ipv4 an wan / switch0.2 ` switch0.2@switch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether f8:1a:67:a5:f8:0d brd ff:ff:ff:ff:ff:ff inet6 fd2f:d46b:e9f9:0:fa1a:67ff:fea5:f80d/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 2003:d2:572d:a268:fa1a:67ff:fea5:f80d/64 scope global dynamic noprefixroute valid_lft 604763sec preferred_lft 86363sec inet6 fe80::fa1a:67ff:fea5:f80d/64 scope link valid_lft forever preferred_lft forever '

fbl added the

bug

node

labels 2024-03-07 11:42:12 +01:00

rohammer commented

2024-03-07 12:27:04 +01:00

Ein sysupgrade -n hilft auch nicht

fbl commented

2024-03-07 12:30:53 +01:00

Betrifft das alle Geräte oder wirklich nur den 4900?
Ich habe nur einen 4900 node, und der ist ebenfalls betroffen. Hab das nur gar nicht bemerkt, weil IPv6 geht ja.

Betrifft das alle Geräte oder wirklich nur den 4900? Ich habe nur einen 4900 node, und der ist ebenfalls betroffen. Hab das nur gar nicht bemerkt, weil IPv6 geht ja.

rohammer commented

2024-03-07 20:16:08 +01:00

Beim 1043 ist alles ok.

rohammer commented

2024-03-09 20:46:53 +01:00

wenn man wan konfiguriert und switch0_2 raus wirft, geht alles.

config interface 'wan' option proto 'dhcp' option ifname 'wan'
Dann startet der udhcpd mit -i wan statt mit -i switch0_2
Ev. macht das den Unterschied.
Warun udhcpd mit switch0_2 nicht funktioniert, hab ich nicht rausgefunden.

wenn man wan konfiguriert und switch0_2 raus wirft, geht alles. ` config interface 'wan' option proto 'dhcp' option ifname 'wan' ` Dann startet der udhcpd mit `-i wan` statt mit `-i switch0_2` Ev. macht das den Unterschied. Warun udhcpd mit switch0_2 nicht funktioniert, hab ich nicht rausgefunden.

rohammer commented

2024-03-09 22:32:41 +01:00

Ich glaub's ja nicht. Es liegt an dem proto 'none'

Ok, Openwrt schreibt:
"none Unspecified protocol, therefore all the other interface settings will be ignored (like disabling the configuration)"

Einfach weglassen, und ich dachte proto sei required.

Ich glaub's ja nicht. Es liegt an dem proto 'none' Ok, Openwrt schreibt: "none Unspecified protocol, therefore all the other interface settings will be ignored (like disabling the configuration)" Einfach weglassen, und ich dachte proto sei required.

fbl commented

2024-03-10 12:54:02 +01:00

Unter "all the other interface settings" würde ich verstehen dass die Settings vom gleichen logischen Interface gemeint sind. Nicht die Settings von anderen logischen Interfaces die nur das physikalische Interface referenziert haben.

Was das leider auch noch nicht erklärt: Wieso ist es nur beim 4900 kaputt?

Unter "all the other interface settings" würde ich verstehen dass die Settings vom gleichen logischen Interface gemeint sind. Nicht die Settings von anderen logischen Interfaces die nur das physikalische Interface referenziert haben. Was das leider auch noch nicht erklärt: Wieso ist es nur beim 4900 kaputt?

rohammer commented

2024-03-10 20:35:51 +01:00

Ich konnte es nur bei einem 1043er ausprobieren. Dem ist es egal, ob die Option gesetzt ist oder nicht.
Falls es mit allen anderen auch so ist, würde ich die Option raus nehmen, auch wenn ich es nicht wirklich verstehe.

Ich konnte es nur bei einem 1043er ausprobieren. Dem ist es egal, ob die Option gesetzt ist oder nicht. Falls es mit allen anderen auch so ist, würde ich die Option raus nehmen, auch wenn ich es nicht wirklich verstehe.

fbl commented

2024-03-11 23:01:28 +01:00

Meine Vermutung: Es handelt sich um einen Bug der nur mit DSA auftritt, nicht aber mit swconfig. Daher tritt das Problem beim 1043 nicht auf.

Es sieht für mich auf den ersten Blick so aus als hätten wir ein Problem mit der Firewall. Dass IPv6 geht ist nur großer Zufall, denn auch SLAAC funktioniert nicht ordentlich. Erst wenn der Router ein Unsolicited Router Advertisement schickt kann sich der Router Adressen zuweisen. Das Versenden eines Router Solicit funktioniert nicht.

Einmal kurz die Firewall geflusht und tatsächlich: Irgendeine Regel blockiert DHCP und SLAAC Dinge. Hier dann direkt die Vermutung: Wir haben DSA (was ja nun anders als bei swconfig eine Linux Bridge ist) bei der bridge-Firewall nicht korrekt berücksichtigt.

# nft list ruleset
table bridge filter {
    [..]

	chain OUT_ONLY {
		oifname != "bat0" counter packets 8 bytes 1770 drop
		counter packets 0 bytes 0
	}

    [..]

	chain OUTPUT {
        [..]
		ether type ip udp dport 67 counter packets 4 bytes 1312 jump OUT_ONLY
		ether type ip6 udp dport 547 counter packets 3 bytes 402 jump OUT_ONLY
		icmpv6 type nd-router-solicit counter packets 1 bytes 56 jump OUT_ONLY
        [..]
    }

    [..]
}

Diese Regeln sind eigentlich dafür da um zu verhindern dass ein lokal angestöpselter DHCP Server sich nicht über batman (bat0) verbreiten kann. Scheinbar greifen diese jetzt auch ungewollt auf der DSA Bridge.

Meine Vermutung: Es handelt sich um einen Bug der nur mit DSA auftritt, nicht aber mit swconfig. Daher tritt das Problem beim 1043 nicht auf. Es sieht für mich auf den ersten Blick so aus als hätten wir ein Problem mit der Firewall. Dass IPv6 geht ist nur großer Zufall, denn auch SLAAC funktioniert nicht ordentlich. Erst wenn der Router ein Unsolicited Router Advertisement schickt kann sich der Router Adressen zuweisen. Das Versenden eines Router Solicit funktioniert nicht. Einmal kurz die Firewall geflusht und tatsächlich: Irgendeine Regel blockiert DHCP und SLAAC Dinge. Hier dann direkt die Vermutung: Wir haben DSA (was ja nun anders als bei swconfig eine Linux Bridge ist) bei der bridge-Firewall nicht korrekt berücksichtigt. ``` # nft list ruleset table bridge filter { [..] chain OUT_ONLY { oifname != "bat0" counter packets 8 bytes 1770 drop counter packets 0 bytes 0 } [..] chain OUTPUT { [..] ether type ip udp dport 67 counter packets 4 bytes 1312 jump OUT_ONLY ether type ip6 udp dport 547 counter packets 3 bytes 402 jump OUT_ONLY icmpv6 type nd-router-solicit counter packets 1 bytes 56 jump OUT_ONLY [..] } [..] } ``` Diese Regeln sind eigentlich dafür da um zu verhindern dass ein lokal angestöpselter DHCP Server sich nicht über batman (bat0) verbreiten kann. Scheinbar greifen diese jetzt auch ungewollt auf der DSA Bridge.

fbl added this to the 20240401-beta milestone 2024-03-11 23:01:35 +01:00

fbl referenced a pull request that will close this issue

2024-03-11 23:48:01 +01:00

fff-node: apply firewall rules to br-client only #318

fbl referenced this issue from a commit

2024-03-21 21:58:03 +01:00

fff-node: apply firewall rules to br-client only

fbl closed this issue

2024-03-21 21:58:03 +01:00

Sign in to join this conversation.