Re: IPSec freeze

Re: IPSec freeze

[Beschorner Daniel]

> 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 the "pmtu discovery on SA" regression in 2.6.22, there is
already another thread about.
With 2.6.15 we had this already, but a patch from Herbert fixed it (TOS
field matching in ICMP IIRC).

Daniel

IPSec freeze

[Beschorner Daniel]

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 normal operations between the routers is fine,
PMTU is honored correctly.
If I set the MTU of the other routers to 1492 I can avoid the IPSec
crash.

Some kind of strange need-to-frag-ICMP that causes such things?
Any ideas how to debug this?

Thanks!
Daniel

Here a tcpdump of a router (1.1.1.1, obfuscated) just before it died:

07:58:23.588064 IP (tos 0x0, ttl  64, id 8192, offset 0, flags [DF],
proto: ESP (50), length: 1496) 1.1.1.1 > 2.2.2.2:
ESP(spi=0xae81babb,seq=0x15), length 1476
07:58:23.590414 IP (tos 0x0, ttl  48, id 22785, offset 0, flags [DF],
proto: ESP (50), length: 152) 2.2.2.2 > 1.1.1.1:
ESP(spi=0x593f3550,seq=0xf), length 132
07:58:23.592928 IP (tos 0x0, ttl  48, id 22785, offset 0, flags [DF],
proto: ESP (50), length: 104) 2.2.2.2 > 1.1.1.1:
ESP(spi=0x593f3550,seq=0x10), length 84
07:58:23.593246 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
ESP (50), length: 1496) 1.1.1.1 > 2.2.2.2: ESP(spi=0xae81babb,seq=0x16),
length 1476
07:58:23.596486 IP (tos 0x0, ttl  48, id 22785, offset 0, flags [DF],
proto: ESP (50), length: 152) 2.2.2.2 > 1.1.1.1:
ESP(spi=0x593f3550,seq=0x11), length 132
07:58:23.596806 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
ESP (50), length: 1496) 1.1.1.1 > 2.2.2.2: ESP(spi=0xae81babb,seq=0x17),
length 1476
07:58:23.596859 IP (tos 0x0, ttl  64, id 10655, offset 0, flags [DF],
proto: ESP (50), length: 200) 1.1.1.1 > 2.2.2.2:
ESP(spi=0xae81babb,seq=0x18), length 180
07:58:23.726550 IP (tos 0x0, ttl  50, id 8192, offset 0, flags [none],
proto: ICMP (1), length: 56) 67.38.70.235 > 1.1.1.1: ICMP 2.2.2.2
unreachable - need to frag (mtu 1492), length 36
        IP (tos 0x0, ttl  45, id 8192, offset 0, flags [DF], proto: ESP
(50), length: 1496) 1.1.1.1 > 2.2.2.2: [|ESP]
07:58:23.731648 IP (tos 0x0, ttl  50, id 0, offset 0, flags [none],
proto: ICMP (1), length: 56) 67.38.70.235 > 1.1.1.1: ICMP 2.2.2.2
unreachable - need to frag (mtu 1492), length 36
        IP (tos 0x0, ttl  45, id 0, offset 0, flags [DF], proto: ESP
(50), length: 1496) 1.1.1.1 > 2.2.2.2: [|ESP]
07:58:23.734776 IP (tos 0x0, ttl  50, id 0, offset 0, flags [none],
proto: ICMP (1), length: 56) 67.38.70.235 > 1.1.1.1: ICMP 2.2.2.2
unreachable - need to frag (mtu 1492), length 36
        IP (tos 0x0, ttl  45, id 0, offset 0, flags [DF], proto: ESP
(50), length: 1496) 1.1.1.1 > 2.2.2.2: [|ESP]
07:58:23.740504 IP (tos 0x0, ttl  48, id 22785, offset 0, flags [DF],
proto: ESP (50), length: 104) 2.2.2.2 > 1.1.1.1:
ESP(spi=0x593f3550,seq=0x12), length 84
07:58:23.743108 IP (tos 0x0, ttl  48, id 22785, offset 0, flags [DF],
proto: ESP (50), length: 104) 2.2.2.2 > 1.1.1.1:
ESP(spi=0x593f3550,seq=0x13), length 84
07:58:23.754123 IP (tos 0x0, ttl  48, id 22785, offset 0, flags [DF],
proto: ESP (50), length: 104) 2.2.2.2 > 1.1.1.1:
ESP(spi=0x593f3550,seq=0x14), length 84

