Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*IPsec\s+xfrm\s+resolution\s*$/: 32 ]

Total 32 documents matching your query.

1. x: get/set eeprom (score: 1)
Author: xx>
Date: Thu, 17 Mar 2005 20:32:31 -0800
This would seem to be the case, but keep in mind that if we're going through all this trouble to improve this quality of implementation issue, we should really get this right. On a more practical sid
/archives/netdev/2005-03/msg01043.html (9,110 bytes)

2. ] TCP congestion schedulers (score: 1)
Author: williams - CONTRACTOR" <chas@xxxxxxxxxxxxxxxx>
Date: Fri, 18 Mar 2005 17:24:01 +1100
Don't worry, further down in that thread we agreed that optional SAs will simply not be added so the MTU estimate will be correct unless it's changed by PMTU later on. Not yet. However, once the MTU
/archives/netdev/2005-03/msg01044.html (9,650 bytes)

3. e: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS (score: 1)
Author: xxxxxx>
Date: Sun, 20 Mar 2005 16:51:23 +0100
David S. Miller wrote: Anyways, in truth I'm being very picky :-) Is there any prototype or beginnings of these ideas anywhere? Not yet, I've put it on hold after clashing with Herbert's MTU work. I'
/archives/netdev/2005-03/msg01126.html (8,930 bytes)

4. ce simple actions (score: 1)
Author: omas Graf <tgraf@xxxxxxx>
Date: Mon, 21 Mar 2005 07:38:41 +1100
I've completed the first stage of the MTU work so please feel free to send patches through. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxx
/archives/netdev/2005-03/msg01155.html (9,101 bytes)

5. e simple actions (score: 1)
Author: Patrick McHardy <kaber@xxxxxxxxx>
Date: Wed, 23 Mar 2005 03:28:57 +0100
Herbert Xu wrote: On Sun, Mar 20, 2005 at 04:51:23PM +0100, Patrick McHardy wrote: Not yet, I've put it on hold after clashing with Herbert's MTU work. I'll have a few free days this week where I wil
/archives/netdev/2005-03/msg01275.html (9,304 bytes)

6. Re: IPsec xfrm resolution (score: 1)
Author: h" <dale@xxxxxxxxxxxxxx>
Date: Fri, 18 Feb 2005 00:26:57 +0100
Herbert Xu wrote: On Thu, Feb 17, 2005 at 08:48:15AM +0100, Patrick McHardy wrote: sorry for the delay, I haven't made much progress yet. The old patch was crap, I started over again. So far I've bee
/archives/netdev/2005-02/msg00627.html (13,890 bytes)

7. Re: IPsec xfrm resolution (score: 1)
Author: ll <mpm@xxxxxxxxxxx>
Date: Fri, 18 Feb 2005 21:08:54 +1100
Agreed. This doesn't stop us from creating the bundle object of course. I don't get it. Can't you just add it into the bundle but ignore it for dst->output and other calculations until it's either re
/archives/netdev/2005-02/msg00641.html (11,014 bytes)

8. Re: IPsec xfrm resolution (score: 1)
Author: xxxxxx>
Date: Sat, 19 Feb 2005 07:03:32 +0100
Herbert Xu wrote: On Fri, Feb 18, 2005 at 12:26:57AM +0100, Patrick McHardy wrote: I'm not sure yet how to deal with optional SAs. We shouldn't add incomplete optional tunnel mode SAs to the bundle b
/archives/netdev/2005-02/msg00660.html (11,181 bytes)

9. Re: IPsec xfrm resolution (score: 1)
Author: ik <jgarzik@xxxxxxxxx>
Date: Sat, 19 Feb 2005 20:23:14 +1100
This is OK for two reasons: 1) The application must be able to react to MTU changes anyway. 2) The most common use for optional SAs is IPCOMP which has zero overhead. Actually, 2) gives us the real r
/archives/netdev/2005-02/msg00664.html (10,597 bytes)

