[Openswan Users] RHEL4 pluto segmentation faults and restarts

[John Mravunac]

Also I just noticed,

if when using the settings ike=3des and esp=3des, even with IP
forwarding turned off, you ping between the ipsec gateways, the gateway
on which the ping is run will kernel panic immediately.

 

-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of John Mravunac
Sent: Friday, 15 April 2005 2:27 PM
To: users at openswan.org
Subject: RE: [Openswan Users] RHEL4 pluto segmentation faults and
restarts

Adding dumpdir=/tmp did not create any dumps in /tmp, even though pluto
continued to seg fault and restart.

Adding ike=3des and esp=3des did make a difference though. Using these
settings, the connections come up, but then when I enable IP forwarding
I get a kernel panic every time. Enabling IP forwarding when ipsec is
stopped works fine, no panics. But as soon as ipsec is started, just
after the connections are loaded, the kernel panics every time.

Any ideas?

Cheers,
John


-----Original Message-----
From: Paul Wouters [mailto:paul at xelerance.com]
Sent: Thursday, 14 April 2005 11:18 PM
To: John Mravunac
Cc: users at openswan.org
Subject: Re: [Openswan Users] RHEL4 pluto segmentation faults and
restarts

On Thu, 14 Apr 2005, John Mravunac wrote:


Can you add dumpdir=/tmp to config setup and check what the coredump is
telling you? Also, since this error seemed to be triggered by AES, can
you try adding ike=3des and esp=3des and see what happens?

Paul


> After experiencing many problems with running Openswan 2.3.0 on RHEL3,

> I decided to give RHEL4 a try. I compiled and installed both the 
> userland and the KLIPS kernel module and everything appeared to start 
> fine. BUT, then I noticed that no tunnels were up and pluto kept 
> restarting after a segmentation fault:
>
>
> Apr 15 00:47:20 one kernel: Unable to handle kernel NULL pointer 
> dereference at virtual address 00000000 Apr 15 00:47:20 one kernel:
> printing eip:
> Apr 15 00:47:20 one kernel: f8ef67cd
> Apr 15 00:47:20 one kernel: *pde = 3d31a067 Apr 15 00:47:20 one
> kernel: Oops: 0002 [#1] Apr 15 00:47:20 one kernel: Modules linked in:

> ipsec(U) md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core 
> sunrpc button battery ac uhci_hcd ehci_hcd hw_random e1000 e100 mii
> tg3 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod cciss sd_mod 
> scsi_mod
> Apr 15 00:47:20 one kernel: CPU:    0
> Apr 15 00:47:20 one kernel: EIP:    0060:[<f8ef67cd>]    Not tainted
VLI
> Apr 15 00:47:20 one kernel: EFLAGS: 00010202   (2.6.9-5.0.3.EL)
> Apr 15 00:47:20 one ipsec__plutorun: /usr/local/lib/ipsec/_plutorun:
> line 221:  3185 Segmentation fault      /usr/local/libexec/ipsec/pluto
> --nofork --secr
> etsfile /etc/ipsec.secrets --ipsecdir /etc/ipsec.d --debug-none 
> --uniqueids Apr 15 00:47:20 one kernel: EIP is at aes_32+0x3/0x499 
> [ipsec] Apr 15 00:47:20 one ipsec__plutorun: !pluto failure!:  exited 
> with error status 139 (signal 11)
> Apr 15 00:47:20 one kernel: eax: f7936800   ebx: 00000000   ecx:
> 00000004   edx: 00000000
> Apr 15 00:47:20 one ipsec__plutorun: restarting IPsec after pause...
>
>
> I've tried bringing up the tunnels without using the KLIPS kernel 
> module and they appear to work fine, but I really do want all ipsec 
> traffic to pass through an ipsec0 interface.
>
> If anybody has any suggestions as to how I can fix the pluto problem 
> or how to setup the iptables rules when the KLIPS modules is not used,

> I'd be extremely appreciative!
>
> Regards,
> John Mravunac
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
>

-- 

As time passes hardware approaches the effectiveness of a rock and the
reliability of a crack addict.
                                      --- Naubert's law

_______________________________________________
Users mailing list
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users