[Swan-dev] ikev2-14-missing-ke test failure

[D. Hugh Redelmeier]

| From: Paul Wouters <paul at nohats.ca>
| 
| > On Dec 29, 2014, at 02:10, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
| > 
| > In my recent run, west's console output doesn't match the reference 
| > output.  Here's an extract:
| > 
| > 133 "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
| > +002 "westnet-eastnet-ipv4-psk-ikev2" #1: supressing retransmit because IMPAIR_RETRANSMITS is set.
| > 002 "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_PARENT_I1: received unauthenticated v2N_INVALID_SYNTAX - ignored
| > -002 "westnet-eastnet-ipv4-psk-ikev2" #1: supressing retransmit because IMPAIR_RETRANSMITS is set
| > -031 "westnet-eastnet-ipv4-psk-ikev2" #1: max number of retransmissions (0) reached STATE_PARENT_I1.  No response (or no acceptable response) to our first IKEv2 me!
| > -002 "westnet-eastnet-ipv4-psk-ikev2" #1: deleting state #1 (STATE_PARENT_I1)
| > -west #
| > +^C#\[root at west ]#  timedout send line: ipsec auto --up  westnet-eastnet-ipv4-psk-ikev2
| >  echo done
| > -done
| > 
| > and from here on there is a serious divergence.
| > 
| > Is this expected?  Is this a bug that I've introduced?
| > 
| > A similar failure occurs in:
| > ikev2-major-version-initiator
| > ikev2-major-version-responder
| > ikev2-allow-narrow-02
| > basic-pluto-15-no-retransmit
| > and possibly others.

| Yes I have this problem too in master. Despite --no-retransmits the whack is not released in time.

I knew that.  I was testing master.  What I asked was whether that's
something I did.  I don't think so but I'm not sure.

Others might know better or have better tools to find out.

In particular, Antony has created an infrastructure to look back at
past runs.  Unfortunately, I don't know/remember how to use that or
what the past runs actually tested.

| But Antony will be working on reducing g the timers in the next few weeks, so this problem will resolve itself :)

Changing timers, while a Good Thing, does not address logical
problems.  If there are logical problems.

I don't understand the test, don't know why it is changed, and hoped
someone else did.

(Earlier puzzle: why did the "supressing retransmit because IMPAIR_RETRANSMITS
is set." come earlier in the new log?)

I don't want to figure this out if someone already knows this.  I
don't want to figure it out if someone intentionally changed this.
If I do have to figure it out, I want to know whether I'm to look in
my recent changes or in someone elses changes.

This is the whole point of cleaning up your own messes (i.e. test
failures you introduce): other folks don't have to puzzle them out.

I don't even know that I didn't introduce this mess, so that was the
point of the original post (still no answer).  It was one of a burst
of postings about messes left in our test suite.

Summary of the meta-point: everyone seems to understand that breaking
the build is to be avoided; I consider causing tests to fail to be
breaking the build.