On Sun, 3 May 2020 at 21:18, Paul Wouters <[email protected]> wrote: > > On Sat, 2 May 2020, Andrew Cagney wrote: > > > Tuomo and I spent a bit of Friday debugging a regression where the > > liveness probe was stomping on a DISCARD event (forcing it to REPLACE) > > set according to the connection. > > I think there are two reasons why a state can get a DISCARD event. One > is for when there is no rekeying scheduled and it reaches its end of > life. The other is when it has been replaced by another IPsec SA, and > we let it linger for a while. Unfortunately, "a while" is just the > original end of life timeout. The revive code I guess tries to determine > if this state is the c->newest_ipsec_sa and then is supposed to act > differently (let it die or try to spin up new one)
Yes. SO_DISCARD assumes a failure and a timeout. Other than logging and who to blame it is identical to CRYPTO_TIMEOUT. -> there should be a way to zap a state without any counting > > Anyway, I think this points to the next change. When retransmits > > fail, force what ever event is in .st_event (and I'm tempted to rename > > .st_event to .st_kill_event or .st_death_event). The test results didn't come across as either better or worse :-/ So lets break this down. An SA expected to end its life through either: - CREATE_CHILD_SA/rekey exchange - DELETE exchange When looking at the user concepts, it seems to be something like: - a rekey is CREATE_CHILD+SA+rekey exchange; with a bit saying that should things go south revive the connection - expire is just a delete with a bit saying if things go south, don't revive the connection - replace (no rekey) is more convoluted but from the POV if this state it is just a delete (but start trying to establish the replacement early), and perhaps also a bit saying revive the connection so should any exchange timeout, I'm guessing it needs to though the family and revive anything with the revive bit set > Maybe st_afterlife ? :) > > Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
