Re: [PATCH]: Re: SA switchover

2005-12-20 Thread jamal
On Tue, 2005-20-12 at 06:04 +0100, Krzysztof Oledzki wrote: On Mon, 19 Dec 2005, jamal wrote: On Mon, 2005-19-12 at 13:57 -0800, David S. Miller wrote: From: jamal [EMAIL PROTECTED] Date: Mon, 19 Dec 2005 08:17:19 -0500 Just an addendum: If this works it should be sysctl controlled

Re: [Ipsec-tools-devel] Re: [PATCH]: Re: SA switchover

2005-12-19 Thread Krzysztof Oledzki
On Sun, 18 Dec 2005, David S. Miller wrote: From: David S. Miller [EMAIL PROTECTED] Date: Sun, 18 Dec 2005 13:20:19 -0800 (PST) From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Sun, 18 Dec 2005 17:49:50 +0100 (CET) At 17:31:26 kernel executed the one from xfrm_state_add() (Ole #2) but it

Re: [PATCH]: Re: SA switchover

2005-12-19 Thread jamal
On Sat, 2005-17-12 at 15:03 -0800, David S. Miller wrote: From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Fri, 16 Dec 2005 13:15:58 +0100 (CET) Thank you! Will test ASAP. Need day or two, I need to reassemble my IPSec netlab. ;) Please let me know if it works as soon as you know. I

Re: [Ipsec-tools-devel] Re: [PATCH]: Re: SA switchover

2005-12-19 Thread David S. Miller
From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Mon, 19 Dec 2005 10:37:14 +0100 (CET) OK. With this patch kernel switches to new SA immediately, but only for ping. TCP (ssh) session between Cisco and Linux is still protected by the old SA. Ok, we're making progress :-) When the bundles get

Re: [PATCH]: Re: SA switchover

2005-12-19 Thread David S. Miller
From: jamal [EMAIL PROTECTED] Date: Mon, 19 Dec 2005 08:17:19 -0500 Just an addendum: If this works it should be sysctl controlled i hope. There is absolutely no reason for that, so no :) A second approach inspired from your current patch: Just delete the route cache entry for the one

Re: [PATCH]: Re: SA switchover

2005-12-19 Thread David S. Miller
From: jamal [EMAIL PROTECTED] Date: Mon, 19 Dec 2005 19:18:55 -0500 BTW, what kernels are these patches against? 2.6.15-GIT, and it would likely apply to 2.6.14 as well :) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More

Re: [PATCH]: Re: SA switchover

2005-12-19 Thread Krzysztof Oledzki
On Mon, 19 Dec 2005, jamal wrote: On Mon, 2005-19-12 at 13:57 -0800, David S. Miller wrote: From: jamal [EMAIL PROTECTED] Date: Mon, 19 Dec 2005 08:17:19 -0500 Just an addendum: If this works it should be sysctl controlled i hope. There is absolutely no reason for that, so no :) Well,

Re: [Ipsec-tools-devel] Re: [PATCH]: Re: SA switchover

2005-12-19 Thread Krzysztof Oledzki
On Mon, 19 Dec 2005, David S. Miller wrote: From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Mon, 19 Dec 2005 10:37:14 +0100 (CET) OK. With this patch kernel switches to new SA immediately, but only for ping. TCP (ssh) session between Cisco and Linux is still protected by the old SA. Ok,

Re: [Ipsec-tools-devel] Re: [PATCH]: Re: SA switchover

2005-12-19 Thread David S. Miller
From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Tue, 20 Dec 2005 06:25:12 +0100 (CET) Yes, it works now perfectly: Wonderful, it's in Linus's 2.6.15 tree and submitted for 2.6.14-stable. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL

Re: [Ipsec-tools-devel] Re: [PATCH]: Re: SA switchover

2005-12-18 Thread Krzysztof Oledzki
On Thu, 15 Dec 2005, David S. Miller wrote: From: David S. Miller [EMAIL PROTECTED] Date: Thu, 15 Dec 2005 17:52:54 -0800 (PST) diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c index 7cf48aa..25dd8f4 100644 --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c Sorry, that

Re: [Ipsec-tools-devel] Re: [PATCH]: Re: SA switchover

