| 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). | 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" There should be a new timeout set here, I would think. _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
