[Mcast-wifi] Fwd: [Bridge] Roaming trouble with bridge & multicast snooping
Linus Lüssing <linus.luessing@c0d3.blue> Wed, 09 December 2015 17:17 UTC
Return-Path: <linus.luessing@c0d3.blue>
X-Original-To: mcast-wifi@ietfa.amsl.com
Delivered-To: mcast-wifi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7751A0087 for <mcast-wifi@ietfa.amsl.com>; Wed, 9 Dec 2015 09:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.15
X-Spam-Level:
X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfZiV0JspLdn for <mcast-wifi@ietfa.amsl.com>; Wed, 9 Dec 2015 09:17:06 -0800 (PST)
Received: from mail.passe0815.de (mail.passe0815.de [IPv6:2a01:4f8:100:2384::20:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42DA1A004C for <mcast-wifi@ietf.org>; Wed, 9 Dec 2015 09:17:05 -0800 (PST)
Received: from mail.passe0815.de (localhost [127.0.0.1]) by mail.passe0815.de (Postfix) with ESMTP id F410A5879AB for <mcast-wifi@ietf.org>; Wed, 9 Dec 2015 18:17:02 +0100 (CET)
Received: from localhost (unknown [IPv6:2001:67c:2d50:0:c85:8cff:fe0f:63fe]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.passe0815.de (Postfix) with ESMTPSA id 4604C5879F4 for <mcast-wifi@ietf.org>; Wed, 9 Dec 2015 18:17:02 +0100 (CET)
Date: Wed, 09 Dec 2015 18:16:57 +0100
From: Linus Lüssing <linus.luessing@c0d3.blue>
To: mcast-wifi@ietf.org
Message-ID: <20151209171657.GI10527@otheros>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.24 (2015-08-30)
X-GPG-Mailgate: Not encrypted, public key not found
Archived-At: <http://mailarchive.ietf.org/arch/msg/mcast-wifi/Ghn2cGy1oN2ZwG1qaQO9SE13g6g>
Subject: [Mcast-wifi] Fwd: [Bridge] Roaming trouble with bridge & multicast snooping
X-BeenThere: mcast-wifi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues." <mcast-wifi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mcast-wifi/>
List-Post: <mailto:mcast-wifi@ietf.org>
List-Help: <mailto:mcast-wifi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2015 17:17:07 -0000
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 <linus.luessing@c0d3.blue> ----- Date: Tue, 8 Sep 2015 05:11:22 +0200 From: Linus Lüssing <linus.luessing@c0d3.blue> To: bridge@lists.linux-foundation.org, b.a.t.m.a.n@lists.open-mesh.org 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 -----
- [Mcast-wifi] Fwd: [Bridge] Roaming trouble with b… Linus Lüssing