Subject: [Mcast-wifi] Fwd: [Bridge] Roaming trouble with bridge & multicast snooping

From: Linus Lüssing <[email-masked]>
Date: Wed, 9 Dec 2015 18:16:57 +0100

Hi,

I am still hoping that I might have just missed some lines in an
RFC. But currently I am having the feeling, that there is
something missing and that something needs to be
specified/clarified from the IETF side
(e.g. that a host should resend its reports (and maybe an IPv6
Neighbor Advertisement, too?) after a link state change, too)

I would also be intersted in the experiences others have had with
various other operating systems. Which operating systems resend
their MLD report(s) right after roaming?

Regards, Linus

Thread on the bridge mailinglist:
https://lists.linuxfoundation.org/pipermail/bridge/2015-September/009752.html

----- Forwarded message from Linus Lüssing <[email-masked]> -----

Date: Tue, 8 Sep 2015 05:11:22 +0200
From: Linus Lüssing <[email-masked]>
To: [email-masked], [email-masked]
Subject: [Bridge] Roaming trouble with bridge & multicast snooping

Hi bridge folks,

I'm currently stuck with a simple scenario where enabling bridge
multicast snooping causes packetloss for some time:

----------

(c) <~~~> (A) <---> (B)

(c) is a wifi client, connected to a wifi access point (A).
(B) is another AP connected to (A) via ethernet cable.
The wifi-ap and ethernet interface are bridged on both (A) and (B).

Now (c) roams from (A) to (B):

          (A) <---> (B) <~~~> (c)

----------

Until the next multicast query is send (up to 125 seconds), (c)
will experience multicast packet loss: (B) does not know which
multicast traffic (c) wants yet and blocks forwarding multicast
traffic to it.

I couldn't find an IETF standard or discussion saying something
about how to deal with multicast snooping and roaming yet (I still
have the feeling I must have overlooked something as this scenario
seems common to me). Does anyone know anything about that or how
vendors implement that on their snooping switches?

The behaviour of (c) running a 3.16 kernel is:
After setting its wifi interface up, it stays quiet. After getting
a link / wifi connects, it sends an IGMP/MLD report first, without
waiting for a query. It then sends the IPv6 Neighbor Solicitation
messages for Duplicate Address Detection to be able to claim its
own IPv6 addresses.

However it does not resend reports / Neighbor Solicitations after
the link goes down and up again while the interface itself stays up.

I could think of two ways to solve the issue:

Either let mac80211 (hostapd?) notify the bridge once a new client
connects. Then let the bridge send a query to the client
immediately and directly.

Or once the bridge adds an fdb entry for a new host, send a query
to this host (no matter if it's wireless or not) immediately,
directly.

The "directly" could be implemented by setting the ethernet
destination to the according unicast MAC instead.

Even though slightly more latency, I'd opt (and would going to
provide a patch) for the second case.

What do others think about this?

Cheers, Linus

----- End forwarded message -----