[OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert "kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)"

Linus Lüssing linus.luessing at c0d3.blue
Sun Aug 30 18:54:06 EDT 2015


On Sun, Aug 30, 2015 at 03:49:50PM +0200, Linus Lüssing wrote:
> Hi Steven,
> 
> Thanks for the feedback.
> 
> On Sat, Aug 29, 2015 at 04:21:50PM +0200, Steven Barth wrote:
> > Let me know if you need more info.
> 
> Could you make a tcpdump for ICMPv6 on the wifi of the client?
> Please start it before connecting and let it run for about three
> minutes after connecting to the wifi.

Ok, I was able to easily reproduce the issue here. Looking at the
tcpdump the wifi client receives its own Neighbor Solicitation
again, reflected through the bridge-hairpin option.

The Linux IPv6 stack seems to interpret the reflected NS as an
address collision with another host. It seems a little weird that
the Linux kernel does that for NS - I think an IPv6 implementation
should only interpret Neighbor Advertisements as address conflicts
if I remember the RFCs correctly.


My current thought to fix this issue is to patch the
multicast-to-unicast patch in the following way:

Only transmit multicast-to-unicast'ed packets if the mangled,
now unicast MAC destination address differs from the MAC source.


We need to think about what'd happen for non-multicast-to-unicast'ed
multicast packets which get reflected back to the wifi interface
though. This should only happen if a multicast router is on one of
the wifi clients / STAs, I think. Will need to check whether the
Linux kernel interprets multicast packets without a mangled
MAC destination as duplicates, too.

Cheers, Linus
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list