gluon-mesh-batman-adv: fix source MAC for the IPv6 local-node address
Before, IPv6 packets from the local-node interface using the IPv6 ULA
were wrongly using the MAC address from br-client (64:70:02:ae:72:e4):
client$ tcpdump -i enp0s31f6 -e -n "ether src 16:41:95:40:f7:dc or ether src 64:70:02:ae:72:e4 or ether src 8c:16:45:66:ba:11"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes
00:02:51.202570 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 3, length 64
00:02:51.203040 64:70:02:ae:72:e4 > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 3, length 64
00:02:52.226566 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 4, length 64
00:02:52.227255 64:70:02:ae:72:e4 > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 4, length 64
(br-client: 64:70:02:ae:72:e4, local-node: 16:41:95:40:f7:dc, client device: 8c:16:45:66:ba:11)
$ ip a s dev local-node
10: local-node@local-port: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP qlen 1000
link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
inet 10.130.0.1/20 brd 10.130.15.255 scope global local-node
valid_lft forever preferred_lft forever
inet6 fdef:ffc0:3dd7::1/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::1441:95ff:fe40:f7dc/64 scope link
valid_lft forever preferred_lft forever
With this patch applied ICMPv6 uses the correct source MAC
address from the local-node interface (16:41:95:40:f7:dc):
$ tcpdump -i enp0s31f6 -e -n "ether src 16:41:95:40:f7:dc or ether src 64:70:02:ae:72:e4 or ether src 8c:16:45:66:ba:11"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes
00:15:19.757790 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 1, length 64
00:15:19.758567 16:41:95:40:f7:dc > 33:33:ff:66:ba:11, ethertype IPv6 (0x86dd), length 86: fdef:ffc0:3dd7::1 > ff02::1:ff66:ba11: ICMP6, neighbor solicitation, who has fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11, length 32
00:15:19.758617 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 86: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, neighbor advertisement, tgt is fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11, length 32
00:15:19.759220 16:41:95:40:f7:dc > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 1, length 64
00:15:20.759425 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 2, length 64
00:15:20.759966 16:41:95:40:f7:dc > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 2, length 64
In practice, this wrong MAC address does not seem to cause any
issues so far, though, as ebtables rules are filtering to bat0 for both
local-node MAC, IPv4 and IPv6 addresses and the IPv6 stack (at least in
Linux) does not seem to update its neighbor table from IPv6 data packets
(interestingly, contrary to the Linux IPv4 stack, as was observed
with 3ef28a4684
("gluon-client-bridge: Revert "move IPv4 local subnet route to br-client (#1312)").
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
909363f5b9