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

[Antony Antony]

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.

Without it, there was too much noise due to jitter from kvm,
slow vs fast test servers. Previously I would see a lot of noise (40-120 
tests when there ~600 tests).
Also before this sanitizer it was hard to commit output I generate from a 
testrun on a slower server. Because it would have those retransmit lines.  
After this sanitizer I haven't noticed much noise.

I also recollect Hugh was seeing many tests failing due to Retranmits.  
Hugh, do you still notice them? He had his own post porocessing for it.

tweakng the sanitizer is probably better than removing.

> --- 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 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