Le 16/04/2015 09:02, James Morris a écrit :
On Thu, 16 Apr 2015, Herbert Xu wrote:
[snip]
PS I used the wrong email for James the first time around. So
let me repeat the question here. Should secmark be preserved
or cleared across tunnels within the same name space? In fact,
do our security
Le 16/04/2015 15:17, weiyj...@163.com a écrit :
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Remove duplicated include.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Nicolas Dichtel nicolas.dich...@6wind.com
--
To unsubscribe from this list: send the line unsubscribe
during listing on rth).
Example:
$ ip netns list-id
nsid 0 (iproute2 netns name: foo)
$ ip monitor nsid
Deleted nsid 0 (iproute2 netns name: foo)
nsid 16 (iproute2 netns name: bar)
Signed-off-by: Nicolas Dichtel nicolas.dich...@6wind.com
---
v2: rebase on master after the 4.0 release
include
'.
Reported-by: Gregory Hoggarth gregory.hogga...@alliedtelesis.co.nz
Signed-off-by: Nicolas Dichtel nicolas.dich...@6wind.com
---
ip/xfrm_policy.c | 24 ++--
ip/xfrm_state.c | 12 +++-
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/ip/xfrm_policy.c b/ip
Le 15/04/2015 15:57, Herbert Xu a écrit :
On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
[snip]
Subject: skbuff: Do not scrub skb mark within the same name space
The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 (tunnels:
Maybe add a Fixes tag?
Fixes: ea23192e8e57 (tunnels:
Le 15/04/2015 12:22, Herbert Xu a écrit :
On Wed, Apr 15, 2015 at 12:20:42PM +0200, Nicolas Dichtel wrote:
Le 15/04/2015 12:01, Herbert Xu a écrit :
The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 (tunnels:
harmonize cleanup done on skb on rx path) broke anyone trying to
use netfilter
Le 15/04/2015 12:01, Herbert Xu a écrit :
The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 (tunnels:
harmonize cleanup done on skb on rx path) broke anyone trying to
use netfilter marking across IPv4 tunnels. As the commit message
did not give any justification for this (in fact it shouldn't
updated,
and so will expire, whereas the host will keep the corresponding address.
Maybe, when strict is set to 1 in rt6_lookup(), kernel must not return
an anycast route.
What about this patch ?
Regards,
Nicolas
[IPv6] Don't return anycast route when strict is enable
Signed-off-by: Nicolas
Le 02.11.2006 18:02, Vlad Yasevich a écrit :
Nicolas DICHTEL wrote:
Hello,
Suppose that a host has autoconfiguration enabled. It will take RA to
autoconfigure an IPv6 address. For example,
2001:0db8:3008:c1ca:2d0:b7ff:febb:4aee/64.
This host will create a route entry for this onlink prefix
devices.
Signed-off-by: Nicolas Dichtel [EMAIL PROTECTED]
--- a/drivers/net/ifb.c 2006-07-20 15:16:31.923529050 +0200
+++ b/drivers/net/ifb.c 2006-07-20 15:17:36.370188249 +0200
@@ -271,6 +271,7 @@
for (i = 0; i numifbs !err; i++)
err = ifb_init_one(i);
if (err) {
+ i--;
while (--i
jamal a écrit :
BTW, in the name of the LinuxWay(tm) - can you also submit a similar
patch for dummy? It suffers from the same bug.
No problem, patch is enclosed.
Cheers,
Nicolas
[DUMMY] Avoid an oops when dummy_init_one() failed
Signed-off-by: Nicolas Dichtel [EMAIL PROTECTED
Sorry, I forgot the patch ;-)
Nicolas
Nicolas DICHTEL a écrit :
jamal a écrit :
BTW, in the name of the LinuxWay(tm) - can you also submit a similar
patch for dummy? It suffers from the same bug.
No problem, patch is enclosed.
Cheers,
Nicolas
[DUMMY] Avoid an oops when dummy_init_one
Same problem and same fix that for IFB.
Regards,
Nicolas
[NET][DUMMY] Avoid an oops when dummy_init_one() failed
Signed-off-by: Nicolas Dichtel [EMAIL PROTECTED]
--- a/drivers/net/dummy.c 2006-07-20 16:19:09.395351558 +0200
+++ b/drivers/net/dummy.c 2006-07-20 16:19:58.802327279 +0200
Thomas Graf a écrit :
* Nicolas Dichtel [EMAIL PROTECTED] 2006-06-30 15:16
That creates a nice loop on ingress. Upon reentering the
stack with skb-dev set to eth0 again we'll go through the
same ingress filters as the first time and we'll hit ifb0
again over and over. Are you suggesting
Herbert Xu a écrit :
David S. Miller [EMAIL PROTECTED] wrote:
From: Nicolas DICHTEL [EMAIL PROTECTED]
Date: Mon, 06 Feb 2006 12:00:30 +0100
in the same way of this patch, why dst_entry are stored for
RAW socket ? In case of specific IPSec rules for ICMPv6,
xfrm state can be different
Hi all,
in the same way of this patch, why dst_entry are stored for
RAW socket ? In case of specific IPSec rules for ICMPv6,
xfrm state can be different for the same destination.
Attached, a proposed patch.
Regards,
Nicolas
[IPV6] Don't store dst_entry for RAW socket
Signed-off-by: Nicolas
501 - 516 of 516 matches
Mail list logo
