From: Antony Antony <antony.antony@secunet.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
David Ahern <dsahern@gmail.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
<netdev@vger.kernel.org>, Eyal Birger <eyal.birger@gmail.com>,
Antony Antony <antony.antony@secunet.com>
Subject: Re: Regression in add xfrm interface
Date: Tue, 8 Mar 2022 14:51:30 +0100 [thread overview]
Message-ID: <YidTpIty2fVKTBzM@moon.secunet.de> (raw)
In-Reply-To: <20220308075013.GD1791239@gauss3.secunet.de>
Hi Stephen,
As Steffen explained bellow if_id = 0 is likely to cause problems in the long
term. Should we revert the commit because it broke userspace tools?
I notice the Debian bug is in a iproute2 testsuite, also it is in Debian testing! How about fixing test case than reverting the kernel commit?
Another option is revert the commit in current kernel development cycle.
And send the same fix to ipsec-next without "Fixes" tag.
Would that be acceptable for Debian testsuite usecase?
regards,
-antony
On Tue, Mar 08, 2022 at 08:50:13 +0100, Steffen Klassert wrote:
> On Mon, Mar 07, 2022 at 12:11:23PM -0800, Stephen Hemminger wrote:
> > There appears to be a regression between 5.10 (Debian 11) and 5.16 (Debian testing)
> > kernel in handling of ip link xfrm create. This shows up in the iproute2 testsuite
> > which now fails. This is kernel (not iproute2) regression.
> >
> >
> > Running ip/link/add_type_xfrm.t [iproute2-this/5.16.0-1-amd64]: FAILED
> >
> >
> > Good log:
> > ::::::::::::::
> > link/add_type_xfrm.t.iproute2-this.out
> > ::::::::::::::
> > [Testing Add XFRM Interface, With IF-ID]
> > tests/ip/link/add_type_xfrm.t: Add dev-ktyXSm xfrm interface succeeded
> > tests/ip/link/add_type_xfrm.t: Show dev-ktyXSm xfrm interface succeeded with output:
> > 2: dev-ktyXSm@lo: <NOARP,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> > link/none promiscuity 0 minmtu 68 maxmtu 65535
> > xfrm if_id 0xf addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> > test on: "dev-ktyXSm" [SUCCESS]
> > test on: "if_id 0xf" [SUCCESS]
> > tests/ip/link/add_type_xfrm.t: Del dev-ktyXSm xfrm interface succeeded
> > [Testing Add XFRM Interface, No IF-ID]
> > tests/ip/link/add_type_xfrm.t: Add dev-tkUDaA xfrm interface succeeded
> > tests/ip/link/add_type_xfrm.t: Show dev-tkUDaA xfrm interface succeeded with output:
> > 3: dev-tkUDaA@lo: <NOARP,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> > link/none promiscuity 0 minmtu 68 maxmtu 65535
> > xfrm if_id 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> > test on: "dev-tkUDaA" [SUCCESS]
> > test on: "if_id 0xf" [SUCCESS]
> > tests/ip/link/add_type_xfrm.t: Del dev-tkUDaA xfrm interface succeeded
> >
> > Failed log:
> >
> > [Testing Add XFRM Interface, With IF-ID]
> > tests/ip/link/add_type_xfrm.t: Add dev-pxNsUc xfrm interface succeeded
> > tests/ip/link/add_type_xfrm.t: Show dev-pxNsUc xfrm interface succeeded with output:
> > 2: dev-pxNsUc@lo: <NOARP,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> > link/none promiscuity 0 minmtu 68 maxmtu 65535
> > xfrm if_id 0xf addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> > test on: "dev-pxNsUc" [SUCCESS]
> > test on: "if_id 0xf" [SUCCESS]
> > tests/ip/link/add_type_xfrm.t: Del dev-pxNsUc xfrm interface succeeded
> > [Testing Add XFRM Interface, No IF-ID]
>
> No IF-ID is an invalid configuration, the interface does not work
> with IF-IF 0. Such an interface will blackhole all packets routed
> to it. That is because policies and states with no IF-ID are meant
> for a setup without xfrm interfaces, they will not match the interface.
>
> Unfortunately we did not catch this invalid configuration from the
> beginning and userspace seems to use (or do some tests tests with)
> xfrm interfaces with IF-ID 0. In that case, I fear we eventually
> have to revert the cange that catches the invalid configuration.
>
next prev parent reply other threads:[~2022-03-08 14:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 20:11 Regression in add xfrm interface Stephen Hemminger
2022-03-08 7:50 ` Steffen Klassert
2022-03-08 13:51 ` Antony Antony [this message]
2022-03-08 16:45 ` Stephen Hemminger
2022-03-09 7:08 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YidTpIty2fVKTBzM@moon.secunet.de \
--to=antony.antony@secunet.com \
--cc=dsahern@gmail.com \
--cc=eyal.birger@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).