Re: bad interaction between TCP delayed ack and RSTs

[jmmikkel%MIT.EDU@localhost (Joanne M Mikkelson)]

> Ahem. IMHO, the problem isn't that a RST is lost. It is that it is
> sent at all!

No RSTs were lost in the creation of my problem. :-)

I will not argue with the assertion that the connection *should* be
shut down with a FIN. However, I am reporting what is *actually*
happening.

> I believe the RST checking foo in our code is for a partial defense
> against 3rd-party rogue RSTs. It's not meant, and can't be, to ACK
> data-on-the-fly when a RST is receive- because by definition, when 

I have several packet traces showing NetBSD sending an ACK after the
RST. And I can generate more at will. If it's a third party (attack)
RST the ACK is harmless. If it's not a third party RST the ACK will
generate another RST, unless there's a firewall dropping the ACK.

> So either the application programmers have forgotten to do some
> proper TCP flushing/closing call (I don't know the Windows API),

My test program calls close() on the socket. It demonstrates the
problem with 100% reliability. I believe that if it were written with
the Windows API instead of using POSIX compatibility it would do the
same. If it becomes necessary I will rewrite the test program
tomorrow night to do so.

> or Windows does a local optimization at the expense of reliability,
> or some "firewall" in between does something very fishy.

By the way, Windows is not the only OS which will send RST to close a
connection. For example, I wrote this a couple years ago while
working with an unrelated problem:

   I tested a bit with the FINs and RSTs and apparently on Linux
   (2.4.something), the TCP connection is closed with a RST whenever
   the user-space process has *not* read all the data on the socket
   before the socket is closed. The only way I could get Linux to
   send a FIN was to read all the data before closing.

(I went on to say I could not get NetBSD to send an RST due to an
action by an application.) At least in this case the application
could be changed, presumably, to "fix" the RST problem, but the point
is, here is an example of something other than Windows sending
RSTs.

I thought NetBSD does want to work as well as possible with other TCP
implementations.

Given the reality of an application doing the perfectly reasonable
thing of calling close() on an extremely common OS using a firewall
with rather common behavior (dropping packets on closed connections),
I still find it strange that a delayed ack causes my server to behave
poorly when, given the same RST and firewall behavior, it works
correctly when there isn't a delayed ack.

Joanne