[Swan-dev] sanitize retransmission; will wait line

[Andrew Cagney]

On Mon, 24 Feb 2020 at 09:57, Andrew Cagney <andrew.cagney at gmail.com> wrote:

> On Mon, 24 Feb 2020 at 09:45, Paul Wouters <paul at nohats.ca> wrote:
> >
> > On Mon, 24 Feb 2020, Andrew Cagney wrote:
> >
> > >  suppress-retransmits: causes pluto to never send retransmits (wait
> > > the full timeout)
> >
> > I'm not fully convinced this works on IKEv1?
>
>
It's IKEv1 quick mode, this turned up locally in impair-09-protected-ikev1
which suppresses retransmits:

| #2 STATE_QUICK_I1: retransmits: first event in 0.5 seconds; timeout in 60
seconds; limit of 12 retransmits; current time is 40.785424
"westnet-eastnet" #2: STATE_QUICK_I1: sent QI1, expecting QR1
| IKEv1 retransmit event
| retransmits: current time 41.29116; retransmit count 0 exceeds limit? NO;
deltatime 0.5 exceeds limit? NO; monotime 0.505736 exceeds limit? NO
| event_schedule: newref EVENT_RETRANSMIT-pe at 0x7f22aa646fc8
| inserting event EVENT_RETRANSMIT, timeout in 0.5 seconds for #2
| libevent_malloc: newref ptr-libevent at 0x7f22aa520f78 size 128
"westnet-eastnet" #2: STATE_QUICK_I1: retransmission; will wait 0.5 seconds
for response


> Could be true.  IKEv1 is calling start_retransmits(st) but there could
> be a missing case.
> Grepping for 'retransmits:' might offer some insight.
>
> > I was porting ikev2-xfrmi-* to ikev1 and got retransmits despite
> > both end having the impair set.
> >
> > Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200327/0cd118ce/attachment.html>