On ons, mar 16, 2022 at 17:18, Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > On 3/10/2022 6:23 AM, Hans Schultz wrote: >> This patch set extends the locked port feature for devices >> that are behind a locked port, but do not have the ability to >> authorize themselves as a supplicant using IEEE 802.1X. >> Such devices can be printers, meters or anything related to >> fixed installations. Instead of 802.1X authorization, devices >> can get access based on their MAC addresses being whitelisted. >> >> For an authorization daemon to detect that a device is trying >> to get access through a locked port, the bridge will add the >> MAC address of the device to the FDB with a locked flag to it. >> Thus the authorization daemon can catch the FDB add event and >> check if the MAC address is in the whitelist and if so replace >> the FDB entry without the locked flag enabled, and thus open >> the port for the device. >> >> This feature is known as MAC-Auth or MAC Authentication Bypass >> (MAB) in Cisco terminology, where the full MAB concept involves >> additional Cisco infrastructure for authorization. There is no >> real authentication process, as the MAC address of the device >> is the only input the authorization daemon, in the general >> case, has to base the decision if to unlock the port or not. >> >> With this patch set, an implementation of the offloaded case is >> supplied for the mv88e6xxx driver. When a packet ingresses on >> a locked port, an ATU miss violation event will occur. When >> handling such ATU miss violation interrupts, the MAC address of >> the device is added to the FDB with a zero destination port >> vector (DPV) and the MAC address is communicated through the >> switchdev layer to the bridge, so that a FDB entry with the >> locked flag enabled can be added. > > FWIW, we may have about a 30% - 70% split between switches that will > signal ATU violations over a side band interrupt, like mv88e6xxx will, > and the rest will likely signal such events via the proprietary tag > format. I guess that the proprietary tag scheme a scenario where the packet can be forwarded to the bridge module's ingress queue on the respective port? > -- > Florian
