Linux Ethernet Bridging - Apr 2020 - [Bridge] [RFC PATCH net-next] net: bridge: fix client roaming from DSA user port

On Mon, Apr 20, 2020 at 12:19:46AM +0800, DENG Qingfang
wrote:
> When a client roams from a DSA user port to a soft-bridged port (such as
WiFi
> interface), the left-over MAC entry in the switch HW is not deleted,
causing
> inconsistency between Linux fdb and the switch MAC table. As a result, the
> client cannot talk to other hosts which are on that DSA user port until the
> MAC entry expires.
> 
> Solve this by notifying switchdev fdb to delete the leftover entry when an
> entry is updated. Remove the added_by_user check in DSA
> 
> Signed-off-by: DENG Qingfang <dqfext at gmail.com>
> ---
> I tried this on mt7530 and mv88e6xxx, but only mt7530 works.
> In previous discussion[1], Andrew Lunn said "try playing with auto
learning
> for the CPU port" but it didn't work on mv88e6xxx either
Hi Deng

We should probably first define how we expect moving MAC to work. Then
we can make any core fixes, and driver fixes.

For DSA, we have assumed that the software bridge and the hardware
bridge are independent, each performs its own learning. Only static
entries are kept in sync.

How should this separate learning work for a MAC address which moves?

    Andrew

On Mon, Apr 20, 2020 at 12:42 AM Andrew Lunn <andrew at lunn.ch>
wrote:
>
> On Mon, Apr 20, 2020 at 12:19:46AM +0800, DENG Qingfang wrote:
> > When a client roams from a DSA user port to a soft-bridged port (such
as WiFi
> > interface), the left-over MAC entry in the switch HW is not deleted,
causing
> > inconsistency between Linux fdb and the switch MAC table. As a result,
the
> > client cannot talk to other hosts which are on that DSA user port
until the
> > MAC entry expires.
> >
> > Solve this by notifying switchdev fdb to delete the leftover entry
when an
> > entry is updated. Remove the added_by_user check in DSA
> >
> > Signed-off-by: DENG Qingfang <dqfext at gmail.com>
> > ---
> > I tried this on mt7530 and mv88e6xxx, but only mt7530 works.
> > In previous discussion[1], Andrew Lunn said "try playing with
auto learning
> > for the CPU port" but it didn't work on mv88e6xxx either
>
> Hi Deng
>
> We should probably first define how we expect moving MAC to work. Then
> we can make any core fixes, and driver fixes.
>
> For DSA, we have assumed that the software bridge and the hardware
> bridge are independent, each performs its own learning. Only static
> entries are kept in sync.
>
> How should this separate learning work for a MAC address which moves?
When a client moves from a hardware port (e.g. sw0p1) to a software port (wlan0)
or another hardware port that belongs to a different switch (sw1p1),
that MAC entry
in sw0's MAC table should be deleted, or replaced with the CPU port as
destination,
by DSA. Otherwise the client is unable to talk to other hosts on sw0 because sw0
still thinks the client is on sw0p1.

Discussion in OpenWrt GitHub:
https://github.com/openwrt/openwrt/pull/2798#issuecomment-602221971

>
>     Andrew

> When a client moves from a hardware port (e.g. sw0p1) to a software port
(wlan0)
> or another hardware port that belongs to a different switch (sw1p1),
> that MAC entry
> in sw0's MAC table should be deleted, or replaced with the CPU port as
> destination,
> by DSA. Otherwise the client is unable to talk to other hosts on sw0
because sw0
> still thinks the client is on sw0p1.
The MAC address needs to move, no argument there. But what are the
mechanisms which cause this. Is learning sufficient, or does DSA need
to take an active role?

Forget about DSA for the moment. How does this work for two normal
bridges? Is the flow of unicast packets sufficient? Does it requires a
broadcast packet from the device after it moves?

	  Andrew