Hi Hugh, I will share what I stumbled up on and my suspicious commit.
On Mon, Jul 02, 2018 at 01:12:19PM -0400, D. Hugh Redelmeier wrote: > I noticed that some tests have started failing recently. I haven't looked > carefully into why they fail. > > My baseline was a run that seems to have been > v3.22-1715-gc22eea8cd-master (if I read my logging correctly). > > Could whoever caused these fix them? It would help the rest of us. > > I don't think that I caused any of these. If you disagree, please tell me. > > ================ > > A bunch of certificate tests failed. I don't know why. (There is a > chance that this is my fault.) > > I'm looking at certoe-03-poc-whack for now, assuming all are similar. > > The packet where things seem to go wrong came from road. > In both runs, the packets are SA, KE, Notify, Notify, Notify. > The old run had a Vendor ID payload at the end but the new one does > not. > > Each of the payloads has the same length in the old and new runs' > packets. So they are pretty similar. > > The Vendor ID payload is interpreted by the old run: > | received Vendor ID payload [Opportunistic IPsec] > > The failure is noted with this in east.pluto.log: > > | initial parent SA message received on 192.1.2.23:500 but no connection has > been authorized with policy AUTHNULL+IKEV2_ALLOW > packet from 192.1.3.209:500: initial parent SA message received on > 192.1.2.23:500 but no suitable connection found with IKEv2 policy > > The old run isn't exactly comparable, but this looks relevant: > | found connection: clear-or-private#192.1.3.0/24[1] ...192.1.3.209 with > policy RSASIG+IKEV2_ALLOW > > So why do the runs think that the authorization technique is different? > > find_next_host_connection() pours out a lot of logging. At the top of its > outer loop, it logs "found policy =" for each connection examined. In the > old run, the first ones include RSASIG but in the old run they do not. > I suspect that this is the root of the problem. I stumbled on something similar and from a quick look pointed me to the commit 1dbc99118f . The test passed in v3.25 NOTE: I followed a slightly different test. I think it is the same issue. Passed https://swantest.libreswan.fi/results/blackswan/2018-06-27-swantest-3.25-1-gad5ba687e-master/rawrsaoe-asymmetric-01/OUTPUT/east.pluto.log Failed: https://swantest.libreswan.fi/results/blackswan/2018-06-28-swantest-3.25-31-g78dc1a2ff-master/rawrsaoe-asymmetric-01/OUTPUT/east.pluto.log I noticed a few, 20 or so, asymetric, certoe*, and dnsoe* tests failed. All possibly same cause. -antony _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
