From 4141f0167191eacfbeee26a7dfad749529ee866b Mon Sep 17 00:00:00 2001 From: Tobias Brunner Date: Tue, 4 Nov 2014 18:24:16 +0100 Subject: [PATCH] ikev1: Accept IPComp proposals with 4 octet long CPI values While they SHOULD be sent as 16-bit values according to RFC 3173 a responder MUST be able to accept CPI values encoded in four bytes. --- src/libcharon/encoding/payloads/proposal_substructure.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/libcharon/encoding/payloads/proposal_substructure.c b/src/libcharon/encoding/payloads/proposal_substructure.c index 53e8cf3ad3..fb9e7856eb 100644 --- a/src/libcharon/encoding/payloads/proposal_substructure.c +++ b/src/libcharon/encoding/payloads/proposal_substructure.c @@ -345,7 +345,7 @@ METHOD(payload_t, verify, status_t, switch (this->protocol_id) { case PROTO_IPCOMP: - if (this->spi.len != 2) + if (this->spi.len != 2 && this->spi.len != 4) { DBG1(DBG_ENC, "invalid CPI length in IPCOMP proposal"); return FAILED; @@ -536,7 +536,7 @@ METHOD(proposal_substructure_t, get_cpi, bool, { if (cpi) { - *cpi = *((u_int16_t*)this->spi.ptr); + *cpi = htons(untoh16(this->spi.ptr + this->spi.len - 2)); } enumerator->destroy(enumerator); return TRUE; -- 2.47.2