From: Patrick McHardy <kaber@xxxxxxxxx> Date: Sat, 7 Jul 2007 17:34:49 +0200 (CEST) > > My idea is following. > > > > - This TCP reset is not initial packet of TCP connection. If it is initial packet, > > no address in ICMP packet should be mangled. Jordan, if you see > > /proc/net/netfilter/nf_conntrack, you will find the entry matched the TCP packet. > > > > - TCP packet was marked as error packet. Because '--state ESTABLISHED' > > didn't match the packet. No conntrack entry wasn't assigned to the > > packet. Usually, error log by nf_conntrack_tcp should be generated in > > such case, but no message is generated in some cases. I don't know why > > this TCP reset was handled as error. > > > > - Then ICMP error generated at this router was not assigned to any conntrack entry. > > > > - nf_conntarck_icmp.c assigns the ICMP error to the conntrack which matches > > the TCP reset. But IP_CT_IS_REPLY didn't set to *ctinfo. This is bug. > > > > h = nf_conntrack_find_get(&innertuple, NULL); > > if (!h) { > > /* Locally generated ICMPs will match inverted if they > > haven't been SNAT'ed yet */ > > /* FIXME: NAT code has to handle half-done double NAT --RR */ > > if (hooknum == NF_IP_LOCAL_OUT) > > h = nf_conntrack_find_get(&origtuple, NULL); > > > The local ICMP tracking is basically useless nowadays since we always > manually attach the conntrack reference from the original packet > (exactly because of the half-done double NAT FIXME quoted above). > But this is an interesting case, the connection tracking code itself > thought the RST was invalid, but ICMP tracking will still associate > the ICMP containing the RST with the original connection. I'm wondering > whether it should really do that. In case it shouldn't, just removing > all locally generated ICMP special-casing should also fix the bug, > right? At first I thought so. But I didn't come up with any bad situation caused by returning ICMP error to such invalid packets. -- Yasuyuki Kozakai