On Sun, Jul 17, 2022 at 06:22:57PM +0200, Hans S wrote: > On Sun, Jul 17, 2022 at 4:03 PM Vladimir Oltean <olteanv@xxxxxxxxx> wrote: > > > > On Sun, Jul 17, 2022 at 04:46:10PM +0300, Vladimir Oltean wrote: > > > Here, what happens is that a locked port learns the MAC SA from the > > > traffic it didn't drop, i.e. link-local. In other words, the bridge > > > behaves as expected and instructed: +locked +learning will cause just > > > that. It's the administrator's fault for not disabling learning. > > > It's also the mv88e6xxx driver's fault for not validating the "locked" + > > > "learning" brport flag *combination* until it properly supports "+locked > > > +learning" (the feature you are currently working on). > > > > > > I'm still confused why we don't just say that "+locked -learning" means > > > plain 802.1X, "+locked +learning" means MAB where we learn locked FDB entries. > > > > Or is it the problem that a "+locked +learning" bridge port will learn > > MAC SA from link-local traffic, but it will create FDB entries without > > the locked flag while doing so? The mv88e6xxx driver should react to the > > 'locked' flag from both directions (ADD_TO_DEVICE too, not just ADD_TO_BRIDGE). > > Yes, it creates an FDB entry in the bridge without the locked flag > set, and sends an ADD_TO_DEVICE notice with it. > And furthermore link-local packets include of course EAPOL packets, so > that's why +learning is a problem. So if we fix that, and make the dynamically learned FDB entry be locked because the port is locked (and offload them correctly in mv88e6xxx), what would be the problem, exactly? The +learning is what would allow these locked FDB entries to be created, and would allow the MAB to work. User space may still decide to not authorize this address, and it will remain locked.
