Re: FIN_WAIT2 not working

Gary R. Garrison <g.r.garrison@xxxxxxxxxxxxxxx> wrote:
I have a strange reaction in FIN_WAIT2 in my embedded linux box.

Running which linux kernel?

Once the box enters FIN_WAIT2, an arriving tcp window update causes
a RST to be sent back. This causses an error on the peer. After
verifying using "netstat -a", I know the box is in FIN_WAIT2 for the
correct time period.

Unless there is a platform-specific timeout being set, there is no one
"correct" time period for a connection to be in FIN_WAIT_2. Assuming
there is still a local socket reference to the endpoint it is still a
perfectly valid receive-only connection state.

I've also confirmed the value in the "tcp window update" variable as
60.

?

Has anyone else seen this and if so how do you correct the
situation?

FIN_WAIT_2 means that side has sent a FINished segment and had it
ACKed by the remote. The implication is that all the data up to the
FIN segment has been ACKed as well.

Given that a FIN means that side will be sending no more data, there
really isn't any point in sending a window update to the side which
has sent you a FIN. Still, there also isn't much point in that side
getting bent out of shape by receipt of a window update. Are you
certain that the only things different in the segment carrying the
window update is the update of the window? Posting a trace of the
exchange, including the FIN and ACK of same might be helpful.

I suspect that unless the TCP RFC's have something concrete to say
about it you are in a grey area. The one side is not being
conservative in what it sends by sending a window update after
receiving a FIN, and the other is not being liberal in what it accepts
by having a window update trigger a RST.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.