From: "Beschorner Daniel" <[EMAIL PROTECTED]>
Date: Tue, 17 Jul 2007 21:03:20 +0200
> > >>> I managed to reproduce a crash with ipcomp, will try to
> > fix it later.
> > >>>
> > >> Yes, I can confirm this.
> > >> After disabling IPComp the crashes went away.
> > >>
> > > The crash hap
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 17 Jul 2007 18:10:13 +0200
> [XFRM]: Fix crash introduced by struct dst_entry reordering
>
> XFRM expects xfrm_dst->u.next to be same pointer as dst->next, which
> was broken by the dst_entry reordering in commit 1e19e02c~, causing
> an oops in
Beschorner Daniel wrote:
>>I fixed it myself. Daniel, can you please test this patch?
>
>
> Many thanks Patrick!!!
> I tested it and found it working!
Thanks for testing.
> No more crashes with IPComp and smaller PMTUs.
> But the "pmtu discovery on SA ESP/..." messages don't disappear.
Thats
> >>> I managed to reproduce a crash with ipcomp, will try to
> fix it later.
> >>>
> >> Yes, I can confirm this.
> >> After disabling IPComp the crashes went away.
> >>
> > The crash happens in xfrm_bundle_ok when walking the bundle upwards
> > following xfrm_dst->u.next. The loop sho
Patrick McHardy wrote:
Beschorner Daniel wrote:
I managed to reproduce a crash with ipcomp, will try to fix it later.
Yes, I can confirm this.
After disabling IPComp the crashes went away.
The crash happens in xfrm_bundle_ok when walking the bundle upwards
following xfrm_dst->
Beschorner Daniel wrote:
>>I managed to reproduce a crash with ipcomp, will try to fix it later.
>
>
> Yes, I can confirm this.
> After disabling IPComp the crashes went away.
The crash happens in xfrm_bundle_ok when walking the bundle upwards
following xfrm_dst->u.next. The loop should be stop
> Today a new site joined our Linux IPSec VPN, now all the
> other routers (all 2.6.22) freeze hard reproducible.
> No oops, no sysreq, only hard reset rewakes them.
Ok, I did a longer test and nothing crashed in the mean time without
IPComp.
So it really must have been the reason.
BTW now I see
> >>Did you turn on IPSec compression?
> >
> >
> >
> > No. Please send the policy you're using.
>
>
> I managed to reproduce a crash with ipcomp, will try to fix it later.
Yes, I can confirm this.
After disabling IPComp the crashes went away.
Thank you
Daniel
-
To unsubscribe from this list
Patrick McHardy wrote:
> Beschorner Daniel wrote:
>
>>>I recreated the same setup here, but things work fine even with
>>>different MTUs. Please try to narrow it down further or capture
>>>some more information (serial console/netconsole,
>>>CONFIG_DETECT_SOFTLOCKUP, ..).
>>
>>
>>Did you turn on I
Patrick McHardy wrote:
> Beschorner Daniel wrote:
>
>>>I recreated the same setup here, but things work fine even with
>>>different MTUs. Please try to narrow it down further or capture
>>>some more information (serial console/netconsole,
>>>CONFIG_DETECT_SOFTLOCKUP, ..).
>>
>>
>>Did you turn on I
Beschorner Daniel wrote:
>>I recreated the same setup here, but things work fine even with
>>different MTUs. Please try to narrow it down further or capture
>>some more information (serial console/netconsole,
>>CONFIG_DETECT_SOFTLOCKUP, ..).
>
>
> Did you turn on IPSec compression?
No. Please
> I recreated the same setup here, but things work fine even with
> different MTUs. Please try to narrow it down further or capture
> some more information (serial console/netconsole,
> CONFIG_DETECT_SOFTLOCKUP, ..).
Did you turn on IPSec compression?
-
To unsubscribe from this list: send the lin
Beschorner Daniel wrote:
>>I'm running IPsec in the same setup as you describe above without
>>problems. I'm probably not seeing ICMP frag requireds on the wire
>>though since I believe the entire path is >= 1492.
>>
>>Could you try to find out whether those are responsible?
>>
>
>
> It's definit
> Today a new site joined our Linux IPSec VPN, now all the
> >>>
> >>>other routers
> >>>
> (all 2.6.22) freeze hard reproducible.
> >
> >
> > The problem is more general und ugly than I thought.
> >
> > I took 2 arbitrary boxes, one behind an Ethernet (A, Kernel
> 2.6.21, MTU
> > 1500
Beschorner Daniel wrote:
Today a new site joined our Linux IPSec VPN, now all the
>>>
>>>other routers
>>>
(all 2.6.22) freeze hard reproducible.
>
>
> The problem is more general und ugly than I thought.
>
> I took 2 arbitrary boxes, one behind an Ethernet (A, Kernel 2.6.21, MTU
> 1500
> > > Today a new site joined our Linux IPSec VPN, now all the
> > other routers
> > > (all 2.6.22) freeze hard reproducible.
The problem is more general und ugly than I thought.
I took 2 arbitrary boxes, one behind an Ethernet (A, Kernel 2.6.21, MTU
1500), one behind ADSL (B, 2.4.x, 1492).
Esta
> Beschorner Daniel wrote:
> > Today a new site joined our Linux IPSec VPN, now all the
> other routers
> > (all 2.6.22) freeze hard reproducible.
>
> Do the other routers all do IPsec or just one of them?
They all do IPSec, that seems to be their mistake.
The unencrypted traffic between the rou
Beschorner Daniel wrote:
> Today a new site joined our Linux IPSec VPN, now all the other routers
> (all 2.6.22) freeze hard reproducible.
Do the other routers all do IPsec or just one of them?
> No oops, no sysreq, only hard reset rewakes them.
>
> The only difference of the new site compared
Today a new site joined our Linux IPSec VPN, now all the other routers
(all 2.6.22) freeze hard reproducible.
No oops, no sysreq, only hard reset rewakes them.
The only difference of the new site compared to the others: ADSL, thus a
MTU of 1492, the others have 1500.
Disabling IPSec und doing norm
From: Olaf Kirch <[EMAIL PROTECTED]>
Date: Wed, 8 Feb 2006 12:59:37 +0100
> On Wed, Feb 08, 2006 at 07:46:48AM +1100, Herbert Xu wrote:
> > I suggest that we simply bail out always. If the dst decides to die
> > on us later on, the packet will be dropped anyway. So there is no
> > great urgency
On Wed, Feb 08, 2006 at 07:46:48AM +1100, Herbert Xu wrote:
> I suggest that we simply bail out always. If the dst decides to die
> on us later on, the packet will be dropped anyway. So there is no
> great urgency to retry here. Once we have the proper resolution
> queueing, we can then do the r
Olaf Kirch <[EMAIL PROTECTED]> wrote:
>
> People have been testing with the patch below, which seems to fix the
> problem partially. They still see connection hangs however (things
> only clear up when they start a new ping or new ssh). So the patch
> is obvsiouly not sufficient, and something els
Hi,
there's a problem with IPsec that has been bugging some of our users
for the last couple of kernel revs. Every now and then, IPsec will
freeze the machine completely. This is with openswan user land,
and with kernels up to and including 2.6.16-rc2.
I managed to debug this a little, and what h
23 matches
Mail list logo
