On 2022-10-20 14:54, Ido Schimmel wrote:
On Tue, Oct 18, 2022 at 06:56:08PM +0200, Hans J. Schultz wrote:
Add an intermediate state for clients behind a locked port to allow
for
possible opening of the port for said clients. The clients mac address
will be added with the locked flag set, denying access through the
port
The entry itself is not denying the access through the port, but
rather the fact that the port is locked and there is no matching FDB
entry.
for the mac address, but also creating a new FDB add event giving
userspace daemons the ability to unlock the mac address. This feature
corresponds to the Mac-Auth and MAC Authentication Bypass (MAB) named
features. The latter defined by Cisco.
Worth mentioning that the feature is enabled via the 'mab' bridge port
option (BR_PORT_MAB).
Only the kernel can set this FDB entry flag, while userspace can read
the flag and remove it by replacing or deleting the FDB entry.
Locked entries will age out with the set bridge ageing time.
Signed-off-by: Hans J. Schultz <netdev@xxxxxxxxxxxxxxxxxxxx>
Overall looks OK to me. See one comment below.
Reviewed-by: Ido Schimmel <idosch@xxxxxxxxxx>
[...]
@@ -1178,6 +1192,14 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr
*tb[],
vg = nbp_vlan_group(p);
}
+ if (tb[NDA_FLAGS_EXT])
+ ext_flags = nla_get_u32(tb[NDA_FLAGS_EXT]);
+
+ if (ext_flags & NTF_EXT_LOCKED) {
+ pr_info("bridge: RTM_NEWNEIGH has invalid extended flags\n");
I understand this function makes use of pr_info(), but it already gets
extack and it's a matter of time until the pr_info() instances will be
converted to extack. I would just use extack here like you are doing in
the next patch.
Also, I find this message more helpful:
"Cannot add FDB entry with \"locked\" flag set"
Okay, since Jakub says that this patch set must be resent, the question
remains
to me if I shall make these changes and resend the patch set as v8?
