Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <649c3931.df0a0220.136ab.2fb7@mx.google.com>
Date:   Wed, 28 Jun 2023 02:49:53 +0200
From:   Christian Marangi <ansuelsmth@gmail.com>
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, Atin Bainada <hi@atinb.me>,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next PATCH RFC] net: dsa: qca8k: make learning configurable
 and keep off if standalone
References: <20230623114005.9680-1-ansuelsmth@gmail.com>
 <20230623114005.9680-1-ansuelsmth@gmail.com>
 <20230625115803.6xykp4wiqqdwwzv4@skbuf>
 <6499c31c.df0a0220.e2acb.5549@mx.google.com>
 <20230626173056.zq77nilzrr5djns5@skbuf>
 <6499d3f5.050a0220.3becf.7296@mx.google.com>
 <20230627094916.maywojwztzdek5y2@skbuf>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230627094916.maywojwztzdek5y2@skbuf>
Precedence: bulk

On Tue, Jun 27, 2023 at 12:49:16PM +0300, Vladimir Oltean wrote:
> On Mon, Jun 26, 2023 at 07:59:41PM +0200, Christian Marangi wrote:
> > > 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?
> 
> No clue. I'd put a "bash" instruction in send_uc_ipv4(), which would act
> as a sort of break point for the script (opens an interactive sub-shell),
> then run it again with bash -x, manually repeat the command that failed,
> investigate why it failed and hit Ctrl-d when I'm done.

Hi, I wasted a day to only notice that the problem was in busybox not
supporting 0.x value and that is what selfttest script use. Another
thing to check. Also the confusing part of this is that we don't check
if ping_do return error and the test just fails (while in reality the
ping command was never executed)

Anyway I'm fixing all kind of bugs and I even found an even hw
limitation with the FDB table with mgmt packet...

Also I implemented fdb_insolation following the implementation done on
felix with reserving VID at the end...
About this I wonder if it might be a good idea to expose some generic
API from DSA?

qca8k require a reserved VID for VLAN unaware port and with
fdb_isolation even more VID are reserved. DSA have no idea about this so
I wonder if there is a chance of VID clash? I feel like we need
something to declare a range of reserved VID so that they gets rejected
when applied. (about this I think I should return -EINVAL if fdb/mbd
insert are asked with a reserved VID)

Anyway by fixing that interval problem (enabling support in busybox as
it's disabled by default in a OpenWRT system)
This is the new output of the local_termination.sh 

TAP version 13
1..1
# selftests: drivers/net/dsa: local_termination.sh
# TEST: lan1: Unicast IPv4 to primary MAC address                     [ OK ]
# TEST: lan1: Unicast IPv4 to macvlan MAC address                     [ OK ]
# TEST: lan1: Unicast IPv4 to unknown MAC address                     [FAIL]
#       reception succeeded, but should have failed
# TEST: lan1: Unicast IPv4 to unknown MAC address, promisc            [ OK ]
# TEST: lan1: Unicast IPv4 to unknown MAC address, allmulti           [FAIL]
#       reception succeeded, but should have failed
# TEST: lan1: Multicast IPv4 to joined group                          [ OK ]
# TEST: lan1: Multicast IPv4 to unknown group                         [FAIL]
#       reception succeeded, but should have failed
# TEST: lan1: Multicast IPv4 to unknown group, promisc                [ OK ]
# 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                [ OK ]
# TEST: lan1: Multicast IPv6 to unknown group, allmulti               [ OK ]
# TEST: br0: Unicast IPv4 to primary MAC address                      [ OK ]
# TEST: br0: Unicast IPv4 to macvlan MAC address                      [ OK ]
# TEST: br0: Unicast IPv4 to unknown MAC address                      [FAIL]
#       reception succeeded, but should have failed
# TEST: br0: Unicast IPv4 to unknown MAC address, promisc             [ OK ]
# TEST: br0: Unicast IPv4 to unknown MAC address, allmulti            [FAIL]
#       reception succeeded, but should have failed
# 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                 [ OK ]
# 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                 [ OK ]
# TEST: br0: Multicast IPv6 to unknown group, allmulti                [ OK ]
not ok 1 selftests: drivers/net/dsa: local_termination.sh # exit=1

Seems good aside from the reception secceeded that I think the kernel
just drops right?

The switch have a way to control FLOOD per port but maybe the correct
feature to use is the VLAN leaky? Where the setting can be set by both
FDB/MBD and per port.

Sorry if I described some fix and implementation without proposing the
patch but I would like some comments on what the tool returned.

-- 
	Ansuel