On Tue, 3 Oct 2017, Andrew Cagney wrote:
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.
Which is a good reason for turning the test cases into better documentation by writing things out.
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
The impair is meant for those cases where we expect a failure to happen. A connection that is supposed to not work. In real life deployments, we must (eternally) keep trying, but for within the test case we want to confirm and abort. That's the only time the impair for retransmits should be used. Well mostly, I also use it when I know there is a bug causing a failure, and while working on it I add it so the test failure doesn't take many minutes. But once the bug is fixed, the impair should no longer be in place. slow-retransmits is a "hack" to prevent false positives on "harmless" retransmits that cause output changes. Ideally, we would fix these without changing the configuration. But we would have to be sure to not filter these out for those tests where it matters. This is a hard problem. It is not only the retransmit output of another line for the re-send. It also changes all the packet counters, so the output change bleeds into everything. Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
