From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, URI_HEX,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DDB3C43381 for ; Mon, 18 Feb 2019 11:34:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2F8FC20675 for ; Mon, 18 Feb 2019 11:34:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="01fyJ6uZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730064AbfBRLej (ORCPT ); Mon, 18 Feb 2019 06:34:39 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:52782 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730016AbfBRLei (ORCPT ); Mon, 18 Feb 2019 06:34:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eCyyK6VuEHSKtyBHVntnYEv3beHBl8NN5JG1wdMbrYo=; b=01fyJ6uZzRbkn6vO5B/LYoJCa vfJPTKALpZeNshHIpWoWU4RLiTQh6+CiYNdW7M3oxdwKv6wsJIVjR0obnYJC7DXmkj/6w6wxaHmtF JYx10OQaYRjC/dv4tIpRFHdOCx7V+n6pwTmh08it9YN8vzvAIKcXiaQY9vfpyBva7pEIsC+M1WJz4 UtSaQcwSbwwks20Wbnc72yKA7Tof/oNk3DDlrDWEMp+znPyqAoAFkq2l6AgA8wEVjWBL0YwMkoZdH dZz+1Dhx7viaeEuBQfnqhaEBtswb8JHqDmD8fjS/n0HkuFDRAFbMLnT0mhWtWP4R0wo8IrWPZq8aq VQw44+DOg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:51218) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gvhBx-0006m9-Hu; Mon, 18 Feb 2019 11:34:33 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1gvhBv-000788-NZ; Mon, 18 Feb 2019 11:34:31 +0000 Date: Mon, 18 Feb 2019 11:34:31 +0000 From: Russell King - ARM Linux admin To: Andrew Lunn , Florian Fainelli , Vivien Didelot Cc: "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: fix IPv6 Message-ID: <20190218113431.qfqgugriptugv3gh@shell.armlinux.org.uk> References: <20190217142414.cjtmpi5y2l5rtdlb@shell.armlinux.org.uk> <20190217163114.yomawlljyxlqy3ob@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190217163114.yomawlljyxlqy3ob@shell.armlinux.org.uk> User-Agent: NeoMutt/20170113 (1.7.2) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Feb 17, 2019 at 04:31:14PM +0000, Russell King - ARM Linux admin wrote: > We have had some emails in private over this issue, this is my current > patch set rebased on top of net-next which provides working IPv6 (and > probably other protocols as well) over mv88e6xxx DSA switches. > > The problem comes down to mv88e6xxx defaulting to not flood unknown > unicast and multicast datagrams, as they would be by dumb switches, > and as the Linux bridge code does by default. > > These flood settings can be disabled via the Linux bridge code if it's > desired to make the switch behave more like a managed switch, eg, by > enabling the multicast querier. However, the multicast querier > defaults to being disabled which effectively means that by default, > mv88e6xxx switches block all multicast traffic. This is at odds with > the Linux bridge documentation, and the defaults that the Linux bridge > code adopts. > > So, this patch set adds DSA support for Linux bridge flags, adds > mv88e6xxx support for the unicast and multicast flooding flags, and > lastly enables flooding of these frames by default to match the > Linux bridge defaults. While looking at some of the other DSA drivers, I've noticed that others are also programmed to forward unknown frames to the CPU port. Does this not end up breaking stuff? If I tcpdump the ethernet interface for the CPU port, what I see is: 11:21:21.901127 00:22:68:15:37:dd (oui Unknown) > 52:54:00:00:06:25 (oui Unknown), ethertype MEDSA (0xdada), length 126: Forward, untagged, dev.port:vlan 0.4:0, pri 0: ethertype IPv6 (0x86dd) e0022681537dd.dyn.armlinux.org.uk > tftp.armlinux.org.uk: ICMP6, echo request, seq 1, length 64 which is the unknown frame being delivered to the CPU port. It seems nothing else happens with the frame - it is ignored. Before my fixes for mv88e6xxx, that frame (and the following frames for the same MAC address) would end up being forwarded only to the CPU port and dropped on the floor, never making their way to their intended destination. It seems that "the hardware doesn't know what to do, forward it to Linux to sort out" doesn't actually work. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up