[Swan-dev] Converting all test cases to not use ipsec.conf.common

[Andrew Cagney]

Here's a 'newbie' view:

On 2 October 2017 at 22:10, Paul Wouters <paul at nohats.ca> wrote:

> On Mon, 2 Oct 2017, D. Hugh Redelmeier wrote:
>
> | We have talked about this in the past, but before I go ahead, I wanted
>> | to ask if anyone objects to the test cases being converted to standalone
>> | configuration files that no longer use or need ipsec.conf.common.
>>
>> | The disadvantage is that any changes that upto now could be made in an
>> | also= conn that is included would effect all the conns that use it.
>>
>> This is a very late comment.  Sorry. [I deleted all my excuses.]
>>
>> It is also theoretical.  I don't often look at the details of the test
>> configurations.
>>
>> I think that saying something once, in one place, is a lot better than
>> smearing it over a lot of locations.  That means that any bug fix or
>> change will be consistently applied.
>>
>
> [ remainder of arguming about good also= discipline ]
>
> I think you are missing the point. The idea is that by NOT using any
> also= statements, all test cases become defacto documentation/examples we
> can point to. Right now, the test cases cannot be used as documentation
> because endusers cannot follow the maze of also's to extract a meaningful
> configuration example.
>

I still don't know the correct way to set up a basic configuration
(technically I know the wrong way to set up a basic configuration - by
driving whack directly).  What should require just a few lines gets lost in
multiple levels of indirection, each adding stuff I suspect isn't needed.

For the timeout stuff I started out with also=slow-retransmits, but then
found that a significant percentage of tests couldn't access it - road
tests get minimal configurations - so I went through and inlined
everything.  I don't think this is an issue as, by applying a little
discipline (a.k.a. sed), they all looked like:
    retransmit-interval=2000 # slow retransmits
(I now see some of the values have been increased to 15000, fixing :-)

Andrew

PS: slow-retransmits is interesting for another reason, there's an impair
mechanism that almost does the right thing - it fails because it
(correctly) logs that it impaired the re-transmit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20171003/51c578b9/attachment.html>