* Regression in add xfrm interface
@ 2022-03-07 20:11 Stephen Hemminger
2022-03-08 7:50 ` Steffen Klassert
0 siblings, 1 reply; 5+ messages in thread
From: Stephen Hemminger @ 2022-03-07 20:11 UTC (permalink / raw)
To: David Ahern, Steffen Klassert, Herbert Xu; +Cc: netdev
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]
test on: "dev-dSwSKP" [FAILED]
test on: "if_id 0xf" [FAILED]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression in add xfrm interface
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
0 siblings, 1 reply; 5+ messages in thread
From: Steffen Klassert @ 2022-03-08 7:50 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Ahern, Herbert Xu, netdev, Eyal Birger, Antony Antony
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression in add xfrm interface
2022-03-08 7:50 ` Steffen Klassert
@ 2022-03-08 13:51 ` Antony Antony
2022-03-08 16:45 ` Stephen Hemminger
2022-03-09 7:08 ` Stephen Hemminger
0 siblings, 2 replies; 5+ messages in thread
From: Antony Antony @ 2022-03-08 13:51 UTC (permalink / raw)
To: Steffen Klassert
Cc: Stephen Hemminger, David Ahern, Herbert Xu, netdev, Eyal Birger,
Antony Antony
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.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression in add xfrm interface
2022-03-08 13:51 ` Antony Antony
@ 2022-03-08 16:45 ` Stephen Hemminger
2022-03-09 7:08 ` Stephen Hemminger
1 sibling, 0 replies; 5+ messages in thread
From: Stephen Hemminger @ 2022-03-08 16:45 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, David Ahern, Herbert Xu, netdev, Eyal Birger
On Tue, 8 Mar 2022 14:51:30 +0100
Antony Antony <antony.antony@secunet.com> wrote:
> 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?
>
This is testsuite in iproute2. Please submit a patch to fix it.
This is not a Debian test.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression in add xfrm interface
2022-03-08 13:51 ` Antony Antony
2022-03-08 16:45 ` Stephen Hemminger
@ 2022-03-09 7:08 ` Stephen Hemminger
1 sibling, 0 replies; 5+ messages in thread
From: Stephen Hemminger @ 2022-03-09 7:08 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, David Ahern, Herbert Xu, netdev, Eyal Birger,
Matt Ellison
On Tue, 8 Mar 2022 14:51:30 +0100
Antony Antony <antony.antony@secunet.com> wrote:
> 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.
> >
The test is here please update as appropriate:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/testsuite/tests/ip/link/add_type_xfrm.t
And was added by:
commit 286446c1e8c7f5f6eca4959015aa9e482b7adb11
Author: Matt Ellison <matt@arroyo.io>
Date: Thu Apr 4 10:08:45 2019 -0400
ip: support for xfrm interfaces
Interfaces take a 'if_id' which is an interface id which can be set on
an xfrm policy as its interface lookup key (XFRMA_IF_ID).
Signed-off-by: Matt Ellison <matt@arroyo.io>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-03-09 7:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2022-03-08 16:45 ` Stephen Hemminger
2022-03-09 7:08 ` Stephen Hemminger
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).