> 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.
>
I hate replying to my own email, but I've been playing around with the ARM
compiler.
>
> Can anyone explain this and how to fix it easily ?
>
It seems that there is a word (or, half-word) alignment thing going on here.
I've written another test program which iterates through the array of 6
bytes, converting each one to a uint16.
The array is:
0x27, 0xff, 0x03, 0xFA, 0x04, 0x30
On the x86, the output is:
=> 0x27ff
bytes = 0xbfc8bffe, byte_pos = 0xbfc8bffe, &bytes[0] = 0xbfc8bffe
*byte_pos = 0x27
*((u_int16_t*) byte_pos) = 65319 = 0xff27
ntohs(*((u_int16_t*) byte_pos)) = 10239 = 0x27ff
=> 0xff03
bytes = 0xbfc8bffe, byte_pos = 0xbfc8bfff, &bytes[1] = 0xbfc8bfff
*byte_pos = 0xff
*((u_int16_t*) byte_pos) = 1023 = 0x03ff
ntohs(*((u_int16_t*) byte_pos)) = 65283 = 0xff03
=> 0x03fa
bytes = 0xbfc8bffe, byte_pos = 0xbfc8c000, &bytes[2] = 0xbfc8c000
*byte_pos = 0x03
*((u_int16_t*) byte_pos) = 64003 = 0xfa03
ntohs(*((u_int16_t*) byte_pos)) = 1018 = 0x03fa
=> 0xfa04
bytes = 0xbfc8bffe, byte_pos = 0xbfc8c001, &bytes[3] = 0xbfc8c001
*byte_pos = 0xfa
*((u_int16_t*) byte_pos) = 1274 = 0x04fa
ntohs(*((u_int16_t*) byte_pos)) = 64004 = 0xfa04
=> 0x0430
bytes = 0xbfc8bffe, byte_pos = 0xbfc8c002, &bytes[4] = 0xbfc8c002
*byte_pos = 0x04
*((u_int16_t*) byte_pos) = 12292 = 0x3004
ntohs(*((u_int16_t*) byte_pos)) = 1072 = 0x0430
You can see that the bytes are bring read correctly (e.g. 0x27ff, 0xff03,
0x03fa, etc.).
On the ARM, the output is:
=> 0xe427
bytes = 0xbedcebfd, byte_pos = 0xbedcebfd, &bytes[0] = 0xbedcebfd
*byte_pos = 0x27
*((u_int16_t*) byte_pos) = 10212 = 0x27e4
ntohs(*((u_int16_t*) byte_pos)) = 58407 = 0xe427
=> 0xff03
bytes = 0xbedcebfd, byte_pos = 0xbedcebfe, &bytes[1] = 0xbedcebfe
*byte_pos = 0xff
*((u_int16_t*) byte_pos) = 1023 = 0x03ff
ntohs(*((u_int16_t*) byte_pos)) = 65283 = 0xff03
=> 0xff03
bytes = 0xbedcebfd, byte_pos = 0xbedcebff, &bytes[2] = 0xbedcebff
*byte_pos = 0x03
*((u_int16_t*) byte_pos) = 1023 = 0x03ff
ntohs(*((u_int16_t*) byte_pos)) = 65283 = 0xff03
=> 0xfa04
bytes = 0xbedcebfd, byte_pos = 0xbedcec00, &bytes[3] = 0xbedcec00
*byte_pos = 0xfa
*((u_int16_t*) byte_pos) = 1274 = 0x04fa
ntohs(*((u_int16_t*) byte_pos)) = 64004 = 0xfa04
=> 0xfa04
bytes = 0xbedcebfd, byte_pos = 0xbedcec01, &bytes[4] = 0xbedcec01
*byte_pos = 0x04
*((u_int16_t*) byte_pos) = 1274 = 0x04fa
ntohs(*((u_int16_t*) byte_pos)) = 64004 = 0xfa04
Which is plain wrong.
Whenever the byte in memory is half-word-aligned, reading it as a uint16
works as expected. The other half of the time, the compiler is adjusting
the pointer (back one) to make it half-word-aligned before reading the two
bytes as a uint16.
I can find at least 26 occasions in the strongSwan code where this
reading-a-byte-pointer-as-a-uint16-pointer idiom occurs.
I have not searched for the byte-pointer->uint32-pointer case yet :-(
Graham.
#include <stdio.h>
#include <sys/types.h>
#define MORE_TRACING
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;
int i;
for(i = 0; i < 5; ++i)
{
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(" => 0x%04x\n", output_pos);
#ifdef MORE_TRACING
printf("\tbytes = 0x%x, byte_pos = 0x%x, &bytes[%d] = 0x%x\n",
(unsigned int) bytes,
(unsigned int) byte_pos,
i,
(unsigned int) &bytes[i]);
printf("\t*byte_pos = 0x%02x\n", *byte_pos);
printf("\t*((u_int16_t*) byte_pos) = %d = 0x%04x\n",
*((u_int16_t*) byte_pos), *((u_int16_t*) byte_pos));
printf("\tntohs(*((u_int16_t*) byte_pos)) = %d = 0x%04x\n",
ntohs(*((u_int16_t*) byte_pos)), ntohs(*((u_int16_t*) byte_pos)));
printf("\n\n");
#endif /* MORE_TRACING */
byte_pos++;
}
return 0;
}_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
