On Thursday 24 June 2004 4:48 pm, Chris Brenton wrote:
> On Thu, 2004-06-24 at 09:54, Antony Stone wrote:
> > > > No harm done though, because the first one has done the job.
> > >
> > > Actually not quite true as both sides will enter a fin-wait state (RFC
> > > 793 page 20) till the second FIN/ACK-ACK exchange takes place.
> >
> > Depends what you mean by "done the job". I meant the phrase in the
> > sense of "no more data is going to pass across the connection".
>
> I *think* this may be the point of confusion. A FIN/ACK only means that
> the _sender_ is done transmitting data.
Agreed.
> So just because one side of the connection issues a FIN/ACK, it does not
> mean the session is over. The other side of the session may have a lot
> more data to transmit so the session can stay active for some additional
> period of time. Here in lies out problem. Netfilter is reacting to the
> first FIN/ACK and killing off the session before the other end finishes
> communicating and issues it's own FIN/ACK.
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 (by which time the client has finished anyway, since it issued
the request and was just waiting for the response to come back). It seems
not to be often that the client sends a FIN/ACK once it's finished sending
the request, knowing that there's plenty of data to come in a reply (if there
were, I think netfilter would have been changed quite some time ago).
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)?
Regards,
Antony.
--
There's no such thing as bad weather - only the wrong clothes.
- Billy Connolly
Please reply to the list;
please don't CC me.
