It turned out we never pulled in the last traffic accounting data before
deleting an IPsec SA. This bug was staring us in the face with the 0B
entries in a bunch of console output.
I fixed it, but you will notice something along these lines:
002 "ikev2-ike=aes128-sha1-dh19" #2: deleting state (STATE_V2_IPSEC_I) and
sending notification
-005 "ikev2-ike=aes128-sha1-dh19" #2: ESP traffic information: in=0B out=0B
+005 "ikev2-ike=aes128-sha1-dh19" #2: ESP traffic information: in=84B out=84B
002 "ikev2-ike=aes128-sha1-dh19" #1: deleting state (STATE_PARENT_I3) and
sending notification
+002 "ikev2-ike=aes128-sha1-dh19" #1: failed to pull traffic counters from
outbound IPsec SA
+002 "ikev2-ike=aes128-sha1-dh19" #1: failed to pull traffic counters from
inbound IPsec SA
the first change is expected. The second one is odd. It is deleting a
parent SA, so it should not be trying to pull IPsec SA traffic counters,
because the code doing that checks for the SA type:
if (IS_IPSEC_SA_ESTABLISHED(st->st_state)) {
+ /* pull in the traffic counters into state before they're lost
*/
+ if (!get_sa_info(st, FALSE, NULL)) {
+ libreswan_log("failed to pull traffic counters from outbound
IPsec SA");
+ }
+ if (!get_sa_info(st, TRUE, NULL)) {
+ libreswan_log("failed to pull traffic counters from inbound
IPsec SA");
+ }
So it seems to be that there is a bug in the macro IS_IPSEC_SA_ESTABLISHED()
So for now, a bunch of a test cases will fail because we can't update
the traffic count fix because there is an error line as well.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
