[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