I have a setup with two network interface:
tap0, bridged by
bridge name bridge id STP enabled interfaces br0 8000.************ no eth0 tap0
tap0 have an IP address besides
eth0's local IPv6 one:
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff inet6 fe80::XXXX:XXXX:XXXX:XXXX/64 scope link valid_lft forever preferred_lft forever 41: tap0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc fq_codel master br0 state DOWN group default qlen 100 link/ether YY:YY:YY:YY:YY:YY brd ff:ff:ff:ff:ff:ff
The bridge, however, has a static IPv4 address and a statelessly configured IPv6 address. Because I need this stateless IPv6 address to be configured if it were for
eth0, I configured the MAC of
tap0 to be larger than that of
eth0 (thus, brctl will choose
eth0 MAC as the
br0 MAC). As a result, the IP address that
br0 assignes itself is the same that
eth0 would choose without any other interfaces.
Note that privacy extensions are disabled (on
all as well as any specific interfaces).
br0 looks like this:
42: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff inet 192.168.X.Y/24 brd 192.168.X.255 scope global br0 valid_lft forever preferred_lft forever inet6 ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ/64 scope global valid_lft 7123sec preferred_lft 3523sec inet6 fe80::ZZZZ:ZZZZ:ZZZZ:ZZZZ/64 scope link valid_lft forever preferred_lft forever
So there's one public and one local IPv6 address and the public one matches the MAC (as it is chosen by stateless). When I now send ICMPv6 packets, I do not receive a reply:
PING google.com(2a00:1450:4001:80e::1008) 56 data bytes ^C --- google.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 1999ms
However, when checking with tcpdump, I see packets being sent and replies arriving between the server and my IP, i.e. I actually see the reply in the packet dump and it is addressed to the IPv6 address of
br0. I have tried to specify each interface with
ping6 -I <interface> without success.
So right now I am out of ideas: I send out packets, receive a reply on the correct address but still the system seems to be dropping it rather than accepting it. Why does it discard them? Can this be debugged?
Edit: I do have IPv6 routes, running
ip -6 route yields:
XXXX:XXX:XXXX:XXXX::/64 dev br0 proto kernel metric 256 expires 6997sec fe80::/64 dev br0 proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 default via fe80::XXX:XXXX:XXXX:XXXX dev br0 proto ra metric 1024 expires 1597sec
The first line is my ISP-assigned prefix as reported in my router (Fritz Box) and that seems correct as this should be my local network (am I correct?), so I don't need a gateway. The other two are link-local addresses so fine again.
The last route now is what should be interesting, right? The IP I find there seems to match my router. I can ping it, but only if specifying the interface, i.e. running
ping6 <ip> yields:
connect: Invalid argument
ping6 -I br0 <ip> works:
PING <ip>(<ip>) from <myip> br0: 56 data bytes 64 bytes from <ip> icmp_seq=1 ttl=64 time=0.534 ms 64 bytes from <ip> icmp_seq=2 ttl=64 time=0.393 ms 64 bytes from <ip> icmp_seq=3 ttl=64 time=0.350 ms 64 bytes from <ip> icmp_seq=4 ttl=64 time=0.369 ms ^C --- <ip> ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.350/0.411/0.534/0.075 ms
<ip> is the routers IP, i.e. the
fe80::... address from above. I cannot find the point in my routers configuration where it tells me this address, however, I do find its Unique Local Address (ULA) and it starts with
fd80:: but besides that is identical, so I am pretty confident that that's my routers IPv6 address.
However: I can look up my routers IPs using
nslookup -query=AAAA fritz.box which yields two responses: The ULA (
fd00::...) and the ISP-assigned IPv6 address within the prefix (
2a02:...) with the same suffix (I'm guessing it chooses this by using SLAAC with its MAC). What does not appear here is the IP that starts with
fe00:... which is entered in the route.
Maybe someone has an explanation for this weird behavior...