On Thu, 10 Jul 2008, Robert L Mathews wrote: > Jozsef Kadlecsik wrote: > > > Client sends RST, which is out of (before) the window (left edge is at > > 2354211889), thus ignored by the server. > > That makes sense, but it seems like conntrack processes the RST and marks the > original connection as closed, then treats the server resends as new outgoing > connections, which doesn't seem right. > > In other words, if the server's TCP stack is ignoring the RST, shouldn't > conntrack ignore it, too? In theory, yes. But conntrack does not have got the same info as the end nodes, e.g. packets which were seen and taken into account by conntrack may get lost in transit. The window sizes in netfilter can easily be slightly wider than the real window sizes at the sender and the receiver. This is the reason why conntrack may think the RST segment is valid and therefore destroys the conntrack entry. > Whatever it is, it's unfortunately quite common -- as I said, any of our > reasonably-busy Web servers show thousands of such phantom connections from > hundreds of unique IP addresses. Still, it's quite strange. Why such RST packets are generated at all? "Late" packets (i.e. packets which are received after a connection is destroyed in conntrack) creates "phantom" connections if nf_conntrack_tcp_be_liberal is enabled (which is the default). We have to balance on a two-edge sword: if we keep the connection in memory too long after we have seen a complete termination (FIN-FIN-ACK or RST), then we waste memory and conntrack is susceptible to DoS attacks; if we destroy the connections too fast, the late packets create phantom connections or false alarms. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
