netdev - Re: Bridged passthru MACVLAN breaks IPv6 multicast?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGnHSEkBiJdLFb88U2d7EhgxvfwbE7DtOxp115SzoP8Cv_Jq4A@mail.gmail.com>
Date:   Tue, 24 Aug 2021 12:57:44 +0800
From:   Tom Yan <tom.ty89@...il.com>
To:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: Bridged passthru MACVLAN breaks IPv6 multicast?

Never mind. I made a mistake. Turns out only Neighbor Solicitation
from a LAN host does not "walk across" the MACVLAN. ping
ff02::1%some_dev and Neighbor Solicitation from a bridge tap host
actually do. (I forgot to change the ether saddr for them: the
underlying link is a wireless NIC)

Btw Neighbor Advertisement from a LAN host "walks across" the MACVLAN
as well. I can see it on this host.

I guess I can workaround the problem by re-enabling IPv6LL on the
MACVLAN. Still wonder why that is broken though.

On Tue, 24 Aug 2021 at 12:12, Tom Yan <tom.ty89@...il.com> wrote:
>
> Hi,
>
> I've further investigated the problem:
>
> What "walk across":
> ping ff02::1%bridge and Neighbor Solicitation from this host (tcpdump
> multicast on a LAN host can see them)
> ping ff02::1%some_dev from a LAN host (tcpdump multicast on this host
> or a bridge tap host can see them)
>
> What do not "walk across":
> Neighbor Solicitation from a LAN host (both tcpdump multicast on this
> host and on a bridge tap host cannot see them)
> ping ff02::1%some_dev and Neighbor Solicitation from a bridge tap host
> (tcpdump multicast on this host can see them, but that on a LAN host
> cannot)
>
> There is no problem with ARP (or IPv4 multicast, apparently).
>
> P.S. I've filed a bug report on:
> https://bugzilla.kernel.org/show_bug.cgi?id=214153
>
> Regards,
> Tom
>
> On Mon, 23 Aug 2021 at 02:07, Tom Yan <tom.ty89@...il.com> wrote:
> >
> > Hi,
> >
> > Normally when a NIC is (directly) enslaved as a bridge port, the NIC
> > itself does not need to have a IPv6 link-local address configured on
> > it for IPv6 multicast / NDP to work properly (instead the address can
> > simply be configured on the bridge like IPv4 addresses).
> >
> > Yet it appears that if the bridge port is instead a passthru mode
> > MACVLAN, IPv6 multicast traffics from (the link/"side" of) it cannot
> > reach the host (as in, cannot even be captured with tcpdump) unless
> > either the MACVLAN or its underlying link has a/the[1] IPv6 link-local
> > address configured.
> >
> > Is it an expected behavior? Or is it a bug?
> >
> > [1]: In my configuration, the bridge, the bridged passthru MACVLAN and
> > its underlying link have the same MAC address and hence (at least by
> > default) their IPv6 link-local addresses are identical.
> >
> > Regards,
> > Tom