"CHILD_SA ... established ..." log message not seen in ipsec up or swanctl --initiate output
Our interop test cases flagged these:
the CERT changes there seem correct and a bugfix from 5.5.2 or 5.5.3, but the line with CHILD_SA should probably not be missing?
Similar bug in ikev1 can be seen too:
ike: Trigger CHILD_INSTALLED state change after corresponding log message
This way we get the log message in stroke and swanctl as last message
when establishing a connection. It's already like this for the IKE_SA
where IKE_ESTABLISHED is set after the corresponding log message.
#1 Updated by Tobias Brunner over 4 years ago
- Subject changed from some logging has vanished which seems to have been done by accident to "CHILD_SA ... established ..." log message not seen in ipsec up or swanctl --initiate output
- Status changed from New to Feedback
- Target version set to 5.6.0
Hm, the state change for the CHILD_SA has actually been triggered before that log message since 4.2.9 and this message might not have been logged for a long time in the output of ipsec/stroke or swanctl (as can also be seen in the output of our test suite - nobody seemed to have cared apparently). Perhaps in your case the thread scheduling just caused the message to appear previously because detaching from the logging bus and returning the result to stroke/swanctl happens asynchronously in the controller after the CHILD_SA has been signaled as being installed by another thread.
I guess we could move that state change after the log message, or use the
child_updown() callback instead of the state change in the controller, as that's triggered after the log message. But since the former is easier to implement and should not have any negative side-effects (we actually do it the same way for IKE_SAs) I did that in the 2364-child-sa-established-log branch.