[Swan-dev] drop ipsec-auto-up.n.sed

[Andrew Cagney]

On Mon, 28 Sep 2020 at 15:11, Antony Antony <antony at phenome.org> wrote:

> On Mon, Sep 28, 2020 at 12:44:03PM -0400, Andrew Cagney wrote:
> > I'm planning on removing the sanitizer ipsec-auto-up.n.sed.  It removes
> what I
> > consider to be important contextual  information from console.txt.  For
> > instance, consider this output:
>
> I think it is a usefull swanitizer. May be tweak need more tweaking, also
> it
> can be skiped easly; see bellow.
>

It's a bandaid hiding non-deterministic behaviour.

Either the re-transmit is relevant, and it should be retained, but made
more robust; or the retransmit is not relevant and can be suppressed.  This
sanitizer does neither.  It removes half the exchange obfuscating the
output.  For instance, when nss-cert-crl-03-strict fails it produces this
diff:

https://testing.libreswan.org/v3.30-1834-g8b42ce739b-main/nss-cert-crl-03-strict/OUTPUT/west.console.diff

--- MASTER/testing/pluto/nss-cert-crl-03-strict/west.console.txt
+++ OUTPUT/testing/pluto/nss-cert-crl-03-strict/west.console.txt
@@ -41,8 +41,6 @@
 1v1 "nss-cert-crl" #1: sent Main Mode I3
 003 "nss-cert-crl" #1: ignoring informational payload
INVALID_ID_INFORMATION, msgid=00000000, length=12
 003 "nss-cert-crl" #1: received and ignored notification payload:
INVALID_ID_INFORMATION
-003 "nss-cert-crl" #1: ignoring informational payload
INVALID_ID_INFORMATION, msgid=00000000, length=12
-003 "nss-cert-crl" #1: received and ignored notification payload:
INVALID_ID_INFORMATION
 002 "nss-cert-crl" #1: Peer ID is ID_DER_ASN1_DN: 'C=CA, ST=Ontario,
L=Toronto, O=Libreswan, OU=Test Department,
CN=east.testing.libreswan.org, E=user-east at testing.libreswan.org'
 002 "nss-cert-crl" #1: certificate verified OK:
E=user-east at testing.libreswan.org,CN=east.testing.libreswan.org,OU=Test
Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA
 003 "nss-cert-crl" #1: authenticated using RSA with SHA-1

so per my point:

> --- MASTER/testing/pluto/nss-cert-crl-03-strict/west.console.txt
> > +++ OUTPUT/testing/pluto/nss-cert-crl-03-strict/west.console.txt
> > @@ -41,8 +41,10 @@
> >  1v1 "nss-cert-crl" #1: sent Main Mode I3
> >  003 "nss-cert-crl" #1: ignoring informational payload
> INVALID_ID_INFORMATION,
> > msgid=00000000, length=12
> >  003 "nss-cert-crl" #1: received and ignored notification payload:
> > INVALID_ID_INFORMATION
> >  003 "nss-cert-crl" #1: ignoring informational payload
> INVALID_ID_INFORMATION,
> > msgid=00000000, length=12
> >  003 "nss-cert-crl" #1: received and ignored notification payload:
> > INVALID_ID_INFORMATION
> >  002 "nss-cert-crl" #1: Peer ID is ID_DER_ASN1_DN: 'C=CA, ST=Ontario, L=
> > Toronto, O=Libreswan, OU=Test Department, CN=east.testing.libreswan.org,
> E=
> > user-east at testing.libreswan.org'
> >  002 "nss-cert-crl" #1: certificate verified OK: E=
> > user-east at testing.libreswan.org,CN=east.testing.libreswan.org,OU=Test
> > Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA
> >  003 "nss-cert-crl" #1: authenticated using RSA with SHA-1
> >
> > the duplicate "ignoring informational payload" seems to be from the
> other end
> > spontaneously sending duplicates (this is IKEv1 after all), and things
> take
> > time to establish because the other end was slow.  However, once
> retransmits
> > are visible:
> >
> > --- MASTER/testing/pluto/nss-cert-crl-03-strict/west.console.txt
> > +++ OUTPUT/testing/pluto/nss-cert-crl-03-strict/west.console.txt
> > @@ -41,8 +41,10 @@
> >  1v1 "nss-cert-crl" #1: sent Main Mode I3
> >  003 "nss-cert-crl" #1: ignoring informational payload
> INVALID_ID_INFORMATION,
> > msgid=00000000, length=12
> >  003 "nss-cert-crl" #1: received and ignored notification payload:
> > INVALID_ID_INFORMATION
> > +010 "nss-cert-crl" #1: STATE_MAIN_I3: retransmission; will wait 0.5
> seconds
> > for response
> >  003 "nss-cert-crl" #1: ignoring informational payload
> INVALID_ID_INFORMATION,
> > msgid=00000000, length=12
> >  003 "nss-cert-crl" #1: received and ignored notification payload:
> > INVALID_ID_INFORMATION
> > +010 "nss-cert-crl" #1: STATE_MAIN_I3: retransmission; will wait 1
> seconds for
> > response
> >  002 "nss-cert-crl" #1: Peer ID is ID_DER_ASN1_DN: 'C=CA, ST=Ontario, L=
> > Toronto, O=Libreswan, OU=Test Department, CN=east.testing.libreswan.org,
> E=
> > user-east at testing.libreswan.org'
> >  002 "nss-cert-crl" #1: certificate verified OK: E=
> > user-east at testing.libreswan.org,CN=east.testing.libreswan.org,OU=Test
> > Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA
> >  003 "nss-cert-crl" #1: authenticated using RSA with SHA-1
> >
> > it looks more likely that the re-transmit triggered forward progress.
> > Similarly, but in contrast:
>
> I guess you are saying in this test retransmits is expected.
> Change the "up" line to something like the following
>
> ipsec auto --up nss-cert-crl #retransmits
>
>
And it does not help.  The test is still non-deterministic - it will
pass/fail dependent on timing.

While you can certainly selectively use this sanitizer for specific cases,
please don't apply it across all tests.  The last thing needed is for
critical output - notably that a retransmit occured - to magically
disappear.


and the sanitizer would leave the output alone.
>
> > --- MASTER/testing/pluto/ikev2-keyingtries-01/west.console.txt
> > +++ OUTPUT/testing/pluto/ikev2-keyingtries-01/west.console.txt
>
> as far as I see this test also need #retransmits after the up.
> So these two test cases could be fixed!
>
> PS: previous discussion:
> https://lists.libreswan.org/pipermail/swan-dev/2020-February/003664.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200928/7073f012/attachment-0001.html>