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?
It apparently doesn't -- I used the "conntrack -E" tool to show a log of
these connections, and it definitely shows it handling the RST, then
detecting a new connection in the other direction from the retried
outgoing packets.
Here's an example of one:
http://www.tigertech.net/20080710.txt
This includes the tcpdump, plus (at the end) the output of the
"conntrack" tool used in both directions, showing how it incorrectly
detected a new connection in the outbound direction. Unfortunately the
conntrack output doesn't show timestamps, but I was watching it, and the
spurious outbound "connection" was detected during the retries, within
maybe 30 seconds after the incoming connection was DESTROYed.
You wrote the client runs Mac OS X 10.4.11. I don't really know what's
wrong with it but it seems as a client related issue - or an ISP between
the client and server which tries to generate fake RST packets to tear
down connections.
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.
--
Robert L Mathews, Tiger Technologies
--
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
