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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
