>> There is no reason why a TCP connection cannot be closed in one
>> direction and still keep streaming data in the other [...]
> I never explicitly tested ipf with half-closed connections, but I did
> observe lots of problems at closing time when both sides attempted to
> do a 3-way close (fin / fin-ack / ack).

Sure sounds like it.

> I'd often see extra acks or tcp-rst's hitting the firewall instead of
> making it to the TCP stack machinery.

This reminds me of a failure mode I've seen comparatively often: my
mailer will accept a connection and initiate an ident lookup.  The
ident connection will time out, which takes about 75 seconds, and then
some 11 minutes later - always the same time delay - I'll log an
unexpected connection loss.  This repeats as often as the far end feels
like until it gets tired of trying and gives up.

I've sniffed such connections twice, and each time, the behaviour has
been that my end sends a packet holding the greeting banner; it goes
unacknowledged, and I continue retrying for 11 minutes before giving
up.  I assume there's some filtering package in between that throws
away idle connection state after some interval less than 75 seconds -
and is also configured to silently drop incoming ident connections,
rather than permitting them or doing the drop-with-RST thing.

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