sanity check for a fake HIP configuration packet

[Raimondas Sasnauskas]

When testing HIP association establishment using symbolic execution, I came across the following scenario. If the initial (correct) I1 packet contains 0x10 in the header field ver_res instead of 0x11, it is first identified as a configuration packet (HIP_USER_VER_RES is 0x10) and afterwards fails a sanity check on packet length (lib/core/builder.c:1836):

    HIP_IFEL(len != hip_get_msg_total_len(hip_common), -EINVAL,
             "Invalid HIP packet length (%d,%d). Dropping\n",
             len, plen);

I think that this assertion shouldn't fire for such a packet at this place, right?