| 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
| ||
|
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?
Powered by blists - more mailing lists