date:20090515

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 
#include 

#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

[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.

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 
#include 

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

Re: [strongSwan] Looking for advice on IKE

2009-05-15 Thread Martin Willi

Hi Phil,

> We will be using a vendor's onboard chip and it has their own IPsec
> imbedded in it.  It has no key management (IKE or IKEv2) capabilities.
> We are looking into using Strongswan (hopefully) on the host for
> IKE/IKEv2 only.  A shim will be developed by us to get the IKE info down
> to the chip for IPsec to use.  

The IKEv2 daemon has a good abstraction layer. You'll actually have to
implement the IPsec kernel interface [1] in your own plugin. This is not
trivial and might need some tricks depending on your chip, but it
should be possible. 

We currently ship implementations for Linux XFRM [2], PF_KEY [3] and an
older KLIPS stack [4].

The IKEv1 daemon also has an abstraction layer for the kernel
communication interface [5], but I'm not very used to it.

Regards
Martin

[1]http://wiki.strongswan.org/repositories/entry/strongswan/src/charon/kernel/kernel_ipsec.h
[2]http://wiki.strongswan.org/repositories/entry/strongswan/src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c
[3]http://wiki.strongswan.org/repositories/entry/strongswan/src/charon/plugins/kernel_pfkey/kernel_pfkey_ipsec.c
[4]http://wiki.strongswan.org/repositories/entry/strongswan/src/charon/plugins/kernel_klips/kernel_klips_ipsec.c
[5]http://wiki.strongswan.org/repositories/entry/strongswan/src/pluto/kernel.h#L78



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

[strongSwan] Looking for advice on IKE

2009-05-15 Thread Philip Bellino

Hello,
We currently use Strongswan in our Linux based LX series products and
are very happy with its performance.
We have a new task in front of us and it is described as follows:

We will be using a vendor's onboard chip and it has their own IPsec
imbedded in it.  It has no key management (IKE or IKEv2) capabilities.
We are looking into using Strongswan (hopefully) on the host for
IKE/IKEv2 only.  A shim will be developed by us to get the IKE info down
to the chip for IPsec to use.  

1.  Is this possible with Strongswan?
2.  Has anyone accomplished this?

Thanks,
Phil Bellino

Phil Bellino
Software Engineer
MRV Communications, Inc.
295 Foster Street
Littleton, MA. 01460
Phone: 978-952-4807
Fax: 978-952-5444
Email: pbell...@mrv.com 
  



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

Re: [strongSwan] [strongswan] IKE_SA and CHILD_SA cleanup when deleting a connection

2009-05-15 Thread Christophe Gouault

Hi Martin,

Martin Willi wrote:
> Hi Christophe,
>
>   
>> The stroke down tunnel1{*} command would be of great help. When deleting 
>> a connection, I want to remove all CHILD_SAs with that name, and this 
>> command would do the job.
>> 
> I've implemented this functionality, changeset [1].
>   
thanks a lot.
>> When deleting a connection, I would like a cleanup to be done in 
>> IKE_SAs. All IKE_SAs that can no more be used by any connection should 
>> be deleted.
>> 
>
> I'm not sure if this is what you need, but changeset [2] adds a
> "purgeike" command which deletes all IKE_SAs without an associated
> CHILD_SA. After running a "down conn1{*}", you can issue a "stroke
> purgeike" to delete useless IKE_SAs.
>
> Hope this is what you were looking for.
>   
Great, it sounds exactly what I need.
Thank you for your support.

Regards,
Christophe.
> Regards
> Martin
>
> [1]http://wiki.strongswan.org/repositories/diff/strongswan?rev=5cb3210a
> [2]http://wiki.strongswan.org/repositories/diff/strongswan?rev=83242706
>   


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

Re: [strongSwan] [strongswan] IKE_SA and CHILD_SA cleanup when deleting a connection

2009-05-15 Thread Martin Willi

Hi Christophe,

> The stroke down tunnel1{*} command would be of great help. When deleting 
> a connection, I want to remove all CHILD_SAs with that name, and this 
> command would do the job.

I've implemented this functionality, changeset [1].

> When deleting a connection, I would like a cleanup to be done in 
> IKE_SAs. All IKE_SAs that can no more be used by any connection should 
> be deleted.

I'm not sure if this is what you need, but changeset [2] adds a
"purgeike" command which deletes all IKE_SAs without an associated
CHILD_SA. After running a "down conn1{*}", you can issue a "stroke
purgeike" to delete useless IKE_SAs.

Hope this is what you were looking for.

Regards
Martin

[1]http://wiki.strongswan.org/repositories/diff/strongswan?rev=5cb3210a
[2]http://wiki.strongswan.org/repositories/diff/strongswan?rev=83242706


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

Re: [strongSwan] Rekeying via xfrm interface

2009-05-15 Thread Poppelreuter, Wolfgang (EXT-Capgemini - DE/Dusseldorf)

Hello Martin,

Thank you for the replay. I´m send the exact same "xfrm_usersa_info" structure 
inside the expire message that I have received during the sa connection setup 
before. I have set the charon loglevel up to 4 and received the following 
traces:

><

software versions:

Linux version = 2.6.21.7-hrt1 (mips64)
Strongswan version = 4.2.8 

ip xfrm montior output 
---
1. establish connection xfrm messages:
--

src 192.168.203.102/27 dst 192.168.203.130/25 
dir out priority 2730 ptype main 
tmpl src 192.168.203.102 dst 192.168.203.130
proto esp reqid 1 mode tunnel
src 192.168.203.130/25 dst 192.168.203.102/27 
dir in priority 2750 ptype main 
tmpl src 192.168.203.130 dst 192.168.203.102
proto esp reqid 1 mode tunnel
src 192.168.203.130/25 dst 192.168.203.102/27 
dir fwd priority 2750 ptype main 
tmpl src 192.168.203.130 dst 192.168.203.102
proto esp reqid 1 mode tunnel
src 192.168.203.102 dst 192.168.203.130
proto esp spi 0xc4da81c7 reqid 1 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x25aadad6651d40061da021f6221b5a342c1e34d0
enc cbc(aes) 0x6dfe15be45c4ffcf17f1e2210739fc9c
Updated src 192.168.203.130 dst 192.168.203.102
proto esp spi 0xcc2d09b2 reqid 1 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0xc586174ca0c98a5e59b47ce90f8ee72e59e48109
enc cbc(aes) 0xe8ddc14f0f367aa3c38088e12a64ded1
Async event  (0x20)  timer expired 
src 192.168.203.102 dst 192.168.203.130  reqid 0x1 protocol ipv6-crypt  
SPI 0xc4da81c7
Async event  (0x20)  timer expired 
src 192.168.203.130 dst 192.168.203.102  reqid 0x1 protocol ipv6-crypt  
SPI 0xcc2d09b2

2. rekeying xfrm messages:
-
Expired src 192.168.203.102 dst 192.168.203.130
proto esp spi 0xc4da81c7 reqid 1 mode tunnel
replay-window 32 flag 20
hard 0
Expired src 192.168.203.102 dst 192.168.203.130
proto esp spi 0xc4da81c7 reqid 1 mode tunnel
replay-window 32 flag 20
hard 0

syslog output:

 5123 INF 01:03:53 815ms syslogd.c(134) "charon: 09[IKE] authentication of 
'192.168.203.102' (myself) with pre-shared key"
 5124 INF 01:03:53 815ms syslogd.c(134) "charon: 09[AUD] establishing 
CHILD_SA conn1"
 5125 INF 01:03:53 816ms syslogd.c(134) "charon: 09[AUD] establishing 
CHILD_SA conn1"
 5126 INF 01:03:53 816ms syslogd.c(134) "charon: 09[ENC] generating 
IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr ]"
 5127 INF 01:03:53 817ms syslogd.c(134) "charon: 09[NET] sending packet: 
