Messages in this thread | | | Date | Wed, 28 Jun 2023 02:53:35 +0200 | From | Christian Marangi <> | Subject | Re: [net-next PATCH RFC] net: dsa: qca8k: make learning configurable and keep off if standalone |
| |
On Wed, Jun 28, 2023 at 02:49:53AM +0200, Christian Marangi wrote: > 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) >
Also sorry for the double email... I forgot to add that it seems I need to add a sleep 1 right after
mc_route_prepare $h1 mc_route_prepare $rcv_if_name
in local_termination.sh. Think the switch needs some time to enable all the port. Without the sleep 1 the first test just fails.
> 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
-- Ansuel
| |