[Swan-dev] EVENT_RETRANSMIT_DELAY_0

[D. Hugh Redelmeier]

| From: Antony Antony <antony at phenome.org>

| DELETE_SA_DELAY will be replaced. I am still working on an accurate replacement for:
| 
| monobefore(monotimesum(mononow(), deltatime(DELETE_SA_DELAY)), dst->st_event->ev_time) 
| 
| event_pending could be used.
| 
| event_pending(dst->st_event->ev, EV_TIMEOUT, delay) 
| delay - DELETE_SA_DELAY
| 
| of course with the right units. If this works then get rid of ev_time.

The original is really odd code that needs a better explanation.

It appears to be something like this: we'll ignore a delete
notification from the other side if we THINK that we're replacing the
state about really soon.

IF
- the state is the most recent for the connection, AND
- the connection has POLICY_UP, AND
- there is an event scheduled in the state, AND
- the event is EVENT_SA_REPLACE, AND
- that event will fire less than DELETE_SA_DELAY from now
  where DELETE_SA_DELAY happens to be EVENT_RETRANSMIT_DELAY_0
THEN
 ignore the  delete notification

I don't understand why this is reasonable logic.

| still working on replacing the use of EVENT_RETRANSMIT_DELAY_0 with 
| c->r_interval, however, two instances trips me off.  The retransmit is 
| scheduled in 30 seconds, check the #master. That looks odd to me.
| 
| ikev1_aggr.c  1383 /* Set up a retransmission event, half a minute hence */
| ikev1_xauth.c 1010 /* Set up a retransmission event, half a minute hence */

I get blamed for those comments but all I did was correct the English.
I changed "henceforth" to "hence".  See
2e586b2c37ca7eae5e50613f1e68aff52b7fea63.

The comment and the code (which disagree!) were added
in almost a decade ago in 241fba64a3c8c993db820343b76063d51475d843 and
9884278826e09e5dd78fcbc3d5c38310e12527ce.

Fix the comments.  Use a retransmission time that makes sense.

| EVENT_RETRANSMIT_DELAY_CAP is gone.

Thanks.