Here a log of another death from inside the tunnel (last packet is again
the time of crash):
The Tunnel MTU of 1430 is correct for an outer MTU of 1500, but the
additional -8 doesn't take place?!?

05:17:18.563448 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1460
05:17:18.563468 IP 192.168.200.254 > 192.168.200.1: ICMP 192.168.203.1
unreachable - need to frag (mtu 1430), length 556
05:17:18.563471 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1460
05:17:18.563479 IP 192.168.200.254 > 192.168.200.1: ICMP 192.168.203.1
unreachable - need to frag (mtu 1430), length 556
05:17:18.563481 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1460
05:17:18.563490 IP 192.168.200.254 > 192.168.200.1: ICMP 192.168.203.1
unreachable - need to frag (mtu 1430), length 556
05:17:18.563492 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1460
05:17:18.563499 IP 192.168.200.254 > 192.168.200.1: ICMP 192.168.203.1
unreachable - need to frag (mtu 1430), length 556
05:17:18.563616 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1390
05:17:18.882785 IP 192.168.203.1.3084 > 192.168.200.1.80: tcp 0
05:17:18.882921 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1390
05:17:18.883097 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1390
05:17:19.042207 IP 192.168.203.1.3084 > 192.168.200.1.80: tcp 0

Re: IPSec freeze

[Patrick McHardy]

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 to the others: ADSL, thus a
> MTU of 1492, the others have 1500.
> Disabling IPSec und doing normal operations between the routers is fine,
> PMTU is honored correctly.
> If I set the MTU of the other routers to 1492 I can avoid the IPSec
> crash.
> 
> Some kind of strange need-to-frag-ICMP that causes such things?
> Any ideas how to debug this?


If you can't get any information from your boxes, a testcase that can
be used to reproduce this would help.

> Here a log of another death from inside the tunnel (last packet is again
> the time of crash):
> The Tunnel MTU of 1430 is correct for an outer MTU of 1500, but the
> additional -8 doesn't take place?!?
> 
> 05:17:18.563448 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1460
> 05:17:18.563468 IP 192.168.200.254 > 192.168.200.1: ICMP 192.168.203.1
> unreachable - need to frag (mtu 1430), length 556


Does the router use a MTU of 1492 itself or is there another DSL
router or something like that connected by ethernet?

Re: IPSec freeze

[Beschorner Daniel]

> 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 routers work fine, only tunnel
traffic triggers the crash.

> 
> > 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 normal operations between the 
> routers is fine,
> > PMTU is honored correctly.
> > If I set the MTU of the other routers to 1492 I can avoid the IPSec
> > crash.
> > 
> > Some kind of strange need-to-frag-ICMP that causes such things?
> > Any ideas how to debug this?
> 
> 
> If you can't get any information from your boxes, a testcase that can
> be used to reproduce this would help.

I'll try to get more information about what is the fatal in this
configuration.
I'm surely not the first one doing VPN with different MTUs.

The only "anomaly" I've seen is that the need-to-frag complaining router
DOES fragment the oversized packet and relays it ignoring the DF flag.

Is there something I can do to debug the network stack in any way? As I
said, I can perfectly reproduce it, but I'm poor in getting information
what's going on in the kernel.

I will do some more tests, disabling Ipsec compression, etc.

> 
> > Here a log of another death from inside the tunnel (last 
> packet is again
> > the time of crash):
> > The Tunnel MTU of 1430 is correct for an outer MTU of 1500, but the
> > additional -8 doesn't take place?!?
> > 
> > 05:17:18.563448 IP 192.168.200.1.80 > 192.168.203.1.3084: tcp 1460
> > 05:17:18.563468 IP 192.168.200.254 > 192.168.200.1: ICMP 
> 192.168.203.1
> > unreachable - need to frag (mtu 1430), length 556
> 
> 
> Does the router use a MTU of 1492 itself or is there another DSL
> router or something like that connected by ethernet?

The router on the ADSL line (behind an ADSL Netopia router via Ethernet)
crashed too with 1500, now it uses 1492.

Re: IPSec freeze

[Beschorner Daniel]

> > > 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).
Established a tunnel, copied a file from site A to B through the tunnel
and router A died in the same moment.

Out of my feeling this worked fine some kernel releases earlier.

As written in this thread before, I see an external need-to-frag-ICMP,
no tunnel need-to-frag will be thrown, box freezes.

