On Thu, 18 Oct 2018 at 13:55, Antony Antony <[email protected]> wrote: > > On Thu, Oct 18, 2018 at 11:00:26AM -0400, Andrew Cagney wrote: > > In IKEv2, at any point, two Message IDs are being juggled: > > - the ID of SA's last message request > > - the ID of SA's last message response > > > > hence, a single .st_msgid which can be traced back to IKEv1 isn't > > sufficient. Instead IKEv2 should be using the fields: > > > > /* message ID sequence for things we send (as initiator) */ > > msgid_t st_msgid_lastack; /* last one peer > > acknowledged - host order */ > > msgid_t st_msgid_nextuse; /* next one to use - > > host order */ > > /* message ID sequence for things we receive (as responder) */ > > msgid_t st_msgid_lastrecv; /* last one peer sent - > > Host order v2 only */ > > msgid_t st_msgid_lastreplied; /* to decide retransmit > > CREATE_CHILD_SA */ > > we are tracking 3. I wonder if we should track 4.
> Initiating an exchange: > st_v2_msgid_nextuse > st_v2_msgid_lastack > > responding to an exchange > > st_v2_msgid_lastreplied > I think it would be nice to have > st_v2_mstid_last_received /* received but not replied yet */ I suspect that is .st_msgid_lastrecv, but there's the problem - I'm not sure :-) > > Given this, I'm planning on renaming .st_msgid (and likely the above). > > Since we've settled on v[12]* as the name prefix convention several > > new names come to mind: > > > > - st_v1_msgid > > st_v1_msgid Yea. > > (PS: I've also a strong preference for sticking v2 somewhere in any > > v2-only thing as that way I know it isn't generic and may have to > > handle ikev1) > > my preference is use as first prefix or the second. > > The one in md would become > msgid_t v2_msgid_received ? I've a patch to delete that field - ever since .hdr.isa_msgid was switched to host-order it became redundant. Except it doesn't work - instead it keeps flushing out increasingly subtle problems with the Message ID code :-( and hence this post. Andrew _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
