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
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.
I saw these while working on the expiry code.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
