One question though... wouldn't it be an issue that the mentioned option setting is bridge wide, while the patch applies a per-port effect?
On Thu, Jun 30, 2022 at 1:38 PM Ido Schimmel idosch@nvidia.com wrote:
On Thu, Jun 30, 2022 at 01:16:34PM +0200, Hans Schultz wrote:
This patch is related to the patch set "Add support for locked bridge ports (for 802.1X)" Link: https://lore.kernel.org/netdev/20220223101650.1212814-1-schultz.hans+netdev@...
This patch makes the locked port feature work with learning turned on, which is enabled with the command:
bridge link set dev DEV learning on
Without this patch, link local traffic (01:80:c2) like EAPOL packets will create a fdb entry when ingressing on a locked port with learning turned on, thus unintentionally opening up the port for traffic for the said MAC.
Some switchcore features like Mac-Auth and refreshing of FDB entries, require learning enables on some switchcores, f.ex. the mv88e6xxx family. Other features may apply too.
Since many switchcores trap or mirror various multicast packets to the CPU, link local traffic will unintentionally unlock the port for the SA mac in question unless prevented by this patch.
Why not just teach hostapd to do:
echo 1 > /sys/class/net/br0/bridge/no_linklocal_learn
?