Re: [B.A.T.M.A.N.] [Bridge] Roaming trouble with bridge & multicast snooping

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 8 Sep 2015 05:11:22 +0200
Linus Lüssing <linus.luessing@c0d3.blue> wrote:

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

The only entity in this scenario that knows that it has changed
state is (c). Why doesn't the client resend a IGMP when it notes
a connection change?