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] [day] [month] [year] [list]

Message-ID: <CAGnHSEmu2iYnRzFfKA9iT585M1GnCHCxY3Riztu+oDZyb0whUA@mail.gmail.com>
Date:   Sun, 29 Aug 2021 21:12:35 +0800
From:   Tom Yan <tom.ty89@...il.com>
To:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: Bridged passthru MACVLAN breaks IPv6 multicast?

Hmm, interestingly, the problem occurs only when I am using the
permanent MAC address of the wireless NIC. If I change/randomize the
address (and of course, make the bridge use the result as its own
address as well), Neighbor Solicitations can come in without needing
the NIC and the MACVLAN to have IPv6LL.

On Tue, 24 Aug 2021 at 15:41, Tom Yan <tom.ty89@...il.com> wrote:
>
> To be more precise, when the passthru MACVLAN is not bridged, I can see:
>
> # tcpdump -eni any icmp6
> tcpdump: data link type LINUX_SLL2
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot
> length 262144 bytes
> 15:30:50.865328 wlan0 M   ifindex 5 LAN_HOST_MAC ethertype IPv6
> (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor
> solicitation, who has THIS_HOST_LL, length 32
> 15:30:50.865547 macvl0 M   ifindex 6 LAN_HOST_MAC ethertype IPv6
> (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor
> solicitation, who has THIS_HOST_LL, length 32
>
> followed by unicast neighbor advertisement "OUTs" from this host to
> the LAN host.
>
> But when the MACVLAN is bridged, I cannot see a similar capture at all
> (i.e. it doesn't just "stop" before "walking across" the MACVLAN,
> rather they appear to be blocked at "the outside" or so.)
>
> On Tue, 24 Aug 2021 at 12:57, Tom Yan <tom.ty89@...il.com> wrote:
> >
> > 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