* 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).