netdev - [switchdev] bridge fdb vs. switch's ATU - connection timeout when roaming from LAN port to WLan port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5c0744ff-d233-8135-50ac-4e7cfbc400ba@gmx.net>
Date:   Mon, 20 Apr 2020 09:34:00 +0000
From:   ѽ҉ᶬḳ℠ <vtol@....net>
To:     netdev@...r.kernel.org
Subject: [switchdev] bridge fdb vs. switch's ATU - connection timeout when
 roaming from LAN port to WLan port

HOST config
* kernel 4.19.93
* SoC Cortex-A9 (armv7l)
* switch Marvell 88E6176 via PHY lane (mdio-mii) to SoC
* switch's downstream port driven by DSA
* switch's ATU’s /AgeTime/ control register default value = 0x13 (19 x
16 = 304 seconds)
* WLan card via mPCIe to SoC
________

Moving a client node from a (HOST) switch's downstream port (either
directly wired or indirectly via wireless AP that is wired into a switch
downstream port) to the HOST provided AP results in the client node not
being able to reach any other client node connected to a (HOST) switch's
downstream port.
Only after the switch's ATU’s /AgeTime/ has expired (and the MAC address
of the roaming client node been cleared in the ATU) the client node
(that been moved/roamed) is able to establish connectivity with any
other client node connected to a (HOST) switch's downstream port.

Whilst bridge fdb is learning on the switch's downstream ports and the
WLan ports the switch's ATU is learning only on its downstream ports.
That sort of constitutes a communication gap and leading to the
aforementioned connectivity issue in the described roaming scenario.

Should switchdev be expected to communicate (align) changes from the
bridge fdb to the switch's ATU and thus prevent the aforementioned
connectivity issue? Or else, how to remedy?