On Mon, 21 Jan 2019, Paul Wouters wrote:
- ikev2-26-keyingtries
Fixed - it used the wrong EVENT type
- interop-ikev2-strongswan-04-x509-responder-certreq
Deleted. The test was wrong. It tested receiving certreq on responder, but it is responder that first should send sendreq.
- newoe-27-replace-sa (cannot install eroute -- it is in use)
There are two test cases, newoe-27-replace-sa and newoe-27-replace-sa-authnull. It was confusing. I had renamed them but only afterwards realised it was wrong and renamed them back. in the current names, newoe-27-replace-sa-authnull starts an authenticated conn, kills pluto and then starts a similar anonymous ipsec conn. east should not replace the authenticated conn with an unauthenticated one. this works properly. In the test case newoe-27-replace-sa an unauthenticated tunnel is replaced with an identical unauthenticated one. This does not work properly. The second tunnel gets "cannot install eroute" and fails to replace the conn. Git bisect shows the problem is caused by commit d3a455723a7c13ce
- netkey-vti-09: lies about different marks on different conns but marks are not different
I fixed up some changed output, but the updown script is lying. The two conns are identical for mark/VTI and should be sharable but it says it cannot? Tuomo? Check or leave until xfrmi interfaces?
- ikev2-55-ipseckey* test fail to find key even after regenerating DNSSEC?
Did not have a look at these yet.
- ikev2-03-basic-rawrsa-ckaid bug in CKAID code ?
It's a bug, but after talking to Andrew seems it is not a regression. This has never worked properly. So this is no longer a blocker bug.
- ikev2-child-01-pfs-no-downgrade-no new failure of conn supposed to come up
This also seems to have never worked properly? One connection test is commented out and one conn that should come up fails. I think there might be an issue of first conn with IKE settings versus other conn's IKE settings. It might be better to split this into separate tests, and bring up each conn and then on east do a rekey via --up. Then, a new bug I found, which we also must have had since the beginning of supporting ipcomp with xfrm is that we do not clean up all the compression state on delete. an xfrm state and policy lingers afterwards. This should be fixed before release. Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
