Bug 214153

Summary:	IPv6 multicast cannot get pass bridged passthru MACVLAN
Product:	Drivers	Reporter:	Tom Yan (tom.ty89)
Component:	Network	Assignee:	drivers_network (drivers_network)
Status:	NEW ---
Severity:	normal	CC:	davem, sebastien
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	5.13.12	Subsystem:
Regression:	No	Bisected commit-id:

Description Tom Yan 2021-08-24 04:06:28 UTC

I have a passthru MACVLAN enslaved to a bridge. The MACVLAN and and its underlying link do NOT have IPv6LL (or any) address configured (while the bridge does).

I expect all IPv6 (or even all Ethernet) multicast to "walk across" the MACVLAN. Yet in reality only some of the traffics do that.

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)

Comment 1 Tom Yan 2021-08-24 04:08:42 UTC

Btw there is no problem with ARP (or IPv4 multicast, apparently)

Comment 2 Tom Yan 2021-08-24 04:58:16 UTC

Actually:

> ping ff02::1%some_dev and Neighbor Solicitation from a bridge tap host

"walks across" the MACVLAN as well (I forgot to change the ether saddr for them: the underlying link is a wireless NIC)

So it seems that only:

> Neighbor Solicitation from a LAN host

does not "walk across".

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

Comment 3 Tom Yan 2021-08-24 07:40:43 UTC

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_HOSTLL, length 32

followed by unicast neighbor advertisement "OUTs" from this host to the LAN host.

But when the MACVLAN is bridged, I cannot see similar capture at all (i.e. it doesn't just "stopped" before "walking across" the MACVLAN, rather they appears to be like blocked at "the outside" or so.)

Comment 4 Tom Yan 2021-08-29 13:13:33 UTC

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.