Project

General

Profile

Bug #2364

"CHILD_SA ... established ..." log message not seen in ipsec up or swanctl --initiate output

Added by Paul Wouters about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Low
Category:
charon
Target version:
Start date:
19.06.2017
Due date:
Estimated time:
Affected version:
5.5.3
Resolution:
Fixed

Description

Our interop test cases flagged these:

http://testing.libreswan.org/results/testing/v3.20-603-gce5d67b-master/interop-ikev2-strongswan-35-rekey-pfs/OUTPUT/west.console.diff

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:

http://testing.libreswan.org/results/testing/v3.20-603-gce5d67b-master/interop-ikev1-strongswan-13-esp-sha2_512/OUTPUT/west.console.diff

Associated revisions

Revision a0cde769 (diff)
Added by Tobias Brunner about 3 years ago

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.

Fixes #2364.

History

#1 Updated by Tobias Brunner about 3 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.

#2 Updated by Tobias Brunner about 3 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Also available in: Atom PDF