On Sun, 19 Apr 2020 at 10:20, Andrew Cagney <[email protected]> wrote:
> > > On Sun, 19 Apr 2020 at 06:57, Antony Antony <[email protected]> wrote: > >> Dear fellow developers. >> >> I just noticed the IKEv2 IPsec rekey responder code has regressed beyond >> recognition! too many changes after the main regression:) While trying to >> figure out I notice logging and debugging lines changed too (possibly >> old) >> some with STATE_ and other without the prefix STATE_. This make it hard >> to >> follow the regression. >> >> I suggest we take pause and retrace the steps. Also changing IKEv2 STATE_ >> is >> , as I recollect, discontented issue. And I feel change has been sneaked >> in. >> Also use of some with STATE_ and others without "STATE_" is annoying. >> > > >> Main issue: rekey regression seems to started with 8abf1c415a. >> currently the pattern is >> >> https://testing.libreswan.org/v3.30-456-g8abf1c415a-master/ikev2-child-rekey/OUTPUT/east.pluto.log.gz >> >> child state #3: V2_CREATE_R0(established IKE SA) => >> V2_IPSEC_R(established CHILD SA) >> >> that state transition for #3 seems wrong, it is not re-key transition. I >> can't be sure because we have many log changes etc. But one thing is sure >> #master is taking same weird code path for IKEv2 rekey responder. >> > > So this: > > Apr 9 11:04:43.134196: | state #1 forced to match CREATE_CHILD_SA from > STATE_V2_CREATE_R0->STATE_V2_IPSEC_R by ignoring from state > Apr 9 11:04:43.134276: | selected state microcode Respond to CREATE_CHILD_SA > IPsec SA Request > Apr 9 11:04:43.134428: | #1 updating local interface from 192.1.2.23:500 to > 192.1.2.23:500 using md->iface (in update_ike_endpoints() at state.c:2675) > > should have matched the child rekey transition? > I'm testing a fix (two transitions got reversed). Is there a test that shows fails after 8abf1c415a? > > > >> >> Before this regression: state transition appears to do the right thing. >> >> >> https://testing.libreswan.org/v3.30-455-g221d720f48-master/ikev2-child-rekey/OUTPUT/east.pluto.log.gz >> rekey seems to follow what is expected. >> >> child state #3: V2_CREATE_R0(established IKE SA) => >> V2_REKEY_CHILD_R0(established IKE SA) >> >> child state #3: V2_REKEY_CHILD_R0(established IKE SA) => >> V2_IPSEC_R(established CHILD SA) >> >> 2. log/debug started using short names and mixing them with long state >> names. This should not happen! Please keep the state names long and >> consistent. >> >> switching IKEv2 MD.ST from CHILD #3 V2_CREATE_R0 to CHILD #3 >> V2_CREATE_R0 >> >> In some other parts of the log it is full name. >> >> please keep the full name. >> >> "east" #4 complete v2 state STATE_V2_REKEY_CHILD_R0 transition with >> STF_SUSPEND suspended from complete_v2_state_transition:3399 >> >> NOTE: because of changes to state names since 8abf1c415a in master you >> will >> see. >> >> >> https://testing.libreswan.org/v3.30-507-ge06a82880f-master/ikev2-child-rekey/OUTPUT/east.pluto.log.gz >> Apr 18 23:52:26.316312: | child state #3: V2_NEW_CHILD_R0(established IKE >> SA) => V2_IPSEC_R(established CHILD SA) >> >> It should be something like STATE_V2_REKEY_CHILD_R0 => >> STATE_V2_IPSEC_R(established) >> >> -antony >> >> PS: at first glance initiator code seems ok. Again hard to say becuase of >> log changes. >> _______________________________________________ >> Swan-dev mailing list >> [email protected] >> https://lists.libreswan.org/mailman/listinfo/swan-dev >> >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
