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

D. Hugh Redelmeier hugh at mimosa.com
Mon Jul 2 17:12:19 UTC 2018


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.

================

testing/pluto/ikev1-impair-01-replay-duplicates failed east:output-different west:output-different

East diff:
 IMPAIR: start duplicate packet
-| "westnet-eastnet" #2: discarding duplicate packet; already STATE_QUICK_R2
+IMPAIR: stop duplicate packet
+IMPAIR: start duplicate packet
 IMPAIR: stop duplicate packet

West diff:

  grep 'duplicate packet' /tmp/pluto.log
-| "westnet-eastnet" #1: discarding duplicate packet; already STATE_MAIN_I4

Perhaps something has changed in duplicate packet handling.  Is the
new behaviour correct?

================

testing/pluto/nflog-01-global failed west:output-different

The ordering of some lines changed

- tcpdump

IP:

-IP 192.0.1.254 > 192.0.2.254: ICMP echo request, id XXXX, seq 1, length 64
-IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id XXXX, seq 1, length 64
 IP 192.0.1.254 > 192.0.2.254: ICMP echo request, id XXXX, seq 2, length 64
 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id XXXX, seq 2, length 64
 IP 192.0.1.254 > 192.0.2.254: ICMP echo request, id XXXX, seq 3, length 64
 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id XXXX, seq 3, length 64
 IP 192.0.1.254 > 192.0.2.254: ICMP echo request, id XXXX, seq 4, length 64
 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id XXXX, seq 4, length 64
+IP 192.0.1.254 > 192.0.2.254: ICMP echo request, id XXXX, seq 5, length 64
+IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id XXXX, seq 5, length 64



More information about the Swan-dev mailing list