https://ci.freebsd.org/job/FreeBSD-head-amd64-test/15309/testReport/junit/sys.netipsec.tunnel/ sys.netipsec.tunnel.aes_cbc_128_hmac_sha1.v4 sys.netipsec.tunnel.aes_cbc_256_hmac_sha2_256.v4 sys.netipsec.tunnel.aesni_aes_cbc_128_hmac_sha1.v4 sys.netipsec.tunnel.aesni_aes_cbc_256_hmac_sha2_256.v4 Did some manual testing, the setkey command results 0, but the ipsec connection is not setup.
jhb: does it look related to the recent update of separate output buffers to in-kernel crypto?
A commit references this bug: Author: lwhsu Date: Tue May 26 06:55:04 UTC 2020 New revision: 361497 URL: https://svnweb.freebsd.org/changeset/base/361497 Log: Disable failing test cases in CI: sys.netipsec.tunnel.aes_cbc_128_hmac_sha1.v4 sys.netipsec.tunnel.aes_cbc_256_hmac_sha2_256.v4 sys.netipsec.tunnel.aesni_aes_cbc_128_hmac_sha1.v4 sys.netipsec.tunnel.aesni_aes_cbc_256_hmac_sha2_256.v4 PR: 246737 Sponsored by: The FreeBSD Foundation Changes: head/tests/sys/netipsec/tunnel/aes_cbc_128_hmac_sha1.sh head/tests/sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256.sh head/tests/sys/netipsec/tunnel/aesni_aes_cbc_128_hmac_sha1.sh head/tests/sys/netipsec/tunnel/aesni_aes_cbc_256_hmac_sha2_256.sh
I will look.
"Jexec" seems like it would make this less unit-test-ey than necessary. I agree it is probably related to recent OCF changes.
The failures are before r361507, but I would not anticipate that change fixing the issue; the change is for CTR mode, and the failing tests are CBC mode.
Hmm, my simple tests of aes-cbc with sha1 hmac with setkey work fine. The vnet test cases are pretty much impossible to work with though. You can't have them leave the jails around after they are setup to see what it is trying to do, or to redo the ping under dtrace, etc. Something like poudriere testport -i where you could pause a test before it runs the teardown steps would be great, but kyua doesn't seem designed to support any debugging other than printf to stdout.
A commit references this bug: Author: jhb Date: Fri May 29 05:41:22 UTC 2020 New revision: 361617 URL: https://svnweb.freebsd.org/changeset/base/361617 Log: Increment the correct pointer when a crypto buffer spans an mbuf or iovec. When a crypto_cursor_copyback() request spanned multiple mbufs or iovecs, the pointer into the mbuf/iovec was incremented instead of the pointer into the source buffer being copied from. PR: 246737 Reported by: Jenkins, ZFS test suite Sponsored by: Netflix Changes: head/sys/opencrypto/criov.c
A commit references this bug: Author: lwhsu Date: Fri May 29 10:09:48 UTC 2020 New revision: 361623 URL: https://svnweb.freebsd.org/changeset/base/361623 Log: Revert r361497, these cases are fixed by r361617. PR: 246737 Sponsored by: The FreeBSD Foundation Changes: head/tests/sys/netipsec/tunnel/aes_cbc_128_hmac_sha1.sh head/tests/sys/netipsec/tunnel/aes_cbc_256_hmac_sha2_256.sh head/tests/sys/netipsec/tunnel/aesni_aes_cbc_128_hmac_sha1.sh head/tests/sys/netipsec/tunnel/aesni_aes_cbc_256_hmac_sha2_256.sh