Hi Ondrej, On Sun, Mar 12, 2023 at 01:29:23PM +0100, Ondrej Zajicek wrote:
I do not really get this. For multicast, outgoing interface is defined by setsockopt(IPV6_MULTICAST_IF) in sk_setup_multicast6().
Hmm, I hadn't seen that. That is odd indeed. Looking at this again I also noticed we set the interface using PKTINFO (ipi6_ifindex) too which seems to make setting MULTICAST_IF redundant.
The field sin6_scope_id should be used only for link-local addresses (to define their scope), not as a way to route multicasts.
Not sure what is going on either, but I have absolutely positively observed the packets on the wrong interface and my patch fixed this. I have three physical en interfaces (enp{1,2,3}s0 and a couple of vlan ones on top of enp2s0. The RAs should be going out enp2s0* only but enp1s0 is still getting one. enp3s0 is also up but isn't receiving this erronous RA. I noticed something in tcpdump just now, when using -iany the incorrect RA advert shows up as an "M" (multicast) as opposed to "Out" on the correct interface. This only happens when sending an RA on enp2s0 not any of the stacked vlan interfaces: enp2s0 Out IP6 fe80::debb > ff02::1: ICMP6, router advertisement, length 112 enp1s0 M IP6 fe80::debb > ff02::1: ICMP6, router advertisement, length 112 enp2s0.20 Out IP6 fe80::20d:b9ff:fe4e:9055 > ff02::1: ICMP6, router advertisement, length 80 enp2s0.40 Out IP6 fe80::debb > ff02::1: ICMP6, router advertisement, length 80 enp2s0.10 Out IP6 fe80::20d:b9ff:fe4e:9055 > ff02::1: ICMP6, router advertisement, length 48 Not sure what to make of this. (Note: fe80::debb isn't the link-local address of enp1s0, which seems weird)
(Hmm, ff02::/16 is defined as link-local multicast address, so perhaps setting sin6_scope_id makes sense.)
If sending (IPv6) multicasts does not work properly, that should be also noticed in OSPFv3/RIPng, but i am not aware of such issue.
Well there are quite a few options here, perhaps those protos just have subtly different socket setup or perhaps there's something particular about my setup that makes it go wrong on the kernel side? Thanks, --Daniel