On Mon, 5 Apr 2021, Paul Wouters wrote:
I noticed you used salifebytes= and salifepackets=.
I'm still working with these for now. Since I'm adding code for deleting an IPsec SA when hard timer hits, I also have a need to ignore a hard timer when testing, so I created two new impair values "ignore-soft-expire" and "ignore-hard-expire" for testing. During testing, it seemed that after the first trigger (say inbound), if the IPsec SA is replaced before the second trigger (say outbound) happens, then the check using st_kernel_sa_expired failed because the latest IPsec SA did not have that value set anymore. The attached patch fixes that issue, and also introduces impair's to ignore soft or hard expiry messages. I found the hard expire hitting too fast on the super low soft expiry, and that also confuses me with testing. It can also be used to ignore soft limits without needing to hobble the code that responses to the soft timer so we can test the hard timer. I also hit a case where an expiry would cause an IKE SA delete, because there was no child sa left, which then caused an IKE_INIT instead of CREATE_CHILD_SA, so I added a check for that case. I've extended the ipsec trafficstatus command to show maxBytes= as well as showing it in the log message that showed ESPmax= with the wrong value. One thing to note here is that the maximum bytes was expected to be stored in st->st_esp.attrs.life_kilobytes or st->st_ah.attrs.life_kilobytes, but instead it is now pulled from c->sa_ipsec_life_bytes which is where whack stores it. I wonder if there is anything else using the attrs there, and if not, perhaps those should be removed entirely? Note I renamed initiate_replace() to handle_expiring_sa() as we do not always initiate or replace the Child SA. I started working on the packet count limit, but that is currently hitting a weird continious rekeying bug. I pushed my changes to a forked libreswan repo of yours and created a pull request: https://github.com/antonyantony/libreswan/pull/1 Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
