On Fri, 27 Mar 2020 at 09:33, Andrew Cagney <[email protected]> wrote:
> > > On Mon, 24 Feb 2020 at 09:57, Andrew Cagney <[email protected]> > wrote: > >> On Mon, 24 Feb 2020 at 09:45, Paul Wouters <[email protected]> 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: > > ... and it turns out the cause was a missing impair-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@0x7f22aa646fc8 > | inserting event EVENT_RETRANSMIT, timeout in 0.5 seconds for #2 > | libevent_malloc: newref ptr-libevent@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 >> >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
