On Thu, 2004-06-24 at 12:09, Antony Stone wrote: > > In my experience (with things like SMTP, HTTP) it appears to be the server > which generally issues the (first) FIN/ACK, telling the client that there's > no more data Weird, my experience with HTTP has been the other way around. The client request typically requires just a single back. Its the data returned from the server that can take multiple packets (thus the client finishes first). This is why when most people run into this time-out issue its always the server still trying to transmit _from_ TCP/80, rather than the client trying to send _to_ TCP/80. A good example are the log entries that started this thread. > I wonder how other stateful firewalls (eg: CP FW-1?) handle this sort of thing > - do they listen for *both* FIN/ACKs (and thereby leave themselves prey to > half-open connections littering their connection table for systems which > don't bother to send the responding FIN/ACK)? With FW-1 and PIX, they use a higher state table time out. Again, proper way to fix this would be to reset the timer if the session stays active. Fixes both your worries and mine. :) As for OS's that don't return a FIN/ACK, I can't say I've seen this in the wild (which is why I asked which OS so I could test this). I know there used to be a few OS's (older Mac OS and SGI come to mind) that used to "cheat" by sending a RST/ACK instead of a FIN/ACK, but that was cleaned up years ago. HTH, Chris
