On Fri, Feb 03, 2023 at 10:25:47AM -0500, Paul Wouters wrote: > On Fri, 3 Feb 2023, Antony Antony wrote:
> Ofcourse, a side effect of doing this was that we _did_ update the > byte counters so every time the dpddelay period was reached, or a whack > status or delete was issued, we would update the traffic counters. That > is probably a good thing to keep. Althoug that makes the addition of > the fixed lastused less useful to us. But I guess it does end up getting > more precision with lastused, then our "now" handling evert dpddelay > time. So that's good to have. > > All of this could ofcourse go away if the kernel could send us an "idle" > callback, but I think that's still not there right? I don't know any! I feel there was a lot confusion among us, swan programmers, around last used and we came up with workarounds. If you look again, with lastused updated for every packet pluto polling would be simple and possibly scalable. Now pluto can control the rate of polling from kernel. Otherwise userspsece/pluto would complain receiving too many idle messages! Think of up link going down, and several 1000s of SAs become idle at once. The idle timer for all 1000s of SAs go off at once in the kernel, and the kernel would send 1000s of messages, possibly faster than pluto would be able to handle them. For each message Pluto would create IKE informational message, and send it. Likely retransmit IKE message and timeout? And then delete... I imagine handling of large number of kernel events would get complex very soon... Uplink going down would happen from time time. I feel pluto polling is better. Having said that may be there are ways to implement smart timers in kernel who knows! In an ideal world lastused update would have been fixed 10 years ago! _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev