[Openswan dev] ARM unaligned bug

Albert Veli albert.veli at gmail.com
Fri Jan 22 05:40:50 EST 2010

Hello again,

> If it's not too much trouble, can you give us a traceback from a crash
> where the original passert fails?  It might help me understand how
> this happens.

Here is the log file (from the responder):

added connection description "ipsec1"
listening for IKE messages
NAT-Traversal: Trying new style NAT-T
NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family
IPv4 (errno=19)
NAT-Traversal: Trying old style NAT-T
adding interface vlan10/vlan10
adding interface vlan10/vlan10
adding interface vlan1/vlan1
adding interface vlan1/vlan1
adding interface lo/lo
adding interface lo/lo
packet from received Vendor ID payload [Dead Peer Detection]
packet from received Vendor ID payload [RFC 3947]
method set to=109
packet from received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109
packet from received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method
packet from received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109
packet from received Vendor ID payload
"ipsec1"[1] #1: Aggressive mode peer ID is ID_FQDN: '@init'
"ipsec1"[1] #1: responding to Aggressive Mode, state #1,
connection "ipsec1" from
"ipsec1"[1] #1: enabling possible NAT-traversal with method 4

// Here comes the assert

"ipsec1"[1] #1: ASSERTION FAILED at

"ipsec1"[1] #1: using kernel interface: netkey
"ipsec1"[1] #1: interface lo/lo
"ipsec1"[1] #1: interface lo/lo
"ipsec1"[1] #1: interface vlan1/vlan1
"ipsec1"[1] #1: interface vlan1/vlan1
"ipsec1"[1] #1: interface vlan10/vlan10
"ipsec1"[1] #1: interface vlan10/vlan10
"ipsec1"[1] #1: %myid = (none)
"ipsec1"[1] #1: debug none
"ipsec1"[1] #1:
"ipsec1"[1] #1: virtual_private (%priv):
"ipsec1"[1] #1: - allowed 0 subnets:
"ipsec1"[1] #1: - disallowed 0 subnets:
"ipsec1"[1] #1: WARNING: Either virtual_private= was not
specified, or there was a syntax
"ipsec1"[1] #1:          error in that line.
'left/rightsubnet=%priv' will not work!
"ipsec1"[1] #1:
"ipsec1"[1] #1: algorithm ESP encrypt: id=2, name=ESP_DES,
ivlen=8, keysizemin=64, keysizemax=64
"ipsec1"[1] #1: algorithm ESP encrypt: id=3,
name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
"ipsec1"[1] #1: algorithm ESP encrypt: id=12,
name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
"ipsec1"[1] #1: algorithm ESP encrypt: id=14,
name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
"ipsec1"[1] #1: algorithm ESP encrypt: id=15,
name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
"ipsec1"[1] #1: algorithm ESP encrypt: id=16,
name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
"ipsec1"[1] #1: algorithm ESP encrypt: id=18,
name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
"ipsec1"[1] #1: algorithm ESP encrypt: id=19,
name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
"ipsec1"[1] #1: algorithm ESP encrypt: id=20,
name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
"ipsec1"[1] #1: algorithm ESP auth attr: id=1,
name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
"ipsec1"[1] #1: algorithm ESP auth attr: id=2,
name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
"ipsec1"[1] #1:
"ipsec1"[1] #1: algorithm IKE encrypt: id=0, name=(null),
blocksize=16, keydeflen=131
"ipsec1"[1] #1: algorithm IKE encrypt: id=5,
name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
"ipsec1"[1] #1: algorithm IKE encrypt: id=7,
name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
"ipsec1"[1] #1: algorithm IKE hash: id=1, name=OAKLEY_MD5,
"ipsec1"[1] #1: algorithm IKE hash: id=2,
name=OAKLEY_SHA1, hashsize=20
"ipsec1"[1] #1: algorithm IKE dh group: id=2,
name=OAKLEY_GROUP_MODP1024, bits=1024
"ipsec1"[1] #1: algorithm IKE dh group: id=5,
name=OAKLEY_GROUP_MODP1536, bits=1536
"ipsec1"[1] #1: algorithm IKE dh group: id=14,
name=OAKLEY_GROUP_MODP2048, bits=2048
"ipsec1"[1] #1: algorithm IKE dh group: id=15,
name=OAKLEY_GROUP_MODP3072, bits=3072
"ipsec1"[1] #1: algorithm IKE dh group: id=16,
name=OAKLEY_GROUP_MODP4096, bits=4096
"ipsec1"[1] #1: "ipsec1"[1]:<>[@arg,+S=C]...[@init,+S=C]===;
unrouted; eroute owner: #0
"ipsec1"[1] #1: "ipsec1"[1]:     myip=; hisip=unset;
"ipsec1"[1] #1: "ipsec1"[1]:   ike_life: 3600s;
ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries:
"ipsec1"[1] #1: "ipsec1"[1]:   policy:
interface: vlan10;
"ipsec1"[1] #1: "ipsec1"[1]:   dpd: action:clear;
delay:30; timeout:120;
"ipsec1"[1] #1: "ipsec1"[1]:   newest ISAKMP SA: #0;
newest IPsec SA: #0;
"ipsec1"[1] #1: "ipsec1"[1]:   IKE algorithms wanted:
AES_CBC(7)_128-SHA1(2)-MODP1024(2); flags=-strict
"ipsec1"[1] #1: "ipsec1"[1]:   IKE algorithms found:
"ipsec1"[1] #1: "ipsec1"[1]:   ESP algorithms wanted:
AES(12)_128-SHA1(2); flags=-strict
"ipsec1"[1] #1: "ipsec1"[1]:   ESP algorithms loaded:
"ipsec1"[1] #1:
"ipsec1"[1] #1: #1: "ipsec1"[1]
STATE_AGGR_R1 (sent AR1, expecting AI2); EVENT_CRYPTO_FAILED in 300s;
lastdpd=-1s(seq in:0 out:0); idle; import:respond to stranger
"ipsec1"[1] #1:
"ipsec1"[1] #1: ABORT at
"ipsec1"[1] #1: ABORT at
pluto_crypto_helper: helper (0) is  normal exiting

