On Mon, 5 Apr 2021 at 20:45, Paul Wouters <[email protected]> wrote: > On Mon, 5 Apr 2021, Andrew Cagney wrote: > > > 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: > > I'll try and play with that. > > > Also, I wonder if we should keep a recent list of deleted IPsec and > > IKE SPI's, so when we get a delete response for something we have > just > > deleted, we don't show a weird "not found" error. > > > > > > As in two delete requests crossing in the night? > > > > Could this be from the delete code being a little too aggressive - > deleting the incoming channel before the delete response has been received? > > It's simpler. > > 1) We realise we want to delete a child sa > 2) we send the delete > 3) we delete it > 4) we get a response, but we cannot find the child sa SPI > > Yea, that's too aggressive with deleting the incoming channel. I'm pretty sure the initiator should:
- delete outgoing channel - send delete on receipt of response - delete incoming channel - delete child state otherwise we get the responder sending packets that have nowhere to go > A variant: > > 1) We realise we want to delete a chilf sa > 2) we send a delete > 3) we delete it > 4) we realise the IKE sa has no more child sa's, so we delete it > 5) we receive the encrypted IKE packet for the delete of child sa, > but can't read it. > > Perhaps this last case is now fixed? with pending the delete, but in > that case the reply message is still unreadable because we deleted the > IKE SA. > It's improved as in it only sends one delete. It still needs the IKE SA to hang around. > I saw these while working on the expiry code. > > Paul >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
