[Swan-dev] broken delete behaviour on ikev2 ?

Antony Antony antony at phenome.org
Thu Sep 25 10:04:47 EEST 2014


On Wed, Sep 24, 2014 at 10:51:56PM -0400, Paul Wouters wrote:
> 
> Testing the ike header flags by sending an informational delete message,
> I see an unrelated problem, the delete fails:
> 
> | **parse ISAKMP Message:
> |    initiator cookie:
> |   ec 52 33 3e  d5 21 42 5c
> |    responder cookie:
> |   73 41 2d e0  dd 4d 92 b3
> |    next payload type: ISAKMP_NEXT_v2E
> |    ISAKMP version: IKEv2 version 2.0 (rfc4306/rfc5996)
> |    exchange type: ISAKMP_v2_INFORMATIONAL
> |    flags: ISAKMP_FLAG_v2_IKE_INIT
> |    message ID:  00 00 00 01
> |    length: 76
> |  processing version=2.0 packet with exchange type=ISAKMP_v2_INFORMATIONAL (37)
> | I am receiving an IKE Request
> | I am the IKE SA Original Responder
> | ICOOKIE:  ec 52 33 3e  d5 21 42 5c
> | RCOOKIE:  73 41 2d e0  dd 4d 92 b3
> | state hash entry 1
> | parent v2 peer and cookies match on #1
> | v2 state object #1 found, in STATE_PARENT_R2
> packet from 192.1.2.45:500: received too old retransmit: 1 < 2
> 
> This seems correct. For the informational exchange, we should have used
> msgid 2 since we used 0 for INIT and 1 for AUTH.
> 
> In send_inforational() we use:
> 
> 	r_hdr.isa_msgid = htonl(pst->st_msgid_nextuse);
> 
> So it looks like sending a successfull IKE_AUTH reply packet did not bump
> st_msgid_nextuse at the end of send_informational().
> 
> The msgid bump is handled in ikev2_update_counters() which is called by
> success_v2_state_transition()
> 
> I'll add some logging to ikev2_update_counters() and investigate
> tomorrow.
> 
> This must have shown up in our running testcases?  Antony, can you see
> when this failure started?

59b6278 is the first time it showed up in testcase  ikev2-delete-02
2014-09-05-blackswan-v3.10-54-g59b6278-hugh-2014aug/ikev2-delete-02/OUTPUT/east.pluto.log:packet from 192.1.2.45:500: received too old retransmit: 1 < 2






More information about the Swan-dev mailing list