Due to the exponential backoff a high number of retransmits only
makes sense if retransmit_limit is set. However, even with that there
was a problem.
We first calculated the timeout for the next retransmit and only then
compared that to the configured limit. Depending on the configured
base and timeout the calculation overflowed the range of uint32_t after
a relatively low number of retransmits (with the default values after 23)
causing the timeout to first get lower (on a high level) before constantly
resulting in 0 (with the default settings after 60 retransmits).
Since that's obviously lower than any configured limit, all remaining
retransmits were then sent without any delay, causing a lot of concurrent
messages if the number of retransmits was high.
This change determines the maximum number of retransmits until an
overflow occurs based on the configuration and defaults to UINT32_MAX
if that value is exceeded. Note that since the timeout is in milliseconds
UINT32_MAX equals nearly 50 days.
The calculation in task_manager_total_retransmit_timeout() uses a double
variable and the result is in seconds so the maximum number would be higher
there (with the default settings 1205). However, we want its result to
be based on the actual IKE retransmission behavior.
Having the inherit() function delayed to the IKE_SA establish procedure
was problematic. The task destroy function was never a good place and
results in locking/cleanup problems. After establishing the SA, it
should be really checked in ASAP to avoid any triggered DPD checks
to get lost.
This output helps tracing checkout and checkin of IKE_SAs when there is
more than one IKE_SAs with the same name. I also added the type of
in-air-exchange to the debug output issued by the task_manager in case
a task initiation is delayed, came in handy for me.
Tobias Brunner