<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 5 Apr 2021 at 19:03, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Eg see this log:<br>
<br>
Apr  5 18:56:32.909849: "west" #4: sent CREATE_CHILD_SA request to rekey IPsec SA<br>
Apr  5 18:56:32.917812: "west" #4: rekeyed #3 STATE_V2_REKEY_CHILD_I1 and expire it remaining life 28774.21038s<br>
Apr  5 18:56:32.917920: "west" #4: negotiated connection [192.0.1.0-192.0.1.255:0-65535 0] -> [192.0.2.0-192.0.2.255:0-65535 0]<br>
Apr  5 18:56:32.917928: "west" #4: IPsec SA established tunnel mode {ESP=>0x19ae6dab <0x0ec6e523 xfrm=AES_GCM_16_256-NONE-MODP2048 NATOA=none NATD=none DPD=passive}<br>
Apr  5 18:56:33.918801: "west" #3: deleting state (STATE_V2_ESTABLISHED_CHILD_SA) aged 26.826433s and sending notification<br>
Apr  5 18:56:33.918917: "west" #3: ESP traffic information: in=1KB out=1KB<br>
Apr  5 18:56:33.921937: "west" #1: received delete request for IKEv2_SEC_PROTO_ESP SA(0xfe024578) but corresponding state not found<br>
Apr  5 18:56:33.922055: "west" #1: established IKE SA<br>
Apr  5 18:56:46.640199: "west" #1: received Delete SA payload: replace CHILD SA #4 now<br>
Apr  5 18:56:46.640351: "west" #1: established IKE SA<br>
<br>
The only event here was a CREATE_CHILD_SA for a Child SA. it should not<br>
print those "established IKE SA" messages.<br></blockquote><div><br></div><div>It's connected to:</div><div><br></div>         * Tell whack and logs our progress - unless OE or a state<br>         * transition we're not telling anyone about, then be quiet.<br>         *<br>         * XXX: This code uses the new state, and not the state<br>         * transition to determine if things established :-(<br>         *<br>         * This should be a bit in the transition!</div><div class="gmail_quote"><br><div>although the comment is slightly out-of-date.  The bit SMF2_SUPPRESS_SUCCESS_LOG has been added (more are needed).  You could try adding it to this transition:</div><div><br></div><div>        { .story      = "Informational Request",<br>          .state      = STATE_V2_ESTABLISHED_IKE_SA,<br>          .next_state = STATE_V2_ESTABLISHED_IKE_SA,<br>          .send       = MESSAGE_RESPONSE,<br>          .req_clear_payloads = P(SK),<br>          .opt_enc_payloads = P(N) | P(D) | P(CP),<br>          .processor  = process_encrypted_informational_ikev2,<br>          .recv_role  = MESSAGE_REQUEST,<br>          .recv_type  = ISAKMP_v2_INFORMATIONAL,<br>          .timeout_event = EVENT_RETAIN, },<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, I wonder if we should keep a recent list of deleted IPsec and<br>
IKE SPI's, so when we get a delete response for something we have just<br>
deleted, we don't show a weird "not found" error.<br><br></blockquote><div><br></div><div>As in two delete requests crossing in the night?</div><div><br></div><div>Could this be from the delete code being a little too aggressive - deleting the incoming channel before the delete response has been received?</div></div></div>