[Swan-dev] regressions since v3.22-1715-gc22eea8cd-master

[Antony Antony]

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