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: <CAGnHSEmeLTq6FsG18QDBmD_cHcNfTk2N6t7Nwrc53p9Ejnd5kg@mail.gmail.com>
Date:   Tue, 24 Aug 2021 12:12:33 +0800
From:   Tom Yan <tom.ty89@...il.com>
To:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: Bridged passthru MACVLAN breaks IPv6 multicast?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