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 [off-list ref] 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 [off-list ref] wrote:

quoted

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 [off-list ref] wrote:

quoted

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 [off-list ref] wrote:

quoted

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