Hi Thomas, > If the peer with the SA configured to be restarted > wins the rekey collision it honors the restart action once the other > peers sends a delete notification, and reinitiates the (actually > duplicate) SA. This results in a growing number of superseded child sas > (which I cleverly configured to time out in an infinite time, i.e. > never).
I've seen on our server that there sometimes pops up an additional CHILD_SA after it was running for a longer time. Now I finally know what was happening. I seldom use dpd/close actions in my tests, so I couldn't reproduce it... Many thanks for pointing this out. > The attached patch introduces a new data member to the child sa, I slightly modified the patch to wrap the complete get_close_action() into the CHILD_SA. This allows us to override the close action whenever we want for a specific CHILD_SA, might come in handy sometime. Same for get_dpd_action(). > can be used to set and retrieve information on whether the child is > going to be deleted by the peer, so that the SAs delete action is going > to be ignored. I've added the same functionality based on the new setter. Many thanks for the patches. Best regards Martin _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
