[PATCH] TCP window tracking patch backported from the 2.6 tree

[Daniel Hartmeier]

On Thu, Jun 30, 2005 at 09:48:19AM +0200, Jozsef Kadlecsik wrote:

> > advantages this has? We see no problems with SACK-enabled connections in
> > pf, and simply ignore selective ACK options.
> 
> I suspect you haven't received reports on such problems because pf does
> not log when it drops out of window segments. TCP is a robust protocol and
> sometimes, by resending packets, it can overcome the situation and the
> connection does not hang forever. However the window tracking patch for
> netfilter lived very long time in patch-o-matic as an experimental
> extension with logging out of window packets enabled. We received
> complains and sometimes the reporters could supply both the logs and full
> tcpdump recordings from the firewall which revealed the problem.

pf can log when it drops packets that mismatch the state entry's
sequence number windows ('BAD state' log entries, generated when pfctl
-xm, debug logging, is enabled, which is disabled by default).

I've analyzed a fair number of problem reports with both tcpdumps of
connections and such out-of-window logs, but I've never seen one where
SACK holes were part of the puzzle. In some cases, one peer would simply
violate the TCP RFC and send out-of-window segments. Maybe I just didn't
make the connection between seemingly invalid behaviour and SACK holes,
but out of at least two dozen analyzed incidents, none remained
unexplained so far.

I'd be interested in an example dump and log of a connection that
demonstrates this issue, especially if it shows that the hosts
didn't violate the RFCs. Comparing, in that example, the use of a
right-most SACK hole as edge vs. a (later) plain ACK could help
understand the implications.

I'm not saying netfilter's use of the SACK holes is potentially
incorrect, but it looks somewhat suspicious to me, and that's what I'd
look at more closely. If you still have one of those examples around,
I'd love to see it :)

Daniel