You should be able to reproduce it with any network path with a smaller
MTU?!?

Daniel

Re: IPSec freeze

[Patrick McHardy]

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), one behind ADSL (B, 2.4.x, 1492).
> Established a tunnel, copied a file from site A to B through the tunnel
> and router A died in the same moment.
> 
> Out of my feeling this worked fine some kernel releases earlier.
> 
> As written in this thread before, I see an external need-to-frag-ICMP,
> no tunnel need-to-frag will be thrown, box freezes.
> 
> You should be able to reproduce it with any network path with a smaller
> MTU?!?


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?

Re: IPSec freeze

[Beschorner Daniel]

> >>>>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).
> > Established a tunnel, copied a file from site A to B 
> through the tunnel
> > and router A died in the same moment.
> > 
> > Out of my feeling this worked fine some kernel releases earlier.
> > 
> > As written in this thread before, I see an external 
> need-to-frag-ICMP,
> > no tunnel need-to-frag will be thrown, box freezes.
> > 
> > You should be able to reproduce it with any network path 
> with a smaller
> > MTU?!?
> 
> 
> 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 definitely the first large packet or corresponding ICMP that
triggers the crash, slow packets don't harm.
IPSec on pathes with a PMTU of 1500 works fine.

Re: IPSec freeze

[Patrick McHardy]

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 definitely the first large packet or corresponding ICMP that
> triggers the crash, slow packets don't harm.
> IPSec on pathes with a PMTU of 1500 works fine.


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, ..).

Re: IPSec freeze

[Beschorner Daniel]

> 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? 

Re: IPSec freeze

[Patrick McHardy]

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 send the policy you're using.

Re: IPSec freeze

[Patrick McHardy]

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 IPSec compression? 
> 
> 
> 
> No. Please send the policy you're using.


And please try disabling ipcomp yourself to see if it makes a difference.

Re: IPSec freeze

[Patrick McHardy]

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 IPSec compression? 
> 
> 
> 
> No. Please send the policy you're using.


I managed to reproduce a crash with ipcomp, will try to fix it later.

Re: IPSec freeze

[Beschorner Daniel]

> >>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

Re: IPSec freeze

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

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 stopped when
xfrm_dst->u.next == first (the topmost xfrm_dst), but it points to
NULL instead. I'm pretty sure the attached patch is responsible,
it breaks XFRM's assumption that dst->next and xfrm_dst->u.next are
the same pointer and xfrm_dst now shares the next pointer with
rcu_head.next in struct dst_entry.

Eric, could you look into this please?

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1910 bytes --]

[NET]: Reorder fields of struct dst_entry

This last patch (but not least :) ) finally moves the next pointer at
the end of struct dst_entry. This permits to perform route cache
lookups with a minimal cost of one cache line per entry, instead of
two.

Both 32bits and 64bits platforms benefit from this new layout.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
commit 1e19e02ca0c5e33ea73a25127dbe6c3b8fcaac4b
tree 23afba2945a9e09b137b094a868ea176c1e1c800
parent 0c195c3fc4e95a06b0c0017506f074c94af99c35
author Eric Dumazet <dada1@cosmosbay.com> Fri, 09 Feb 2007 16:26:55 -0800
committer David S. Miller <davem@sunset.davemloft.net> Sat, 10 Feb 2007 23:20:45 -0800

 include/net/dst.h |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/net/dst.h b/include/net/dst.h
index 5d62342..e12a8ce 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -37,14 +37,7 @@ struct sk_buff;
 
 struct dst_entry
 {
-	union {
-		struct dst_entry *next;
-		struct rtable    *rt_next;
-		struct rt6_info   *rt6_next;
-		struct dn_route  *dn_next;
-	};
-	atomic_t		__refcnt;	/* client references	*/
-	int			__use;
+	struct rcu_head		rcu_head;
 	struct dst_entry	*child;
 	struct net_device       *dev;
 	short			error;
@@ -55,7 +48,6 @@ struct dst_entry
 #define DST_NOPOLICY		4
 #define DST_NOHASH		8
 #define DST_BALANCED            0x10
-	unsigned long		lastuse;
 	unsigned long		expires;
 
 	unsigned short		header_len;	/* more space at head required */
@@ -80,8 +72,16 @@ struct dst_entry
 #endif
 
 	struct  dst_ops	        *ops;
-	struct rcu_head		rcu_head;
 		
+	unsigned long		lastuse;
+	atomic_t		__refcnt;	/* client references	*/
+	int			__use;
+	union {
+		struct dst_entry *next;
+		struct rtable    *rt_next;
+		struct rt6_info   *rt6_next;
+		struct dn_route  *dn_next;
+	};
 	char			info[0];
 };
 

