From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack Date: Tue, 14 Feb 2006 17:26:32 +0100 Message-ID: <43F204B8.5060700@trash.net> References: <200602131628.k1DGSpc3019846@toshiba.co.jp> <43F0B76E.7050007@trash.net> <200602140348.k1E3msEc020481@toshiba.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org, usagi-core@linux-ipv6.org, laforge@gnumonks.org Return-path: To: Yasuyuki KOZAKAI In-Reply-To: <200602140348.k1E3msEc020481@toshiba.co.jp> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Yasuyuki KOZAKAI wrote: > From: Patrick McHardy > Date: Mon, 13 Feb 2006 17:44:30 +0100 > >> >>The reason why we manually attach these references (at least for ICMP) >>is because the packet might be in the middle of two NAT manips and >>unrecognizable for conntrack. For IPv6 this should be irrelevant. I'm >>not sure why it is done for TCP RSTs, they should always be properly >>tracked anyway. > > > It's common case for me that the conntrack of original TCP packet is > unconfirmed at processing in REJECT target. In this case, TCP RST > generated by REJECT causes to create new conntrack. I don't think > that is good behavior. That can be said about sending ICMPv6 error. Unless I'm missing something, that shouldn't happen. __{ip,nf}_conntrack_confirm check that the packet is in direction IP_CT_DIR_ORIGINAL before confirming the conntrack.