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
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 PRO
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,
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
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 ma
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, we went from "use old SA"
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 sp
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
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 kn
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
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
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
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 p
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
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 !
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 p
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 in
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 a/net/xfr
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
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 XFR
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 ev
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 use
On Thu, 2005-15-12 at 21:28 +0100, Krzysztof Oledzki wrote:
>
> On Thu, 15 Dec 2005, jamal wrote:
> > It will help 100% of the time _if you know_ you have CISCOs on the other
> > end and you configure racoon with that in mind. In other words it doesnt
> > matter who the initiator/responder is in
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
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
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
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
On Thu, 15 Dec 2005, 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 CISCO not sending IKE
delet
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.
>
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 i
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 the original
authors of racoon.
So lets take one more go a
Addedd CC: to the [EMAIL PROTECTED] mailing list.
On Wed, 14 Dec 2005, jamal wrote:
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
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-netdev&m=113070963711648&w=2
> We
Please have a look at:
http://bugzilla.kernel.org/show_bug.cgi?id=4952
It should look familiar.
We were discussing this in depth a few weeks ago, but the
discussion tailed off and I don't know how close we came
to a consensus or what that consensus might be :-)
The crux of the matter, t
34 matches
Mail list logo
