On Sat, Nov 08, 2014 at 11:10:03AM -0500, D. Hugh Redelmeier wrote: > | From: Antony Antony <[email protected]> > > [Sorry for the slow response. I still haven't studied this well but > I don't want to hold you up any longer.] > > | It is probably time to remove IKEv2 debug log line in function > | success_v2_state_transition, case EVENT_NULL, Any objections? > > No objection. > > My idea was that setting of timeouts should be centralized since there > is a more-or-less common logic. That certainly was true in V1. > > It was one of many things on my to-do list but I ignored it since you > had taken that task over (but perhaps with a different goal).
same goal as you. There is once case in AUTH exchange where we set timeout event outside of success_v2_state_transition. I am not sure how to move that. The timeout event for child is set by success_v2_state_transition. > > | And the proposed change and related ones are in a new branch > | ikev2-smc-timeout, waiting for review and testing. > | > | Hugh, please take a look when time permits. > > Sorry, I haven't done that yet. > > What is the semantics of EVENT_NULL in this table? I presume: don't > change the event that is already scheduled. In that case, we should > check that there is actually an event scheduled. If so, perhaps we > should add and use "EVENT_RETAIN" to make that clear -- after all, > EVENT_NULL already has a different meaning elsewhere (I guess). If > there is not other use, then it should just be renamed. > > 0 (the value of EVENT_NULL) might be useful as a reserved value to > catch accidents. For example, uninitialized struct member. > > | EVENT_NULL is ok for many smc entries, such as, > | - when responding to an IKEv2 informational exchange, such as > dpd/liveness , or delete > > When responding to an IKEv2 informational exchange, I would expect > EVENT_RETAIN would make sense. > > DPD/Liveness: would that not change the next DPD/Liveness event timing > (at least in some cases)? > > I don't know what "delete" is. If it is "I just sent a delete > notification", I think a new event would be appropriate (when to > retransmit or to just go ahead and delete). If it is "I just received > a delete, but not for myself", I imagine that > - dpd timeout (if any) should be reset > - the old rekey-or-whatever event ought to be retained. > > | - "Initiator: process anti-spoofing cookie" > EVENT_RETAIN is a good idea. I have committed the change to #ikev2-smc-timeout -antony _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
