Hi,

I wonder if anyone can please help me with a problem I'm having getting
strongSwan (4.2.14) running on the ARM ?

I've played about getting strongSwan working on x86 setting up a tunnel to
a server. I then compiled strongSwan for ARM and copied across the config
files I used on x86.

The ARM version fails to set up the tunnel.

Turning on tracing to level 3 everywhere gets me the following line in the
client (left?) /var/log/messages:

charon: 08[MGR] checkout IKE_SA
charon: 13[ENC]   parsing rule 0 U_INT_8
charon: 13[ENC]    => 39
charon: 13[ENC]   parsing rule 1 FLAG
charon: 13[ENC]    => 0
charon: 13[ENC]   parsing rule 2 RESERVED_BIT
charon: 13[ENC]   parsing rule 3 RESERVED_BIT
charon: 13[ENC]   parsing rule 4 RESERVED_BIT
charon: 13[ENC]   parsing rule 5 RESERVED_BIT
charon: 13[ENC]   parsing rule 6 RESERVED_BIT
charon: 13[ENC]   parsing rule 7 RESERVED_BIT
charon: 13[ENC]   parsing rule 8 RESERVED_BIT
charon: 13[ENC]   parsing rule 9 PAYLOAD_LENGTH
charon: 13[ENC]    => 3
charon: 13[ENC] encrypted payload could not be decrypted and parsed
charon: 13[ENC] could not decrypt payloads
charon: 13[IKE] IKE_AUTH response with message ID 1 processing failed

The client is trying to use ike=aes128-sha-modp1024!, esp=aes128-sha1,
3des-md5 and EAP-SIM.

The client has sent out the initial IKE_SA_INIT request and been happy
with the IKE_SA_INIT response. The client has then sent out the first
IKE_AUTH request and has then had trouble processing the first IKE_AUTH
response.

Working back from the "encrypted payload could not be decrypted and
parsed" error in the code, I can see that message.c:decrypt_payloads() has
managed to decrypt and parse one payload (the ID_RESPONDER one) and has
started on the CERTIFICATE payload.

The code manages to decrypt this payload okay and starts to parse it (see
parser.c:parse_payload()).

The payload starts with the following bytes:

0x27, 0x00, 0x03, 0xFA, 0x04, 0x30

On the x86, the code parses the first byte as one uint_8 = 39 decimal (27
hex), 8 1-bit fields and a uint_16 payload-length = 1018 decimal (03FA
hex).

On the ARM, the code parses the first byte as one uint_8 = 39 (decimal), 8
1-bit fields and a uint_16 payload-length = 3 decimal (0003 hex) !!

The code, rightly, thinks this is rubbish and fails the rest of the parse.

I've worked my way through the code in parser.c (e.g. parse_payload(),
parse_uint8(), parse_bit() and parse_uint16()) and managed to reduce them
to a small test program (hopefully attached).

If I compile and run this on the x86, I get:

  parsing rule 0 U_INT_8
   => 39
  skipping rules 1 FLAG ... 8 RESERVED_BIT
  parsing rule 9 PAYLOAD_LENGTH
   => 1018

output. On the ARM, I get:

  parsing rule 0 U_INT_8
   => 39
  skipping rules 1 FLAG ... 8 RESERVED_BIT
  parsing rule 9 PAYLOAD_LENGTH
   => 65283

To make things more clear what it going on, I have changed the second byte
of the message from 0x00 to 0xff in my test program.

If I replace the line:

    output_pos = ntohs(*((u_int16_t*) byte_pos));

by:

    u_int16_t intermediate = *(byte_pos + 1) << 8 | *(byte_pos + 0);
    output_pos = ntohs(intermediate);

everything works as expected on both x86 and ARM.

Also found that something like the following works on both x86 and ARM:

    u_int16_t intermediate;

    u_int8_t* intermediate_bytes = (u_int8_t*) &intermediate;

    intermediate_bytes[0] = byte_pos[0];

    intermediate_bytes[1] = byte_pos[1];

    output_pos = ntohs(intermediate);

Can anyone explain this and how to fix it easily ?

I'm hoping that someone will say that this is fixed by a command-line flag
on the ARM version of gcc ;-}

Version of ARM gcc in use is 4.1.1.

If this does mean a strongSwan code fix, will it just be to parse_uint16() ?

Or parse_uint32() too ?

Or is this idiom endemic throughout the strongSwan code ?

Thanks for any help,

    Graham.

#include <stdio.h>
#include <sys/types.h>

int main()
{
    u_int8_t bytes[] =
    {
        0x27, 0xff, 0x03, 0xFA, 0x04, 0x30
    };

    u_int8_t bit_pos;

    u_int8_t* byte_pos;

    byte_pos = bytes;

    printf("  parsing rule 0 U_INT_8\n");

    {
        u_int8_t output_pos;

        output_pos = *(byte_pos);

        printf("   => %d\n", output_pos);
    }

    byte_pos++;

    printf("  skipping rules 1 FLAG ... 8 RESERVED_BIT\n");

    byte_pos++;

    printf("  parsing rule 9 PAYLOAD_LENGTH\n");

    {
        u_int16_t output_pos;

        // u_int16_t intermediate = *(byte_pos + 1) << 8 | *(byte_pos + 0);

        // output_pos = ntohs(intermediate);

        output_pos = ntohs(*((u_int16_t*) byte_pos));

        printf("   => %d\n", output_pos);

#ifdef MORE_TRACING
        printf("bytes = 0x%x, byte_pos = 0x%x, bytes + 2 = 0x%x\n",
            (unsigned int) bytes,
            (unsigned int) byte_pos,
            (unsigned int) (bytes + 2));

        printf("*byte_pos = %d\n", *byte_pos);
        printf("*((u_int16_t*) byte_pos) = %d = 0x%x\n",
            *((u_int16_t*) byte_pos), *((u_int16_t*) byte_pos));
        printf("ntohs(*((u_int16_t*) byte_pos)) = %d = 0x%x\n",
            ntohs(*((u_int16_t*) byte_pos)), ntohs(*((u_int16_t*) byte_pos)));
#endif /* MORE_TRACING */
    }

    byte_pos += 2;

    return 0;
}
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to