headers
Ruben Laban | 2 Feb 2010 20:03
Picon
Favicon

[Openswan dev] Failed test for fix of ipsecX tcpdump bug

Using latest git, the following happens when I try to up a conn using KLIPS:

Feb  2 19:47:10 vn-t-fw01 pluto[4669]: packet from 172.16.2.10:500: ignoring unknown Vendor ID payload [4f454a64436d56714e727861]
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: packet from 172.16.2.10:500: received Vendor ID payload [Dead
Peer Detection]
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: responding to Main Mode
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: STATE_MAIN_R1: sent MR1, expecting MI2
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: STATE_MAIN_R2: sent MR2, expecting MI3
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: Main mode peer ID is ID_IPV4_ADDR: '172.16.2.10'
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #1: the peer proposed: 172.16.4.0/24:0/0 -> 172.16.1.0/24:0/0
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #2: responding to Quick Mode proposal {msgid:b7cacc21}
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #2:     us: 172.16.4.0/24===172.16.3.21<172.16.3.21>[+S=C]---172.16.3.10
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #2:   them: 172.16.2.20---172.16.2.10<172.16.2.10>[+S=C]===172.16.1.0/24
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: | NAT-OA: 0 tunnel: 0  
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA
installed, expecting QI2
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #2: pfkey_lib_debug:pfkey_msg_hdr_build: satype 104
> max 9 
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: "tunnel2" #2: building of pfkey_msg_hdr flow
tun.1001 <at> 172.16.2.10 failed, code -22
Feb  2 19:47:10 vn-t-fw01 pluto[4669]: | raw_eroute result=0 
Feb  2 19:47:15 vn-t-fw01 pluto[4669]: "tunnel2" #3: initiating Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW {using isakmp#1 msgid:4dfa6c49
proposal=3DES(3)_192-MD5(1)_128,
(Continue reading)

Permalink | Reply | 0 comments |
headers
hiren joshi | 3 Feb 2010 16:31
Picon

[Openswan dev] openswan-2.6.24 KLIPS compilation fails for kernel-2.6.18-8

Hello,

I was able to compile openswan-2.6.23 for linux-2.6.18-8 (with a minor
modification related to scatterlist interface).
However openswan-2.6.24 KLIPS compilation fails.
Does some code needs to be wrapped under KERNEL_VERSION(2,6,24) or
some other conditional compilation macro?

[hiren <at> fedora linux-2.6.18.8-crl]$ make
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
  CC [M]  net/ipsec/ipsec_tunnel.o
net/ipsec/ipsec_tunnel.c: In function 'klips_header':
net/ipsec/ipsec_tunnel.c:249: error: 'struct net_device' has no member
named 'header_ops'
net/ipsec/ipsec_tunnel.c: In function 'klips_header_parse':
net/ipsec/ipsec_tunnel.c:278: error: 'struct net_device' has no member
named 'header_ops'
net/ipsec/ipsec_tunnel.c: In function 'klips_rebuild_header':
net/ipsec/ipsec_tunnel.c:331: error: 'struct net_device' has no member
named 'header_ops'
net/ipsec/ipsec_tunnel.c: In function 'klips_header_cache':
net/ipsec/ipsec_tunnel.c:339: warning: passing argument 1 of
'netdev_priv' discards qualifiers from pointer target type
net/ipsec/ipsec_tunnel.c:355: error: 'struct net_device' has no member
named 'header_ops'
net/ipsec/ipsec_tunnel.c: In function 'klips_header_cache_update':
net/ipsec/ipsec_tunnel.c:363: warning: passing argument 1 of
'netdev_priv' discards qualifiers from pointer target type
(Continue reading)

Permalink | Reply | 1 comment |
headers
David McCullough | 3 Feb 2010 23:02

Re: [Openswan dev] openswan-2.6.24 KLIPS compilation fails for kernel-2.6.18-8


Jivin hiren joshi lays it down ...
> Hello,
> 
> I was able to compile openswan-2.6.23 for linux-2.6.18-8 (with a minor
> modification related to scatterlist interface).
> However openswan-2.6.24 KLIPS compilation fails.
> Does some code needs to be wrapped under KERNEL_VERSION(2,6,24) or
> some other conditional compilation macro?

Yes,  this has been fixed in git and will be in 2.6.25,  if you have access
to git you could look there for a diff or just use the git version.

Cheers,
Davidm

> [hiren <at> fedora linux-2.6.18.8-crl]$ make
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   CHK     include/linux/compile.h
>   CC [M]  net/ipsec/ipsec_tunnel.o
> net/ipsec/ipsec_tunnel.c: In function 'klips_header':
> net/ipsec/ipsec_tunnel.c:249: error: 'struct net_device' has no member
> named 'header_ops'
> net/ipsec/ipsec_tunnel.c: In function 'klips_header_parse':
> net/ipsec/ipsec_tunnel.c:278: error: 'struct net_device' has no member
> named 'header_ops'
> net/ipsec/ipsec_tunnel.c: In function 'klips_rebuild_header':
> net/ipsec/ipsec_tunnel.c:331: error: 'struct net_device' has no member
> named 'header_ops'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tuomo Soini | 4 Feb 2010 13:11
Picon
Favicon

