linux-kernel - Re: [net-next PATCH RFC] net: dsa: qca8k: make learning configurable and keep off if standalone

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6499d3f5.050a0220.3becf.7296@mx.google.com>
Date:   Mon, 26 Jun 2023 19:59:41 +0200
From:   Christian Marangi <ansuelsmth@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Atin Bainada <hi@...nb.me>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH RFC] net: dsa: qca8k: make learning configurable
 and keep off if standalone

On Mon, Jun 26, 2023 at 08:30:56PM +0300, Vladimir Oltean wrote:
> On Mon, Jun 26, 2023 at 06:41:50PM +0200, Christian Marangi wrote:
> > > Once that basic precondition passes, you should be able to start looking
> > > at tools/testing/selftests/drivers/net/dsa/ and run those one by one.
> > > An interesting one would be local_termination.sh, which monitors the way
> > > in which frames reach the CPU. Though be aware that some sub-tests from
> > > that suite will fail on misconfigurations that are non-fatal (and don't
> > > impact functionality), just sub-optimal (affecting performance). Like
> > > sending unknown packets to the CPU when the port is non-promiscuous and
> > > software would drop those packets anyway.
> > > 
> > 
> > Lots of difficult to run the selftests on a light fw but step at times
> > I'm managing to make use of them (could be helpfull to add some comments
> > in the .config saying that the testing port needs to be declared in the
> > struct) (and maybe some additional checks on the kind of device type are
> > required for the test to actually work (vrf, dummy, macvlan...)
> 
> Yeah, that doesn't sound like a bad idea at all. AFAIK,
> tools/testing/selftests/net/forwarding/lib.sh doesn't check
> "zcat /proc/config.gz" at all. Maybe it would be nice if it did, and to
> guard that behavior based on some REQUIRE_* variables that are true by
> default (but can be set to false by scripts).
>

Some thing can even be checked by simply creating an interface and see
if the thing gives error. I feel this is a better approach than checking
config and kflags since from what I can see the idea of these scripts is
to be system agnostic and sometimes it's handy to ""compile"" or package
these scripts on a different system than the target one (this is true
for every shell script and target specific stuff that needs to be
compiled is not the case)

> > Anyway a run of local_termination.sh produce the following output.
> > # selftests: drivers/net/dsa: local_termination.sh
> > # TEST: lan1: Unicast IPv4 to primary MAC address                     [FAIL]
> > #       reception failed
> 
> Hmm, so ping works but this doesn't? That's strange, because send_uc_ipv4()
> also pings. Have you run with bash -x to see why it fails?
> 

I just run with bash -x and I also mod the script to not delete the
tcpdump. Limiting the script to only this test the dump is just 2 ICMPv6
packet and no output from tcpdump aside from

tcpdump: listening on lan1, link-type EN10MB (Ethernet), snapshot length 65535 bytes
3 packets captured
5 packets received by filter
0 packets dropped by kernel

I feel like this is important so I think I should focus on understanding
why this doesn't work? Any clue?

> > # TEST: lan1: Unicast IPv4 to macvlan MAC address                     [FAIL]
> > #       reception failed
> > # TEST: lan1: Unicast IPv4 to unknown MAC address                     [ OK ]
> 
> So the only reason why this test passes is because in this case, the
> unicast drops are okay?
> 
> > # TEST: lan1: Unicast IPv4 to unknown MAC address, promisc            [FAIL]
> > #       reception failed
> > # TEST: lan1: Unicast IPv4 to unknown MAC address, allmulti           [ OK ]
> 
> Similar here. Packet should have been dropped; the test detects a drop => okay.
> Passes for the wrong reason, most likely, because this driver doesn't react
> on IFF_PROMISC or IFF_ALLMULTI.
> 
> > # TEST: lan1: Multicast IPv4 to joined group                          [ OK ]
> > # TEST: lan1: Multicast IPv4 to unknown group                         [FAIL]
> > #       reception succeeded, but should have failed
> 
> "reception succeeded, but should have failed" is the okay kind of failure.
> "reception failed" is what's bothering.
> 
> > # TEST: lan1: Multicast IPv4 to unknown group, promisc                [FAIL]
> > #       reception failed
> > # TEST: lan1: Multicast IPv4 to unknown group, allmulti               [ OK ]
> > # TEST: lan1: Multicast IPv6 to joined group                          [ OK ]
> > # TEST: lan1: Multicast IPv6 to unknown group                         [FAIL]
> > #       reception succeeded, but should have failed
> > # TEST: lan1: Multicast IPv6 to unknown group, promisc                [FAIL]
> > #       reception failed
> 
> This I cannot explain. For the test right above, "Multicast IPv6 to unknown group",
> it said that reception succeeded. This is sending the same packet, only
> the IFF_PROMISC flag of the device changes (this is also propagated to
> the DSA master). I've no idea why it fails. Again, bash -x will say more.
> 
> > # TEST: lan1: Multicast IPv6 to unknown group, allmulti               [ OK ]
> > # TEST: br0: Unicast IPv4 to primary MAC address                      [FAIL]
> > #       reception failed
> > # TEST: br0: Unicast IPv4 to macvlan MAC address                      [FAIL]
> > #       reception failed
> > # TEST: br0: Unicast IPv4 to unknown MAC address                      [ OK ]
> > # TEST: br0: Unicast IPv4 to unknown MAC address, promisc             [FAIL]
> > #       reception failed
> > # TEST: br0: Unicast IPv4 to unknown MAC address, allmulti            [ OK ]
> > # TEST: br0: Multicast IPv4 to joined group                           [ OK ]
> > # TEST: br0: Multicast IPv4 to unknown group                          [FAIL]
> > #       reception succeeded, but should have failed
> > # TEST: br0: Multicast IPv4 to unknown group, promisc                 [FAIL]
> > #       reception failed
> > # TEST: br0: Multicast IPv4 to unknown group, allmulti                [ OK ]
> > # TEST: br0: Multicast IPv6 to joined group                           [ OK ]
> > # TEST: br0: Multicast IPv6 to unknown group                          [FAIL]
> > #       reception succeeded, but should have failed
> > # TEST: br0: Multicast IPv6 to unknown group, promisc                 [FAIL]
> > #       reception failed
> > # TEST: br0: Multicast IPv6 to unknown group, allmulti                [ OK ]
> > 
> > Things doesn't look good to me or I am wrong?
> 
> Nope, doesn't look good at all. Looks like an incomplete setup.

-- 
	Ansuel