Radv proto sending adverts on wrong interface

[dxld at darkboxed.org]

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