[Openswan Users] pluto traps in aggressive mode with 2.6.24rc4

[Murat Sezgin]

Hi all,

We are running this version of openswan on our 2 ubicom32 based routers to
establish site-to-site VPN. Main mode works fine, but if we switch to
aggressive mode. pluto crashes on the responder side router. Because of some
limitations of our processor (no-MMU), we are passing the pluto options a
little different. We are not using a ipsec.conf file. So I cannot send you a
conf file now. The pluto and whack options are as below that we passed.

PLUTO_OPTIONS=--nofork --ikeport 500 --secretsfile /etc/ipsec/ipsec.secrets
--ctlbase /var/run/pluto/pluto --interface eth0.1  --nat_traversal
--force_keepalive  --debug-all --stderrlog --virtual_private %v4:
192.168.0.0/16,%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:!192.168.1.0/24

WHACK_OPTS=--name site-to-site-psk --ipv4 --host 10.10.30.131 --ikeport 500
--dpddelay 30 --dpdtimeout 120 --dpdaction clear --updown
/usr/lib/ipsec/_updown_fw --client 192.168.1.0/24 --srcip 192.168.1.1 --to
--host 10.10.30.132 --ikeport 500 --client 192.168.2.0/24 --srcip
192.168.2.1 --ike 3des-md5-modp1024 --esp 3des-md5 --pfs --aggrmode
--pfsgroup modp1024 --ikelifetime 28800 --ipseclifetime 3600 --psk
--encrypt


The back trace is as below.

(gdb) bt
#0  0x42a276a0 in complete_v1_state_transition (mdp=0x427492a0,
result=STF_INLINE)
    at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/ikev1.c:1886
#1  0x42a65ebc in aggr_inI1_outR1_continue1 (pcrc=<value optimized out>,
r=0x4267e52c, ugh=<value optimized out>)
    at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/ikev1_aggr.c:207
#2  0x42a51298 in send_crypto_helper_request (r=0x4267e52c, cn=0x42749134,
toomuch=0x4267e528)
    at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/pluto_crypt.c:415
#3  0x42a51b48 in build_ke (cn=0x42749134, st=0x42748b00, group=<value
optimized out>, importance=<value optimized out>)
    at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/crypt_ke.c:201
#4  0x42a65a4c in aggr_inI1_outR1_common (md=0x427477c8, authtype=<value
optimized out>)
    at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/ikev1_aggr.c:366
#5  0x42a65aa4 in aggr_inI1_outR1_psk (md=0x4c49b2bb) at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/ikev1_aggr.c:381
#6  0x42a29270 in process_packet_tail (mdp=<value optimized out>) at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/ikev1.c:1833
#7  0x42a29df4 in process_v1_packet (mdp=0x429520c8) at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/ikev1.c:1375
#8  0x42a4b980 in process_packet (mdp=0x429520c8) at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/demux.c:163
#9  0x42a4ba24 in comm_handle (ifp=<value optimized out>) at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/demux.c:212
#10 0x42a2283c in call_server () at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/server.c:755
#11 0x42a1fd6c in main (argc=14, argv=0x4267fcb4) at
/scratch2/twu/openwrt_vpnrouter/ubicom-linux-dist-1.2.1/openwrt/build_dir/linux-ubicom32_IP7160RGW/openswan-2.6.24rc4/programs/pluto/plutomain.c:952


It seems, in the complete_v1_state_transition() functions the *mdp comes
corrupted. Because we are assigning its value to "struct msg_digest *md" and
md->st always shows an invalid memory address which is not in the address
range of our memory.

I wonder, if somebody has seen this crash. And our config options are true
on above?

Can someone help us?

Regards,
Murat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20101015/0678eb02/attachment.html