[Swan-dev] IPsec SA accounting bug fixed - some test case still broken due to macro bug?

[Paul Wouters]

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