Re: [PATCH net-next v1 1/1] net: bridge: ensure that link-local traffic cannot unlock a locked port

[Ido Schimmel <idosch@nvidia.com>]

On Fri, Jul 01, 2022 at 06:07:10PM +0200, Hans S wrote:
> There is several issues when learning is turned off with the mv88e6xxx driver:

Please don't top-post...

> 
> Mac-Auth requires learning turned on, otherwise there will be no miss
> violation interrupts afair.
> Refreshing of ATU entries does not work with learning turn off, as the
> PAV is set to zero when learning is turned off.
> This then further eliminates the use of the HoldAt1 feature and
> age-out interrupts.
> 
> With dynamic ATU entries (an upcoming patch set), an authorized unit
> gets a dynamic ATU entry, and if it goes quiet for 5 minutes, it's
> entry will age out and thus get removed.
> That also solves the port relocation issue as if a device relocates to
> another port it will be able to get access again after 5 minutes.

You assume I'm familiar with mv88e6xxx, when in fact I'm not. Here is
what I think you are saying:

1. When a port is locked and a packet is received with a SA that is not
in the FDB, it will only generate a miss violation if learning is
enabled. In which case, you will notify the bridge driver about this
entry as externally learned and locked entry.

2. When a port is locked and a packet is received with a SA that matches
a different port, it will be dropped regardless if learning is enabled
or not.

3. From the above I conclude that the HW will not auto-populate its FDB
when a port is locked.

4. FDB entries that point to a port that does not have learning enabled
are not subject to ageing (why?).

Assuming the above is correct, in order for mv88e6xxx to work correctly,
it needs to enable learning on all locked ports, but it should happen
regardless of the bridge driver learning configuration let alone impose
any limitations on it. In fact, hostapd must disable learning for all
locked ports.