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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A3F7C433F5 for ; Thu, 17 Mar 2022 14:59:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234722AbiCQPAw (ORCPT ); Thu, 17 Mar 2022 11:00:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233311AbiCQPAv (ORCPT ); Thu, 17 Mar 2022 11:00:51 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD780E6175; Thu, 17 Mar 2022 07:59:34 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4E9F25C0151; Thu, 17 Mar 2022 10:59:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 17 Mar 2022 10:59:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=eq8Q3Wf36/Ac2wsVD zrJSDqU/+NPSnDNknTC94Rn3ys=; b=Z+u61UZF2MpFvWSlO9RK9pImFvyFmJi45 jy6JXcXuXSm3frv6E3GS/SPdGVUx5jdEEFQ+QqdpGZu7HAE6uNYkS9LgMYaQn6Zk cRRvPrhYr46PgsDMZ0jQskLD2kuL7U6XppwJNiCHbvB3SxYso8QLkVtRg5Km+CWJ +1xP7shOd/FYQ7MTQdkVOZ4nJ5EuGNWy65PAxIBkgpphPWlQKfGyF+RCr0BJocYu qpUyh1nzzUhRZPMb7oJAfWWKpsc/EEoUvnPYjgH55dqG/yctgtg5MnjHJHJPuQio FPPlokROP7Nb3zWA9Rdjw0C02G7ih2Fp8snt5Brdtr6g8AwFYLxVQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefgedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpedtffekkeefudffveegueejffejhfetgfeuuefgvedtieehudeuueekhfduheel teenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiug hoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Mar 2022 10:59:33 -0400 (EDT) Date: Thu, 17 Mar 2022 16:59:30 +0200 From: Ido Schimmel To: Hans Schultz Cc: razor@blackwall.org, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Shuah Khan , Daniel Borkmann , Ido Schimmel , linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 net-next 1/4] net: bridge: add fdb flag to extent locked port feature Message-ID: References: <20220317093902.1305816-1-schultz.hans+netdev@gmail.com> <20220317093902.1305816-2-schultz.hans+netdev@gmail.com> <86ilsciqfh.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ilsciqfh.fsf@gmail.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Mar 17, 2022 at 03:50:26PM +0100, Hans Schultz wrote: > On tor, mar 17, 2022 at 15:44, Ido Schimmel wrote: > > On Thu, Mar 17, 2022 at 10:38:59AM +0100, Hans Schultz wrote: > >> Add an intermediate state for clients behind a locked port to allow for > >> possible opening of the port for said clients. This feature corresponds > >> to the Mac-Auth and MAC Authentication Bypass (MAB) named features. The > >> latter defined by Cisco. > >> Only the kernel can set this FDB entry flag, while userspace can read > >> the flag and remove it by deleting the FDB entry. > > > > Can you explain where this flag is rejected by the kernel? > > > Is it an effort to set the flag from iproute2 on adding a fdb entry? I'm not sure what you are asking, but even if iproute2 can't set the flag it doesn't mean the kernel shouldn't reject it > > > Nik, it seems the bridge ignores 'NDA_FLAGS_EXT', but I think that for > > new flags we should do a better job and reject unsupported > > configurations. WDYT? > > > > The neighbour code will correctly reject the new flag due to > > 'NTF_EXT_MASK'.