https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14710/testReport/sys.netipsec.tunnel/empty/v4/ https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14710/testReport/sys.netipsec.tunnel/empty/v6/ stderr: Files left in work directory after failure: created_interfaces.lst, created_jails.lst, ipsec.ipsecA.conf, ipsec.ipsecB.conf ifconfig: interface epair0b does not exist ifconfig: interface epair1b does not exist ifconfig: interface epair2b does not exist ifconfig: interface epair3b does not exist
olivier, kp: I suspect that the ipsec config part of these tests may need to be adjusted, could you help check it? Thanks!
A commit references this bug: Author: lwhsu Date: Wed Apr 22 20:50:24 UTC 2020 New revision: 360204 URL: https://svnweb.freebsd.org/changeset/base/360204 Log: Temporarily skip sys.netipsec.tunnel.empty.v{4,6} in CI PR: 245832 Sponsored by: The FreeBSD Foundation Changes: head/tests/sys/netipsec/tunnel/empty.sh
Does it mean that r359374 removed the support of 'null' algo ? Because there is no reference to the removal of this algorithm in the commit message of r359374.
(In reply to Olivier Cochard from comment #3) > Does it mean that r359374 removed the support of 'null' algo ? I suspect but I am not 100% sure. jhb and cem, could you help check about this?
No, null should still be there, and I had tested using some setkey configurations with a null cipher, but is probably some sort of regression in r359374.
I just retested null on stock HEAD and it worked for me. I used the following setkey configurations: host with 172.16.0.1 interface: flush; spdflush; # Host to host ESP # Security Associations add 172.16.0.1 172.16.0.2 esp 0x10000 -E null 0xffff; add 172.16.0.2 172.16.0.1 esp 0x10001 -E null 0xffff; # Security Policies spdadd 172.16.0.1 172.16.0.2 any -P out ipsec esp/tunnel/172.16.0.1-172.16.0.2/require; spdadd 172.16.0.2 172.16.0.1 any -P in ipsec esp/tunnel/172.16.0.2-172.16.0.1/require; Host with 172.16.0.2 interface: flush; spdflush; # Host to host ESP # Security Associations add 172.16.0.1 172.16.0.2 esp 0x10000 -E null 0xffff; add 172.16.0.2 172.16.0.1 esp 0x10001 -E null 0xffff; # Security Policies spdadd 172.16.0.1 172.16.0.2 any -P in ipsec esp/tunnel/172.16.0.1-172.16.0.2/require; spdadd 172.16.0.2 172.16.0.1 any -P out ipsec esp/tunnel/172.16.0.2-172.16.0.1/require; I'll look to see what kind of setkey config files the test creates, but I didn't change any of the parsing for setkey in the OCF rework changes, and I would expect setkey to report an error to stderr (which it didn't from what I can tell) if it had a parse error or got an error back when trying to setup the SA.
kyua actively makes this hard to investigate. I can't get it to leave the setkey config files around (kyua debug only redirects stdout/stderr which is useless in this case). So, I ran the entire test under ktrace and used kdump to figure out what it wrote. It appears to have used an encryption key of "", and even though the test fails to report the error from setkey, trying that directly does error (so would be nice if we could get the test to report stderr output from jexec'd things to stderr): # setkey -f /mnt/jhb/work/git/netperf/IPSEC/Configs/source-null.conf The result of line 8: Invalid argument. The result of line 9: Invalid argument. But I'll track it down from here since I can reproduce.
A commit references this bug: Author: jhb Date: Sat May 2 01:00:30 UTC 2020 New revision: 360560 URL: https://svnweb.freebsd.org/changeset/base/360560 Log: Don't pass bogus keys down for NULL algorithms. The changes in r359374 added various sanity checks in sessions and requests created by crypto consumers in part to permit backend drivers to make assumptions instead of duplicating checks for various edge cases. One of the new checks was to reject sessions which provide a pointer to a key while claiming the key is zero bits long. IPsec ESP tripped over this as it passes along whatever key is provided for NULL, including a pointer to a zero-length key when an empty string ("") is used with setkey(8). One option would be to teach the IPsec key layer to not allocate keys of zero length, but I went with a simpler fix of just not passing any keys down and always using a key length of zero for NULL algorithms. PR: 245832 Reported by: CI Changes: head/sys/netipsec/xform_ah.c head/sys/netipsec/xform_esp.c
I've committed a fix. All of the IPsec tunnel tests pass for me now. I'll let Li-wen re-enable the tests after verifying the fix.
Fix verified. Thanks!
A commit references this bug: Author: lwhsu Date: Mon May 4 11:23:56 UTC 2020 New revision: 360626 URL: https://svnweb.freebsd.org/changeset/base/360626 Log: Revert r360204, sys.netipsec.tunnel.empty.v{4,6} are fixed by r360560 PR: 245832 Sponsored by: The FreeBSD Foundation Changes: head/tests/sys/netipsec/tunnel/empty.sh