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

This reverts commit a080e8e1943156168913d0353a2e99d1151102aa.

It did not fix the problem but just hid some symptom. The real issue was
that IGMP/MLD report suppression was not considered for the
multicast-to-unicast feature. A recent netifd which isolates IGMP/MLD
reports between STAs by utilizing AP-isolation and bridge-hairpinning
should have fixed this.

It is perfectly fine to apply multicast-to-unicast to IPv6 Neighbor
Solicitations, too (once that feature is configured correctly).

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
---
 .../645-bridge_multicast_to_unicast.patch          |   37 +++++++++-----------
 1 file changed, 17 insertions(+), 20 deletions(-)

Hi Linus,

one of these two kernel patches break IPv6 over WiFi completely.

https://dev.openwrt.org/changeset/46719 works
https://dev.openwrt.org/changeset/46723 is broken with default settings,
but works when setting option igmp_snooping 0.

symptoms are:
"IPv6: wlan0: IPv6 duplicate address fe80::[...] detected!"
in the client's kernel log when connecting using WiFi.

Connecting through Ethernet (bridged to said WiFi) works as expected
though. Since the link-local is marked as dadfailed over WiFi,
IPv6 connectivity is completely broken, obviously the DAD failed
is a false positive.

Router is ar71xx / ath9k.
Client is iwlwfi.

Let me know if you need more info.



Cheers,

Steven

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.

On the router side, what's the output of:

* /sys/class/net/$bridged-wifi/brport/hairpin
* /sys/class/net/$bridged-wifi/brport/multicast_to_unicast
* /tmp/run/hostapd-*, ap-isolate=...

Cheers, Linus

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

PS: Out of curiousity, can someone with deeper knowledge into 802.11
tell me, when an STA sends a multicast packet to its master which
then rebroadcasts it at e.g. 1MBit/s, how does the originating STA
know that its a rebroadcast of its own frame and refrain from
forwarding it internally?

>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.

Why are we reflecting packets back to the originator anyway? Could it not be excluded?

Btw. once we are bit more stable i will try to test how the igmpv3/mldv2 querier / proxy I wrote interacts here (disabling kernel querier).

On Mon, Aug 31, 2015 at 11:29:45AM +0200, Steven Barth wrote:
> 
> 
> 
> >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.
> 
> Why are we reflecting packets back to the originator anyway? Could it not be excluded?

Currently the multicast-to-unicast patch reflects it back as it
detected that the originator itself is a listener of the multicast
group of the Neighbor Solicitation.

I had somehow expected that mac80211 would exclude it. But looks like it
doesn't. And yes, we can exclude/drop that unicast'ed multicast
packet with src==dst on the bridge side already like I said
before for a suggested fix. But it's not 100% sufficient yet, we'd
have issues again once a multicast router/querier is on an STA.

Cheers, Linus

> 
> Btw. once we are bit more stable i will try to test how the igmpv3/mldv2 querier / proxy I wrote interacts here (disabling kernel querier).

I'd be interested to hear about that :).

On Mon, Aug 31, 2015 at 12:19:44PM +0200, Linus Lüssing wrote:
> I had somehow expected that mac80211 would exclude it. But looks like it
> doesn't.

Looks like mac80211 on an STA does that for frames with a
multicast destination (to prevent getting the own multicast
packets echo'd back once the AP rebroadcasts them, I guess). E.g.
ap-isolation + bridge-hairpin without multicast-to-unicast works
fine. So maybe the simple fix for the multicast-to-unicast patch
is sufficient.

The unicast-to-multicast patch mangled the destination to a
unicast one and mac80211 does not seem to consider their source
address.

Going to make and try a patch for the bridge now.

Cheers, Linus