destination mac address of IPv6 neighbour solicitation changed from multi- to unicast (IPv6 partly broken)

[elpeh]

Hello,

with 14.07rc3 I see the following misbehaviour on openwrt-ar71xx-generic-tl-wr710n-v1... This (IPv6 partly broken) was not the case with some earlier BB snapshot on that device and (as shown later) AA on WRT160NL.

Effect: IPv6 is not working reliably for a Linux VM in VMware Fusion on Macbook, connected by WLAN (Ethernet not tested yet). If OpenWRT has to send NDP neighbour solicitation packets those do not reach the VM (that means IPv6 connectivity for the VM only works if one e.g. ping6s the gateway/OpenWRT first).

VMware Fusion is doing some MAC address NAT for bridged interfaces with WLAN(?). Guest MAC addresses are replaced by address of host interface.

IPv6 Neighbour solicitation frames are sent to muliticast group and multicast MAC address. At laest this is also what tcpdump br-lan shows on OpenWRT:

07:53:15.267516 64:66:b3:85:15:c9 > 33:33:ff:6a:67:2f, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fde9:9177:dccc:8::1 > ff02::1:ff6a:672f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fde9:9177:dccc:8:20c:29ff:fe6a:672f

source link-address option (1), length 8 (1): 64:66:b3:85:15:c9

BUT: this is received on WLAN interface of Mac (host system):
09:53:15.273459 64:66:b3:85:15:c9 (oui Unknown) > b8:8d:12:18:31:e4 (oui Unknown), ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fde9:9177:dccc:8::1 > ff02::1:ff6a:672f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fde9:9177:dccc:8:20c:29ff:fe6a:672f

source link-address option (1), length 8 (1): 64:66:b3:85:15:c9

33:33:ff:6a:67:2f has been replaced by b8:8d:12:18:31:e4 somewhere. Somewhere within OpenWRT 14.07rc3 that is, because it happens only in this setup.
With earlier version (see above) the destinations address stays multicast.
VMware Fusion does not/cannot pass a frame with hardware address of Mac WLAN interface as destination to the Linux VM -> IPv6 for VM is broken...

What's going on here? Trying to optimize something? Please revert the change.

Thanks for your work,

Lutz

[cyrus]

We recently added a feature which translates multicast-to-unicast for wireless connection because WiFi is usually very bad at handling multicast traffic efficiently. This makes stuff like IPTV work better over wireless but apparently breaks in some obscure cases like yours.

You can probably disable this by adding:
option igmp_snooping 0
to your lan interface config in /etc/config/network.

I guess we will need to see if we can find a generic fix here or not since this layer 2 natting vmware is doing is not really standard behaviour either.

[elpeh]

Thanks. Yes, "option igmp_snooping 0" disables also multicast-to-unicast and leads to working IPv6 within VM. So does (manually) "echo 0 > /sys/devices/virtual/net/br-lan/brif/wlan0/multicast_to_unicast".
(Is the option igmp_snooping, setting /sys/.../muticast_snooping, activating MLD snooping, too, btw?)

Maybe you want to introduce an uci option for netifd to (de)activate this setting.

Concerning IPTV performance vs. IPv6 in VMs on WLAN connected hosts (not_so_ obscure, I think): Could it be possible to optionally exempt frames with ICMP(v6) from translation?

Lutz

[cyrus]

I'll notify the developer and will discuss some possible exceptions with him once he's back from vacation.

[nbd]

please try applying this patch on top of your kernel tree and see if it fixes the issue:
​http://nbd.name/br-multicast-test.patch

[elpeh]

Thanks! I won't be able to set up the build system/figure out how to compile and replace the kernel image within the next days/weeks though, I'm afraid. This patch is not included in trunk/snapshots yet, is it? Could someone provide me with a modified kernel/openwrt-ar71xx-generic-tl-wr710n-v1-squashfs-sysupgrade.bin for testing?

Lutz

[elpeh]

This patch is not included in the released 14.07, is it? Could this still change?
I'm sorry that I haven't been able to test it yet.

Lutz

[nbd]

It's not included. It may get included in 14.07.1 if it gets tested in time ;)

[elpeh]

Replying to nbd:

It's not included. It may get included in 14.07.1 if it gets tested in time ;)

Please do include there. It works (for me). Thanks, Lutz

[nbd]

committed in r43736, r43737

[linus.luessing@…]

Hi nbd. I'm a little upset because of this patch. We discussed thoroughly, what the real issue is:

​https://lists.openwrt.org/pipermail/openwrt-devel/2014-September/027859.html

And you made a suggestion how to fix things properly:

​https://lists.openwrt.org/pipermail/openwrt-devel/2014-October/028924.html

In my opinion, we should either have such a fix or disable the multicast-to-unicast feature by default. Disabling the feature partially with r43736, r43737 leaves things partially broken...

[nbd]

I hope that i will find the time to take care of this soon. I just had a bit too much other stuff to deal with

[chris@…]

I also was experiencing issues with ipv6 and VMWare Fusion VMs on my mac over wifi. I implemented the igmp_snooping 0 config change on my lan interface, and that resolved the issue.

If I didn't have a knowledgable network guy as a friend, who helped me go through a bunch of tcpdumps, I never would have figured this out on my own. I would agree that the default situation as-is is undesirable.

[linus.luessing@…]

@Lutz: Hm, it seems like a bug in VMWare Fusion to me: If it did NAT'ing properly, then this shouldn't be an issue and the multicast frame from OpenWRT unicasted to the WLAN adapter address of the Macbook should be translated back to the guest MAC by VMWare Fusion. So you are seeing MLD reports with the source MAC address of the VMWare guest when leaving the Macbook's WLAN / entering the OpenWRT AP?

NAT'ing should hide the internal guest MAC to the outside world.

[linus.luessing@…]

Although, then it'd have to change the MAC address *within* the ICMPv6 header of the IPv6 Neighbor Advertisement, too, which VMWare Fusion is probably not doing.

I'm curious, could someone provide a pcap-file with something like "tcpdump -i wlan0 icmp6" on the OpenWRT router and name the according MAC addresses of the host and guest on the Macbook? Or maybe some link to what VMWare Fusion is doing exactly?