10. Re: IPsec xfrm resolution (score: 1)
Author: arzik <jgarzik@xxxxxxxxx>
Date: Sat, 19 Feb 2005 13:29:25 +0100
Herbert Xu wrote: On Sat, Feb 19, 2005 at 07:03:32AM +0100, Patrick McHardy wrote: - netfilter LOCAL_OUT hook sees incorrect output device - strict source routing check done with incorrect rt_gateway
/archives/netdev/2005-02/msg00667.html (9,991 bytes)

11. Re: IPsec xfrm resolution (score: 1)
Author: SHIFUJI Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Sun, 20 Feb 2005 05:32:02 +1100
That's a bug. How can you forward packets properly if the tunnel mode SA is missing? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> H
/archives/netdev/2005-02/msg00670.html (9,827 bytes)

12. Re: IPsec xfrm resolution (score: 1)
Author: xxxxxxx>
Date: Sat, 19 Feb 2005 19:47:11 +0100
Herbert Xu wrote: On Sat, Feb 19, 2005 at 01:29:25PM +0100, Patrick McHardy wrote: This is not what happens currently. If an optional IPCOMP SA is missing it is skipped entirely. It is also legal to
/archives/netdev/2005-02/msg00672.html (10,119 bytes)

13. Re: IPsec xfrm resolution (score: 1)
Author: xxxxxxxx>
Date: Sun, 20 Feb 2005 06:03:33 +1100
In that case you can't mark IPCOMP SAs as optional in this scenario which is the most common application of optional: IPCOMP(tunnel) -- ESP(transport) -- Visit Openswan at http://www.openswan.org/ Em
/archives/netdev/2005-02/msg00674.html (10,010 bytes)

14. Re: IPsec xfrm resolution (score: 1)
Author: xxxxxxxxx>
Date: Sat, 19 Feb 2005 20:53:33 +0100
Herbert Xu wrote: On Sat, Feb 19, 2005 at 07:47:11PM +0100, Patrick McHardy wrote: That's a bug. How can you forward packets properly if the tunnel mode SA is missing? Using normal routing. What mean
/archives/netdev/2005-02/msg00676.html (11,047 bytes)

15. Re: IPsec xfrm resolution (score: 1)
Author: xxxxxxxxx>
Date: Sat, 19 Feb 2005 21:26:02 +0100
Patrick McHardy wrote: I've checked KAME, it also skips IPSEC_LEVEL_USE SAs if they aren't present. IPCOMP in tunnel mode is a special case. It wants to express more than just "optional". It means to
/archives/netdev/2005-02/msg00677.html (10,832 bytes)

16. Re: IPsec xfrm resolution (score: 1)
Author: Buytenhek <buytenh@xxxxxxxxxxxxxx>
Date: Sun, 20 Feb 2005 17:57:20 +1100
Actually, I've been convinced by your earlier argument :) I now think that IPCOMP users like racoon/openswan should simply not set the optional flag on the sending policy. It only needs to be set on
/archives/netdev/2005-02/msg00684.html (10,006 bytes)

17. Re: IPsec xfrm resolution (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 17 Mar 2005 20:32:31 -0800
This would seem to be the case, but keep in mind that if we're going through all this trouble to improve this quality of implementation issue, we should really get this right. On a more practical sid
/archives/netdev/2005-03/msg02966.html (9,661 bytes)

18. Re: IPsec xfrm resolution (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Mar 2005 17:24:01 +1100
Don't worry, further down in that thread we agreed that optional SAs will simply not be added so the MTU estimate will be correct unless it's changed by PMTU later on. Not yet. However, once the MTU
/archives/netdev/2005-03/msg02967.html (10,263 bytes)

19. Re: IPsec xfrm resolution (score: 1)
Author: Patrick McHardy <kaber@xxxxxxxxx>
Date: Sun, 20 Mar 2005 16:51:23 +0100
Anyways, in truth I'm being very picky :-) Is there any prototype or beginnings of these ideas anywhere? Not yet, I've put it on hold after clashing with Herbert's MTU work. I'll have a few free day
/archives/netdev/2005-03/msg03049.html (9,453 bytes)

20. Re: IPsec xfrm resolution (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 21 Mar 2005 07:38:41 +1100
I've completed the first stage of the MTU work so please feel free to send patches through. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxx
/archives/netdev/2005-03/msg03078.html (9,668 bytes)


This search system is powered by Namazu