Re: [PROBLEM] selftests: net/forwarding/*.sh: 'Command line is not complete. Try option "help"'

[Mirsad Todorovac]

On 7/19/23 14:59, Ido Schimmel wrote:
> On Tue, Jul 18, 2023 at 08:39:33PM +0200, Mirsad Todorovac wrote:
> > There is also a gotcha here: you do not delete all veths:
> >
> > root@defiant:# ip link show
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> >      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: enp16s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
> >      link/ether 9c:6b:00:01:fb:80 brd ff:ff:ff:ff:ff:ff
> > root@defiant:# ./bridge_igmp.sh
>
> [...]
>
> > root@defiant:# ip link show
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> >      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: enp16s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
> >      link/ether 9c:6b:00:01:fb:80 brd ff:ff:ff:ff:ff:ff
> > 3: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> >      link/ether b6:46:e6:4c:e4:00 brd ff:ff:ff:ff:ff:ff
> > 4: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> >      link/ether 2e:ff:7f:8a:6b:d4 brd ff:ff:ff:ff:ff:ff
> > 5: veth3@veth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> >      link/ether ba:33:37:81:dc:5b brd ff:ff:ff:ff:ff:ff
> > 6: veth2@veth3: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
> >      link/ether f2:fd:0a:9b:94:17 brd ff:ff:ff:ff:ff:ff
> > root@defiant:#
>
> These tests can be run with veth pairs or with loop backed physical
> ports. We can't delete the latter and I don't see a clean way to delete
> the veth pairs.
>
> The following patch [1] changes the default to not create interfaces so
> that by default these tests will be skipped [2]. Those who care about
> running the tests can create a forwarding.config file (using
> forwarding.config.sample as an example) and either create the veth pairs
> themselves or opt-in for the interfaces to be created automatically
> (setting NETIF_CREATE=yes), but not deleted.
>
> [1]
> diff --git a/tools/testing/selftests/net/forwarding/forwarding.config.sample b/tools/testing/selftests/net/forwarding/forwarding.config.sample
> index 4a546509de90..b72f08dfd491 100644
> --- a/tools/testing/selftests/net/forwarding/forwarding.config.sample
> +++ b/tools/testing/selftests/net/forwarding/forwarding.config.sample
> @@ -36,8 +36,9 @@ PAUSE_ON_FAIL=no
>   PAUSE_ON_CLEANUP=no
>   # Type of network interface to create
>   NETIF_TYPE=veth
> -# Whether to create virtual interfaces (veth) or not
> -NETIF_CREATE=yes
> +# Whether to create virtual interfaces (veth) or not. Created interfaces are
> +# not automatically deleted
> +NETIF_CREATE=no
>   # Timeout (in seconds) before ping exits regardless of how many packets have
>   # been sent or received
>   PING_TIMEOUT=5
> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
> index 9ddb68dd6a08..1b1bc634c63e 100755
> --- a/tools/testing/selftests/net/forwarding/lib.sh
> +++ b/tools/testing/selftests/net/forwarding/lib.sh
> @@ -17,7 +17,7 @@ WAIT_TIME=${WAIT_TIME:=5}
>   PAUSE_ON_FAIL=${PAUSE_ON_FAIL:=no}
>   PAUSE_ON_CLEANUP=${PAUSE_ON_CLEANUP:=no}
>   NETIF_TYPE=${NETIF_TYPE:=veth}
> -NETIF_CREATE=${NETIF_CREATE:=yes}
> +NETIF_CREATE=${NETIF_CREATE:=no}
>   MCD=${MCD:=smcrouted}
>   MC_CLI=${MC_CLI:=smcroutectl}
>   PING_COUNT=${PING_COUNT:=10}
>
> [2]
> # ./bridge_igmp.sh
> SKIP: could not find all required interfaces

Hi, Ido,

Please would you consider making a formal patch, so the vanilla 'make kselftest'
run would have some sensible defaults?

I am really interested in the network stack working right, though I really do
not have much opportunities testing like high speed links and bonded eth adapters :-(

Maybe that'll come :-/

Kind regards,
Mirsad