from 192.168.203.102[500] to 192.168.203.130[500]"
 5136 INF 01:03:54  96ms syslogd.c(134) "charon: 10[NET] received packet: 
from 192.168.203.130[500] to 192.168.203.102[500]"
 5137 INF 01:03:54  97ms syslogd.c(134) "charon: 10[ENC] parsed IKE_AUTH 
response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ]"
 5138 INF 01:03:54  97ms syslogd.c(134) "charon: 10[IKE] authentication of 
'192.168.203.130' with pre-shared key successful"
 5139 INF 01:03:54  97ms syslogd.c(134) "charon: 10[IKE] scheduling 
reauthentication in 85618s"
 5140 INF 01:03:54  98ms syslogd.c(134) "charon: 10[IKE] maximum IKE_SA 
lifetime 86158s"
 5141 INF 01:03:54  98ms syslogd.c(134) "charon: 10[AUD] IKE_SA conn1[1] 
established between 
192.168.203.102[192.168.203.102]...192.168.203.130[192.168.203.130]"
 5142 INF 01:03:54  98ms syslogd.c(134) "charon: 10[AUD] IKE_SA conn1[1] 
established between 
192.168.203.102[192.168.203.102]...192.168.203.130[192.168.203.130]"
 5167 INF 01:03:54 109ms syslogd.c(134) "charon: 10[KNL] received netlink 
error: Invalid argument (22)"
 5168 INF 01:03:54 109ms syslogd.c(134) "charon: 10[KNL] unable to install 
source route for 192.168.203.102"
 5211 INF 01:03:54 117ms syslogd.c(134) "charon: 10[AUD] CHILD_SA conn1{1} 
established with SPIs cc2d09b2_i c4da81c7_o and TS 192.168.203.102/27 === 
192.168.203.130/25 &"
 5212 INF 01:03:54 118ms syslogd.c(134) "charon: 10[AUD] CHILD_SA conn1{1} 
established with SPIs cc2d09b2_i c4da81c7_o and TS 192.168.203.102/27 === 
192.168.203.130/25 &"
 5213 INF 01:03:54 118ms syslogd.c(134) "charon: 10[IKE] received 
AUTH_LIFETIME of 85730s, scheduling reauthentication in 85190s"
 5973 INF 01:05:32 650ms syslogd.c(134) "charon: 16[CFG] received stroke: 
loglevel 4 for all"
 6552 INF 01:06:46 315ms syslogd.c(134) "charon: 17[KNL] creating rekey job 
for ESP CHILD_SA with SPI c4da81c7 and reqid {1}"

ipsec statusall after rekeying:
-
000 interface lo/lo ::1:500
000 interface lo/lo 127.0.0.1:500
000 interface eth0/eth0 192.168.255.97:500
000 interface eth1/eth1 192.168.255.113:500
000 interface eth2:1/eth2:1 11.0.0.13:500
000

Re: [strongSwan] Strongswan 4.2.14 broken on ARM ?

[strongSwan] Strongswan 4.2.14 broken on ARM ?

Re: [strongSwan] Looking for advice on IKE

[strongSwan] Looking for advice on IKE

Re: [strongSwan] [strongswan] IKE_SA and CHILD_SA cleanup when deleting a connection

Re: [strongSwan] [strongswan] IKE_SA and CHILD_SA cleanup when deleting a connection

Re: [strongSwan] Rekeying via xfrm interface

7 matches

Site Navigation

Mail list logo

Footer information