#
f97f1fcc |
|
08-Feb-2024 |
Ido Schimmel <idosch@nvidia.com> |
selftests: forwarding: Fix bridge locked port test flakiness The redirection test case fails in the netdev CI on debug kernels because an FDB entry is learned despite the presence of a tc filter that redirects incoming traffic [1]. I am unable to reproduce the failure locally, but I can see how it can happen given that learning is first enabled and only then the ingress tc filter is configured. On debug kernels the time window between these two operations is longer compared to regular kernels, allowing random packets to be transmitted and trigger learning. Fix by reversing the order and configure the ingress tc filter before enabling learning. [1] [...] # TEST: Locked port MAB redirect [FAIL] # Locked entry created for redirected traffic Fixes: 38c43a1ce758 ("selftests: forwarding: Add test case for traffic redirection from a locked port") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://lore.kernel.org/r/20240208155529.1199729-5-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
38c43a1c |
|
11-Aug-2023 |
Ido Schimmel <idosch@nvidia.com> |
selftests: forwarding: Add test case for traffic redirection from a locked port Check that traffic can be redirected from a locked bridge port and that it does not create locked FDB entries. Cc: Hans J. Schultz <netdev@kapio-technology.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4a331d34 |
|
01-Nov-2022 |
Hans J. Schultz <netdev@kapio-technology.com> |
selftests: forwarding: Add MAC Authentication Bypass (MAB) test cases Add four test cases to verify MAB functionality: * Verify that a locked FDB entry can be generated by the bridge, preventing a host from communicating via the bridge. Test that user space can clear the "locked" flag by replacing the entry, thereby authenticating the host and allowing it to communicate via the bridge. * Test that an entry cannot roam to a locked port, but that it can roam to an unlocked port. * Test that MAB can only be enabled on a port that is both locked and has learning enabled. * Test that locked FDB entries are flushed from a port when MAB is disabled. Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
07c8a2dd |
|
22-Apr-2022 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
selftests: drivers: dsa: add a subset of forwarding selftests This adds an initial subset of forwarding selftests which I considered to be relevant for DSA drivers, along with a forwarding.config that makes it easier to run them (disables veth pair creation, makes sure MAC addresses are unique and stable). The intention is to request driver writers to run these selftests during review and make sure that the tests pass, or at least that the problems are known. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f70f5f1a |
|
21-Mar-2022 |
Ido Schimmel <idosch@nvidia.com> |
selftests: forwarding: Use same VRF for port and VLAN upper The test creates a separate VRF for the VLAN upper, but does not destroy it during cleanup, resulting in "RTNETLINK answers: File exists" errors. Fix by using the same VRF for the port and its VLAN upper. This is OK since their IP addresses do not overlap. Before: # ./bridge_locked_port.sh TEST: Locked port ipv4 [ OK ] TEST: Locked port ipv6 [ OK ] TEST: Locked port vlan [ OK ] # ./bridge_locked_port.sh RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists TEST: Locked port ipv4 [ OK ] TEST: Locked port ipv6 [ OK ] TEST: Locked port vlan [ OK ] After: # ./bridge_locked_port.sh TEST: Locked port ipv4 [ OK ] TEST: Locked port ipv6 [ OK ] TEST: Locked port vlan [ OK ] # ./bridge_locked_port.sh TEST: Locked port ipv4 [ OK ] TEST: Locked port ipv6 [ OK ] TEST: Locked port vlan [ OK ] Fixes: b2b681a41251 ("selftests: forwarding: tests of locked port feature") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
917b149a |
|
21-Mar-2022 |
Ido Schimmel <idosch@nvidia.com> |
selftests: forwarding: Disable learning before link up Disable learning before bringing the bridge port up in order to avoid the FDB being populated and the test failing. Before: # ./bridge_locked_port.sh RTNETLINK answers: File exists TEST: Locked port ipv4 [FAIL] Ping worked after locking port, but before adding FDB entry TEST: Locked port ipv6 [ OK ] TEST: Locked port vlan [ OK ] After: # ./bridge_locked_port.sh TEST: Locked port ipv4 [ OK ] TEST: Locked port ipv6 [ OK ] TEST: Locked port vlan [ OK ] Fixes: b2b681a41251 ("selftests: forwarding: tests of locked port feature") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
b2b681a4 |
|
23-Feb-2022 |
Hans Schultz <schultz.hans@gmail.com> |
selftests: forwarding: tests of locked port feature These tests check that the basic locked port feature works, so that no 'host' can communicate (ping) through a locked port unless the MAC address of the 'host' interface is in the forwarding database of the bridge. Signed-off-by: Hans Schultz <schultz.hans+netdev@gmail.com> Acked-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|