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? > > 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