[Openswan dev] problem with ASSERTION FAILED

Something has really broken in openswan-2.6. ASSERT doesn't cause core
dump any more. This makes it quite much harder to debug problems.

Anybody know how to fix this?

--

-- 
Tuomo Soini <tis <at> foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>
Permalink | Reply | 8 comments |
headers
David McCullough | 4 Feb 2010 13:21

Re: [Openswan dev] problem with ASSERTION FAILED


Jivin Tuomo Soini lays it down ...
> Something has really broken in openswan-2.6. ASSERT doesn't cause core
> dump any more. This makes it quite much harder to debug problems.
> 
> Anybody know how to fix this?

Looks to me like ASSERT is not used anywhere in openswan.

There is passert() and some others in openswan/passert.h.  This
needs DEBUG to be defined.

You should be able to call assert().

Have a look around the code for assertions and follow their example,

Cheers,
Davidm.

--

-- 
David McCullough,      david_mccullough <at> mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
Permalink | Reply | 7 comments |
headers
Paul Wouters | 4 Feb 2010 15:26
Gravatar

Re: [Openswan dev] problem with ASSERTION FAILED

On Thu, 4 Feb 2010, David McCullough wrote:

>> Something has really broken in openswan-2.6. ASSERT doesn't cause core
>> dump any more. This makes it quite much harder to debug problems.
>>
>> Anybody know how to fix this?
>
> Looks to me like ASSERT is not used anywhere in openswan.
>
> There is passert() and some others in openswan/passert.h.  This
> needs DEBUG to be defined.
>
> You should be able to call assert().
>
> Have a look around the code for assertions and follow their example,

What Tuomo is saying is that the assert/passert calls seem to cause
openswan to crash now, instead of producing a core dump. I do think
there is a problem now with this mechanism. This is also causing
plutorun issues where plutorun is no longer starting a new pluto
process when it detects pluto has crashed.

Paul
Permalink | Reply | 6 comments |
headers
David McCullough | 5 Feb 2010 00:15

Re: [Openswan dev] problem with ASSERTION FAILED


Jivin Paul Wouters lays it down ...
> On Thu, 4 Feb 2010, David McCullough wrote:
> 
> >> Something has really broken in openswan-2.6. ASSERT doesn't cause core
> >> dump any more. This makes it quite much harder to debug problems.
> >>
> >> Anybody know how to fix this?
> >
> > Looks to me like ASSERT is not used anywhere in openswan.
> >
> > There is passert() and some others in openswan/passert.h.  This
> > needs DEBUG to be defined.
> >
> > You should be able to call assert().
> >
> > Have a look around the code for assertions and follow their example,
> 
> What Tuomo is saying is that the assert/passert calls seem to cause
> openswan to crash now, instead of producing a core dump. I do think
> there is a problem now with this mechanism. This is also causing
> plutorun issues where plutorun is no longer starting a new pluto
> process when it detects pluto has crashed.

You should be getting at least a log entry/file/line for any abort that
happens.

It does all it's logging etc and then calls abort (depending on all kinds of
obfuscation of what actually gets called).
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Wouters | 5 Feb 2010 03:07
Gravatar

Re: [Openswan dev] problem with ASSERTION FAILED

On Fri, 5 Feb 2010, David McCullough wrote:

> You should be getting at least a log entry/file/line for any abort that
> happens.

I think what is happening is that we're getting "aborted" within the
process of the abort/logging routines.

This might have to do with errors in the crypto pluto helpers and
signaling in threads.

> This is a ulimit thing by any chance ?

The issue is not so much no core file appearing, but the fact that no
new pluto is spawned.

Paul
Permalink | Reply | 4 comments |
headers
Tuomo Soini | 5 Feb 2010 07:59
Picon
Favicon

Re: [Openswan dev] problem with ASSERTION FAILED

David McCullough wrote:

> Not sure I follow,  you are crashing while trying to log the abort,
> or crashing in the abort routines is hiding something ?

I think again that log tell us more than thousand words.

https://bugs.openswan.org/issues/1086

--

-- 
Tuomo Soini <tis <at> foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>
Permalink | Reply | 2 comments |
headers
David McCullough | 5 Feb 2010 04:11

Re: [Openswan dev] problem with ASSERTION FAILED


Jivin Paul Wouters lays it down ...
> On Fri, 5 Feb 2010, David McCullough wrote:
> 
> > You should be getting at least a log entry/file/line for any abort that
> > happens.
> 
> I think what is happening is that we're getting "aborted" within the
> process of the abort/logging routines.

Not sure I follow,  you are crashing while trying to log the abort,
or crashing in the abort routines is hiding something ?

> This might have to do with errors in the crypto pluto helpers and
> signaling in threads.

Well the helpers could abort and pluto would not exit.  But then
I would have throught pluto would detect the dead helper and just start
another,  perhaps that is a the problem ?

> > This is a ulimit thing by any chance ?
> 
> The issue is not so much no core file appearing, but the fact that no
> new pluto is spawned.

Ok,  which is what I would expect if a helper aborted/asserted I guess.
We may just need some smarts on helper death ?

Cheers,
Davidm
(Continue reading)

Permalink | Reply | 3 comments |

Gmane