Re: [strongSwan] Strongswan 4.2.14 broken on ARM ?

2009-05-20 Thread Graham Hudspith 
 I've removed any reads to unaligned integers in the parser code [1],
generator looks OK so far. I don't have an ARM box, so any feedback is
very welcome.

 Thanks
 Martin

 [1]http://wiki.strongswan.org/repositories/diff/strongswan?rev=42748858



Martin,

Thanks for that patch.

With a small bit of adjustment, I managed to apply the patch to my
copy of the 4.2.14 code, :-), and rebuild.

It seems to work fine, so far.

I did have a small problem the first time I brought the ARM up, in
that the initial SA came up fine but then something started creating LOTS
of child SAs. I pulled the plug on the ARM box after we got to 100 child
SAs. Unfortunately, I did not have any charon logging turned on, so had no
logs to comb through.

Since then, restarting the ARM box and bringing up the connection has
exhibited no problems (and no unwanted child SAs).

So, looking good (but feeling slightly nervous about it needing wider
testing).

Regards,

Graham.







___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Strongswan 4.2.14 broken on ARM ?

2009-05-18 Thread Martin Willi 
Hi,

 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.

Yes, it seems that some ARM CPUs don't like unaligned (half-)word reads.

 I can find at least 26 occasions in the strongSwan code where this
 reading-a-byte-pointer-as-a-uint16-pointer idiom occurs.

I think not all of them are problematic. GCC should align struct members
properly, so read/write to struct members shouldn't be a problem (except
__packed__ ones, I'll review those).

I've removed any reads to unaligned integers in the parser code [1],
generator looks OK so far. I don't have an ARM box, so any feedback is
very welcome.

Thanks
Martin

[1]http://wiki.strongswan.org/repositories/diff/strongswan?rev=42748858

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Strongswan 4.2.14 broken on ARM ?

2009-05-15 Thread Graham Hudspith 
 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