From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 2.6 0/12]: netfilter update Date: Mon, 27 Sep 2004 01:19:13 +0200 Sender: netfilter-devel-bounces@lists.netfilter.org Message-ID: <41574E71.4060601@trash.net> References: <414F9DFC.701@trash.net> <20040921143611.6a6e2f60.davem@redhat.com> <4150BB62.2060904@trash.net> <20040921171857.2c720c8e.davem@redhat.com> <4150D880.70108@trash.net> <20040924154032.5a0c32e1.davem@redhat.com> <41571BCC.2050909@trash.net> <41573B05.1000308@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org Return-path: To: Henrik Nordstrom In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Henrik Nordstrom wrote: > On Sun, 26 Sep 2004, Patrick McHardy wrote: > >> We confirm conntrack entries in LOCAL_IN after they passed all hooks, >> but this new set of hooks would be after LOCAL_IN, so conntrack entries >> should be confirmed there. > > > Right. THis would also ensure that connections not picked up by the > host does not get confirmed, but there is many complications if > attempting this path. > > - It must be fully assured no packets is silently accepted by the host > without entering this new hook. ipip and gre don't have sockets, they could call the hook with sk = NULL. Some icmp types are processed without a socket, same here. Packets without a protocol or raw-socket for that protocol are dropped in ip_local_deliver_finish, another hook would be required there. With all this, the existing LOCAL_IN hook becomes pratically useless. So we could just extend the existing NF_HOOK macro by an "sk" argument. In LOCAL_OUT, it would be set to skb->sk and, for symetry, to NULL in POST_ROUTING. One big advantage of this is that it would allow filtering packets from a transport mode SA without reinjecting them into the stack. I think I have to try it to see how ugly it gets :) > > - Fragmented packets is again an issue. Fragmentation is not a problem, packets are already defragmented when received on a socket. >> I agree. But I wonder if its worth it just for having the owner match >> work in the input path, or if there are other uses for these hooks. > > > Not sure either. But then it is also the case I have never really been > sure about the current independent relation of conntrack and the local > host sockets.. The socket could cache the conntrack entry, but then you run into problems with icmp and tcp, who uses the same socket (per-CPU in case of icmp) for replies generated by the kernel (RST, icmp reply, ...). Other than that, I don't see any advantage, we would still need the socket independent code for forwarded packets. Regards Patrick