netdev
[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

Re: [RFC, PATCH 3/5]: netfilter+ipsec - input hooks

from [Patrick McHardy] [Permanent Link][Original]
To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: [RFC, PATCH 3/5]: netfilter+ipsec - input hooks
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Fri, 19 Mar 2004 17:17:30 +0100
Cc: herbert@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20040318221523.07298f03.davem@redhat.com>
References: <20040308110331.GA20719@gondor.apana.org.au> <404C874D.4000907@trash.net> <20040308115858.75cdddca.davem@redhat.com> <4059CF0E.3050708@trash.net> <20040318221523.07298f03.davem@redhat.com>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1
David S. Miller wrote: 

Be careful!  xfrm4_tunnel handles both uncompressed ipcomp packets
_and_ IPIP encapsulator device packets.  Yet you will intepret usage
of the ipprot as 'xfrm_prot==1' in all cases.

Yes this is ugly... if we added some kind of flag bit-mask to sk_buff,
would that allow an easier implementation?


I can't imagine how. Best would be to avoid the xfrm_prot flag
completely. Maybe we can add a flag to xfrm_state which indicates
that this is the last xfrm specified in the policy ?

[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [RFC, PATCH 4/5]: netfilter+ipsec - policy lookup, Patrick McHardy
Next by Date:  Re: [RFC, PATCH 5/5]: netfilter+ipsec - policy checks, Patrick McHardy
Previous by Thread:  Re: [RFC, PATCH 3/5]: netfilter+ipsec - input hooks, Herbert Xu
Next by Thread:  Re: [RFC, PATCH 3/5]: netfilter+ipsec - input hooks, Herbert Xu
Indexes:  [Date] [Thread] [Top] [All Lists]