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