Re: IPSec freeze

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

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->u.next. The loop should be stopped when
> xfrm_dst->u.next == first (the topmost xfrm_dst), but it points to
> NULL instead. I'm pretty sure the attached patch is responsible,
> it breaks XFRM's assumption that dst->next and xfrm_dst->u.next are
> the same pointer and xfrm_dst now shares the next pointer with
> rcu_head.next in struct dst_entry.
>
> Eric, could you look into this please?

I fixed it myself. Daniel, can you please test this patch?




[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1543 bytes --]

[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 xfrm_bundle_ok when walking the bundle upwards.

Kill xfrm_dst->u.next and change the only user to use dst->next instead.

Signed-off-by: Patrick McHardy <kaber@trash.net>

---
commit 20c2fee8cc562817f11752e1d87350d5994fa098
tree f42318b847e962aa637136e94722a688c231111a
parent 308ac1b6249226730b70fcf7c13a289c27ce2bf3
author Patrick McHardy <kaber@trash.net> Tue, 17 Jul 2007 18:11:29 +0200
committer Patrick McHardy <kaber@trash.net> Tue, 17 Jul 2007 18:11:29 +0200

 include/net/xfrm.h     |    1 -
 net/xfrm/xfrm_policy.c |    2 +-
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index ae959e9..a5f80bf 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -585,7 +585,6 @@ static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ct
 struct xfrm_dst
 {
 	union {
-		struct xfrm_dst		*next;
 		struct dst_entry	dst;
 		struct rtable		rt;
 		struct rt6_info		rt6;
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 157bfbd..b48f06f 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2141,7 +2141,7 @@ int xfrm_bundle_ok(struct xfrm_policy *pol, struct xfrm_dst *first,
 		if (last == first)
 			break;
 
-		last = last->u.next;
+		last = (struct xfrm_dst *)last->u.dst.next;
 		last->child_mtu_cached = mtu;
 	}
 

Re: IPSec freeze

[Beschorner Daniel]

> >>> 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 stopped when
> > xfrm_dst->u.next == first (the topmost xfrm_dst), but it points to
> > NULL instead. I'm pretty sure the attached patch is responsible,
> > it breaks XFRM's assumption that dst->next and xfrm_dst->u.next are
> > the same pointer and xfrm_dst now shares the next pointer with
> > rcu_head.next in struct dst_entry.
> >
> > Eric, could you look into this please?
> 
> I fixed it myself. Daniel, can you please test this patch?

Many thanks Patrick!!!
I tested it and found it working!

No more crashes with IPComp and smaller PMTUs.
But the "pmtu discovery on SA ESP/..." messages don't disappear.

Daniel

Re: IPSec freeze

[Patrick McHardy]

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 probably a different issue. Please post the output of
"ip -x xfrm state" (obfuscate keys if you care ..).

Re: IPSec freeze

[David Miller]

From: "Beschorner Daniel" <Daniel.Beschorner@facton.com>
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 happens in xfrm_bundle_ok when walking the bundle upwards
> > > following xfrm_dst->u.next. The loop should be stopped when
> > > xfrm_dst->u.next == first (the topmost xfrm_dst), but it points to
> > > NULL instead. I'm pretty sure the attached patch is responsible,
> > > it breaks XFRM's assumption that dst->next and xfrm_dst->u.next are
> > > the same pointer and xfrm_dst now shares the next pointer with
> > > rcu_head.next in struct dst_entry.
> > >
> > > Eric, could you look into this please?
> > 
> > I fixed it myself. Daniel, can you please test this patch?
> 
> Many thanks Patrick!!!
> I tested it and found it working!

Thank you for testing.

Re: IPSec freeze

[David Miller]

From: Patrick McHardy <kaber@trash.net>
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 xfrm_bundle_ok when walking the bundle upwards.
> 
> Kill xfrm_dst->u.next and change the only user to use dst->next instead.
> 
> Signed-off-by: Patrick McHardy <kaber@trash.net>

Applied, thanks a lot Patrick.

I'll toss this to -stable too.