On 24/11/2024 23:23, Elliot Ayrey wrote:

On Sat, 2024-11-09 at 15:40 +0200, Nikolay Aleksandrov wrote:

quoted

No way, this is ridiculous. Changing the port like that for a notification is not
ok at all. It is also not the bridge's job to notify user-space for sticky fdbs
that are trying to roam, you already have some user-space app and you can catch
such fdbs by other means (sniffing, ebpf hooks, netfilter matching etc). Such
change can also lead to DDoS attacks with many notifications.

Unfortunately in this case the only indication we get from the hardware of this
event happening is a switchdev notification to the bridge. All traffic is dropped
in hardware when the port is in this mode so the methods you suggest will not work.

I see

I have changed my implementation to use Andrew's suggestion of using a new attribute
rather than messing with the port. But would this also be more appropriate if the
notification was only triggered when receiving the event from hardware? If not
then do you have any suggestions for getting these kinds of events from hardware
to userspace without going through the bridge?

We want to have the same behaviour (or as close as possible) between sw and hw.
Since this can cause many notifications to be sent up for current setups, maybe
make it optional so we'll get notifications for roam attempts only when we
explicitly enable them, with default off. You can look into bridge's bool options
for this (e.g. link-local fdb learning option).


Cheers,
 Nik