Re: bad interaction between TCP delayed ack and RSTs

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> - The client sends some data.
> - Delayed ack causes NetBSD to send no ack for this packet.
> - The client exits (or closes the socket).
> - Windows sends an RST/ACK to close the TCP connection (it does this
>   a lot, if not most of the time -- I do not know when it uses a
>   FIN).

Problem one; I agree with Ignatios in that respect.  However, while
this is liable to lose unacked-and-unread data, that's the only effect
it should have.

> - When the RST message arrives, NetBSD responds to the RST with an
>   ACK and then drops the RST.
> - The intention must be that the peer will respond to the ACK with
>   another RST, [...]

If the first RST was real, yes.

> - The *reality* is that the Windows firewall drops the post-RST ack.

It is broken, at least for TCP's use.  The RST in response to packets
to nonexistent connections is there for a reason; failing to generate
it breaks TCP, leading to problems such as the one you're seeing.
Either you will need to configure the firewall so endpoints behind it
behave, as seen by the network, the way TCP expects them to behave or
you will have to live with the brokenness that results.  Even if NetBSD
didn't have the third-party-RST defense, the same behaviour would
result if the Windows-sent RST got dropped in the network.

> This seems to be the code that is giving me trouble: [...]

I would say, rather, that it is the code that's showing up the
bustification in the firewall.

> I just don't think it's right for a connection to not close down
> solely due to the fact that it's in the middle of doing a delayed
> ack.

It's not.  It's due to that _plus_ the presence of a misconfigured
(and/or misimplemented) firewall breaking the assumptions TCP is built
upon.

While it's not really my call to make, I think it's a bad idea to
contrive NetBSD in an attempt to compensate for someone else's breaking
the underlying protocol.  That's a very slippery slope with lots of
catastrophes waiting to happen.  If you really really need to
interoperate with the behaviour exhibited by your
Windows-plus-firewall, you will, first, need to know exactly what
behaviour it exhibits - this is unlikely to be the only respect in
which it breaks TCP - and redesign TCP in light of that, then implement
the resulting not-quite-TCP.  Just don't mistake it for TCP.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B