From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall-org.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Auj42wKcECcnklt6KoxYruKINeN/YRt0HTEgWQUvSbk=; b=trKaLQcY0Yt+MaFoeQX72QMgkuS5ppCOlNREaVS7jA73fXvLoyc7ULKKjY4nZXSvpb PAWHAjW2yBatHxPF21LM40sYwNnc0oT01X7OtZhPA65Blrr4xDZrt3YVuLS6rl3lkgGG qGdKrKHFuXoeQQ9/dhxBX4+2e5JzFER+NnKiU5FFpm/LZucICodXrX4AZJNcOwQFs4by 1HZEjYX5Ev2wrsD8Z6/cy8LNMwZrr5UseaxFnzXb3tEajr3lPLnCMXJwpnSk3XJxpJto 02FW+5u8/k7oc1hck+7sNYGTQV+G61KbOnMiUm6QlFH2vykPa7I8ht0+WeQS09VSChWa 5omQ== Message-ID: <24add056-e0d2-bf4b-9d56-04289bedbf15@blackwall.org> Date: Thu, 17 Mar 2022 15:54:43 +0200 MIME-Version: 1.0 Content-Language: en-US References: <20220317093902.1305816-1-schultz.hans+netdev@gmail.com> <20220317093902.1305816-2-schultz.hans+netdev@gmail.com> From: Nikolay Aleksandrov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [PATCH v2 net-next 1/4] net: bridge: add fdb flag to extent locked port feature List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ido Schimmel , Hans Schultz Cc: Ivan Vecera , Andrew Lunn , Florian Fainelli , Jiri Pirko , Daniel Borkmann , netdev@vger.kernel.org, Ido Schimmel , bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Vivien Didelot , Hans Schultz , linux-kselftest@vger.kernel.org, Roopa Prabhu , kuba@kernel.org, Vladimir Oltean , Shuah Khan , davem@davemloft.net On 17/03/2022 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? > > 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? > Definitely, I agree. > The neighbour code will correctly reject the new flag due to > 'NTF_EXT_MASK'.