On Mon, 5 Jul 2021 at 14:55, Paul Wouters <[email protected]> wrote: > On Jul 5, 2021, at 14:46, Andrew Cagney <[email protected]> wrote: > > > > > > Again, three possible outcomes requiring three clear status codes: > > > - exchange succeeds; child succeeds STF_OK > > > - exchange succeeds; child fails (ike survives) STF_FAIL > > > - exchange fails, implying that the ike family dies STF_FATAL > > we need a way to differentiate between them, and return accordingly. > > I agree for ikev2. Is it possible that we rename these to STFv2_XXX ? > > Because re-assigning meaning here might make sense but will really be > confusing when looking at the IKEv1 code where this is not true. > > We are really changing the meaning here. > > So I looked at v3.23 IKEv1.
- to your point, the STF_FAIL path contains the comment: /* As it is, we act as if this message never happened: * whatever retrying was in place, remains in place - however to my point, it already contains code to send notifications and delete the (quick) state - not exactly following the guidelines Helps explain why STF_DROP and STF_IGNORE were added. For a name change I don't know what to call them.
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