And here is some information from the debugger:

(gdb) backtrace
#0  out_modify_previous_np (np=20 '\024', outs=0x11d8d8) at
#1  0x0006fc44 in nat_traversal_add_natd (np=13 '\r', outs=0x11d8d8,
md=0x11d808) at
#2  0x0007bf80 in aggr_inI1_outR1_tail (pcrc=0x11f728, r=0xbe9c7814)
at /home/albert/trunk/packages/openswan/openswan-2.6.24/programs/pluto/ikev1_aggr.c:532
#3  0x0007aec4 in aggr_inI1_outR1_continue2 (pcrc=0x11f728,
r=0xbe9c7814, ugh=0x0) at
#4  0x00061ccc in handle_helper_comm (w=0x11bf00) at
#5  0x0006268c in pluto_crypto_helper_ready (readfds=0xbe9ca61c) at
#6  0x000254ec in call_server () at
#7  0x0002159c in main (argc=9, argv=0xbe9cab74) at

(gdb) x /80x outs->start
0x108a80 <reply_buffer>:	0x1587effe	0x3c648dfa	0x657bebe5	0x302505f1
0x108a90 <reply_buffer+16>:	0x01100400	0x00000000	0x00000170	0x04000038
0x108aa0 <reply_buffer+32>:	0x00000001	0x00000001	0x0000002c	0x00010001
0x108ab0 <reply_buffer+48>:	0x00000024	0x00010000	0x800b0001	0x800c0e10
0x108ac0 <reply_buffer+64>:	0x80010007	0x80020002	0x80030001	0x80040002
0x108ad0 <reply_buffer+80>:	0x800e0080	0x0a000084	0x1133a7d9	0x58761578
0x108ae0 <reply_buffer+96>:	0x9afbc6a2	0x2ab3f6fb	0x19301281	0xb9967335
0x108af0 <reply_buffer+112>:	0x6bf8e17f	0x99b57a64	0xcc270055	0x595f40e2
0x108b00 <reply_buffer+128>:	0x8a89836c	0xdb8252ac	0xd4860c36	0x07b3e716
0x108b10 <reply_buffer+144>:	0x8e1dd750	0x2f9173b0	0x4465a68e	0xa7a941fd
0x108b20 <reply_buffer+160>:	0x647e4dcd	0xf61c2068	0xbbf0d9ce	0x4770441e
0x108b30 <reply_buffer+176>:	0xcd5be431	0xf2671477	0x83274ab2	0xdd0b68dc
0x108b40 <reply_buffer+192>:	0x8a4bf363	0x1f5231d8	0xc0cc7b81	0xcc28cd2c
0x108b50 <reply_buffer+208>:	0x89574a39	0xdf2441ab	0x05000014	0x0139f448
0x108b60 <reply_buffer+224>:	0x9767c81d	0xa5083f7f	0x02e41421	0x0800000b
0x108b70 <reply_buffer+240>:	0x02000000	0x6172670d	0x000018bc	0x315794ea
0x108b80 <reply_buffer+256>:	0xf1863188	0xc4739bf4	0xf15cea92	0x067ac30d
0x108b90 <reply_buffer+272>:	0x000014af	0xcad71368	0xa1f1c96b	0x8696fc77
0x108ba0 <reply_buffer+288>:	0x57010000	0x00000000	0x00000000	0x00000000
0x108bb0 <reply_buffer+304>:	0x00000000	0x00000000	0x00000000	0x00000000

// The passert is at line 1688

(gdb) break 1688
Breakpoint 2 at 0xc09b0: file
line 1688.
(gdb) cont

Breakpoint 2, out_modify_previous_np (np=20 '\024', outs=0x11d8d8) at
(gdb) print left
$1 = 20
(gdb) print pllen
$2 = 20

(gdb) x pl
0x108b8f <reply_buffer+271>:	0x0d000014

And there is the value that will trigger the assert. 0x0d is ISAKMP_NEXT_VID.

I hope this is the information you need. Just tell me if you need more
information to trace it down.

Best regards,


More information about the Dev mailing list