In article [EMAIL PROTECTED] (at Sun, 18 Dec 2005 15:27:01 +0100), Patrick
McHardy [EMAIL PROTECTED] says:
YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Tue, 22 Nov 2005 02:14:26 +0100),
Patrick McHardy [EMAIL PROTECTED] says:
The easiest way would be to store nhoff
In article [EMAIL PROTECTED] (at Sun, 18 Dec 2005 23:59:35 +0100), Patrick
McHardy [EMAIL PROTECTED] says:
YOSHIFUJI Hideaki wrote:
:
BTW, we're now using full of skb-cb
(and we are even exceeding it w/ mobile-ipv6 extensions)...
Not in mainline so far, so maybe we can fit your
On Sun, Dec 04, 2005 at 11:06:02PM +0100, Patrick McHardy wrote:
I'm worried about this bit. This looks like it'll go back to the top
of the IP stack with the existing call chain. So could grow as the
number of transforms increase.
Its not so bad. It adds ip_xfrm_transport_hook and
Herbert Xu wrote:
On Sun, Dec 04, 2005 at 11:06:02PM +0100, Patrick McHardy wrote:
If there is a DNAT in the way, this will jump to the very start of
the stack. So if we have a hostile IPsec peer, and the DNAT rules
are such that this can occur, then we could be in trouble (especially
because
On Sun, Nov 20, 2005 at 04:31:36PM +, Patrick McHardy wrote:
@@ -145,7 +149,17 @@ int xfrm4_rcv_encap(struct sk_buff *skb,
netif_rx(skb);
return 0;
} else {
+#ifdef CONFIG_NETFILTER
+ __skb_push(skb, skb-data - skb-nh.raw);
+
Hello.
In article [EMAIL PROTECTED] (at Tue, 22 Nov 2005 02:14:26 +0100), Patrick
McHardy [EMAIL PROTECTED] says:
The easiest way would be to store nhoff somewhere in the skb and
use it to continue at the next header. But I still hope there is
a way without keeping data in the skb.
We've
Hello Patrick,
I have a comment about the patch on the IPv6 input process.
The kernel applied your patch will always call ip6_rcv_finish
when enabling netfilter and receiving a esp packet so that
it will always look up the routing table and parse
extention headers twice a packet.
It will probably
Hello.
In article [EMAIL PROTECTED] (at Mon, 21 Nov 2005 17:31:41 +0900), Kazunori
Miyazawa [EMAIL PROTECTED] says:
Your ip_xfrm_transport_hook is a good idea, I think.
We could call ip6_rcv_finish if the netfilter changed the addresses
or otherwise we can continue the loop to avoid the
Hi,
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 21 Nov 2005 07:52:36 +0100
I don't see why it is confusing. Plain text packets are visible before
encapsulation (and they have to be because we don't necessarily know
if packets will be encapsulated at the time the hooks are called in
Kazunori Miyazawa wrote:
Hello Patrick,
I have a comment about the patch on the IPv6 input process.
The kernel applied your patch will always call ip6_rcv_finish
when enabling netfilter and receiving a esp packet so that
it will always look up the routing table and parse
extention headers
Yasuyuki KOZAKAI wrote:
I don't see why it is confusing. Plain text packets are visible before
encapsulation (and they have to be because we don't necessarily know
if packets will be encapsulated at the time the hooks are called in
case the policy lookup after NAT returns a policy), plain text
David S. Miller wrote:
I've read over Patrick's two most recent postings of these patches
and I think they are generally sane and I cannot find any holes in
them. Herbert brought up the legitimate concern about defragmentation,
but I think that's a detail and does not take away from the
Patrick McHardy wrote:
Kazunori Miyazawa wrote:
Hello Patrick,
I have a comment about the patch on the IPv6 input process.
The kernel applied your patch will always call ip6_rcv_finish
when enabling netfilter and receiving a esp packet so that
it will always look up the routing table and parse
Kazunori Miyazawa wrote:
Patrick McHardy wrote:
The problem is that netfilter hooks take ownership of the skb, so the
caller can't touch it afterwards. It would be possible, but it would
become very ugly. Can I assume that you would also be satisfied if
the double-parsing of extension headers
Hi, Patrick,
From: Patrick McHardy [EMAIL PROTECTED]
Date: Sun, 20 Nov 2005 17:31:36 +0100
[IPV4/6]: Netfilter IPsec input hooks
When the innermost transform uses transport mode the decapsulated packet
is not visible to netfilter. Pass the packet through the PRE_ROUTING and
LOCAL_IN hooks
Yasuyuki KOZAKAI wrote:
At first, now I could agree to use same name for hooks before/after xfrm
processing, if it's important to keep compatibility than to avoid difficulty
to use. Even now I think it's confusing to pass packets before/after xfrm to
same hook, and believe it's ideal to use
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 21 Nov 2005 07:52:36 +0100
I don't see why it is confusing. Plain text packets are visible before
encapsulation (and they have to be because we don't necessarily know
if packets will be encapsulated at the time the hooks are called in
case
David S. Miller [EMAIL PROTECTED] wrote:
I've read over Patrick's two most recent postings of these patches
and I think they are generally sane and I cannot find any holes in
them. Herbert brought up the legitimate concern about defragmentation,
but I think that's a detail and does not take
18 matches
Mail list logo