2005-12-18 Thread David S. Miller
From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Sun, 18 Dec 2005 17:49:50 +0100 (CET) At 17:31:26 kernel executed the one from xfrm_state_add() (Ole #2) but it didn't help. :( Thanks for testing, I'll try to figure out what might be going on. - To unsubscribe from this list: send the line

Re: [Ipsec-tools-devel] Re: [PATCH]: Re: SA switchover

2005-12-18 Thread David S. Miller
From: David S. Miller [EMAIL PROTECTED] Date: Sun, 18 Dec 2005 13:20:19 -0800 (PST) From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Sun, 18 Dec 2005 17:49:50 +0100 (CET) At 17:31:26 kernel executed the one from xfrm_state_add() (Ole #2) but it didn't help. :( Thanks for testing, I'll

Re: [PATCH]: Re: SA switchover

2005-12-17 Thread David S. Miller
From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Fri, 16 Dec 2005 13:15:58 +0100 (CET) Thank you! Will test ASAP. Need day or two, I need to reassemble my IPSec netlab. ;) Please let me know if it works as soon as you know. I think for now it's more important to have things working than to

Re: [PATCH]: Re: SA switchover

2005-12-16 Thread Krzysztof Oledzki
On Thu, 15 Dec 2005, David S. Miller wrote: From: David S. Miller [EMAIL PROTECTED] Date: Thu, 15 Dec 2005 17:52:54 -0800 (PST) diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c index 7cf48aa..25dd8f4 100644 --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c Sorry, that

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-16 Thread VANHULLEBUS Yvan
On Thu, Dec 15, 2005 at 02:55:13PM -0800, David S. Miller wrote: [] I think the kernel is definitely within it's rights to interpret section 4.3 of RFC2408 the way that it does. We can say that, but then, we have to accept that this interpretation can lead to interoperability problems !

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread VANHULLEBUS Yvan
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote: On Thu, 2005-15-12 at 05:57 +0100, Krzysztof Oledzki wrote: Addedd CC: to the [EMAIL PROTECTED] mailing list. And I added Shoichi Sakane to the CC. He is responsible for bringing use new SA feature to BSD to begin with and is one of

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread jamal
On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote: On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote: What is not true?;- CISCO doesnt hardcode 30 secs as the time between soft and hard expiry? Or what is said with CISCO not sending IKE delete? AFAIK, both are true.

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread VANHULLEBUS Yvan
On Thu, Dec 15, 2005 at 10:27:02AM -0500, jamal wrote: On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote: On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote: What is not true?;- CISCO doesnt hardcode 30 secs as the time between soft and hard expiry? Or what is said with

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread jamal
On Thu, 2005-15-12 at 17:11 +0100, Krzysztof Oledzki wrote: On Thu, 15 Dec 2005, jamal wrote: [..] Thats one interpretation. The other is in the same section and says: Deletion of the old SA is dependent on local security policy. Please notice - there are two SA: incomming and outgoing.

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread jamal
On Thu, 2005-15-12 at 17:23 +0100, VANHULLEBUS Yvan wrote: On Thu, Dec 15, 2005 at 10:27:02AM -0500, jamal wrote: On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote: On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote: What is not true?;- CISCO doesnt hardcode 30 secs as the

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread Krzysztof Oledzki
On Thu, 15 Dec 2005, jamal wrote: Agree. It is a _workaround_;- A good one in my opinion. Given that it works for CISCOs, a very large piece of the problem is resolved, no? No, again, it does not help. I explained it in my previous mail. It will help 100% of the time _if you know_ you have

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread David S. Miller
From: jamal [EMAIL PROTECTED] Date: Thu, 15 Dec 2005 15:56:52 -0500 Refer to Herberts solution and see if that solves the problem. I think the kernel is definitely within it's rights to interpret section 4.3 of RFC2408 the way that it does. And I bet that whoever wrote those paragraphs used

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread Krzysztof Oledzki
On Thu, 15 Dec 2005, David S. Miller wrote: 1) I don't understand how a routing cache flush fixes the problem. The routing cache flush only marks non-IPSEC cached routes as invalid, not IPSEC ones. New IPsec SA is used for communication between new src/dst (previously unseend) pair

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread David S. Miller
From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Fri, 16 Dec 2005 01:04:47 +0100 (CET) It looks like XFRM caches that information, so kernel does need to search whole SADB for each packet and this is the reason why usage of old SA is observed. This is my theory only, someone who wrote XFRM

Re: [Ipsec-tools-devel] Re: SA switchover

2005-12-15 Thread David S. Miller
From: David S. Miller [EMAIL PROTECTED] Date: Thu, 15 Dec 2005 17:04:56 -0800 (PST) I'm trying to see if there is a clever way to make existing SA entries get invalidated upon insertion of a new SA which shadows them. To illustrate why this is a hard problem, I've drawn an extensive diagram

[PATCH]: Re: SA switchover

2005-12-15 Thread David S. Miller
The following is an extremely inefficient way to make new SAs visible immediately. It is just for example purposes. We just flush out all the cached bundles any time we insert a new SA state. Krzysztof, can you at least verify that this makes your problem go away? Thanks. diff --git

Re: [PATCH]: Re: SA switchover

2005-12-15 Thread David S. Miller
From: David S. Miller [EMAIL PROTECTED] Date: Thu, 15 Dec 2005 17:52:54 -0800 (PST) diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c index 7cf48aa..25dd8f4 100644 --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c Sorry, that patch was incomplete, please try this one instead:

Re: SA switchover

2005-12-14 Thread jamal
On Wed, 2005-14-12 at 16:48 -0800, David S. Miller wrote: Please have a look at: http://bugzilla.kernel.org/show_bug.cgi?id=4952 It should look familiar. It is - the soup nazi got involved on that bug ;- http://marc.theaimsgroup.com/?l=linux-netdevm=113070963711648w=2 We were