Question regarding RST packet and the tcp stack
cswiger at mac.com
Fri Nov 15 16:03:31 UTC 2013
On Nov 15, 2013, at 7:22 AM, Andrew Schmidt <Andrew.Schmidt at impactmobile.com> wrote:
> Apologies in advance, but can you confirm that a "CLOSE" means either a FIN or RST?
"CLOSE" corresponds to when one side calls close(2) in userland. The TCP stack will send any remaining unsent bytes and then a FIN, moving the connection from ESTAB to FIN-WAIT-1; the other side of the connection which receives a FIN moves to CLOSE-WAIT. (See state diagram around page 22.)
> I've read this section over and over, and I still don't fully understand where it confirms those bytes should be readable (I'm sure you are correct, but I just need to be able to explain this to someone else, and right now I'm not 100% clear)
Well, read other parts of the RFC....
> For instance this part:
>> A TCP will reliably deliver all
>> buffers SENT before the connection was CLOSED so a user who expects no
>> data in return need only wait to hear the connection was CLOSED
>> successfully to know that all his data was received at the destination
> Seems to be talking about the side that is closing the connection (which in my example is the remote side).
Which side wants to close first doesn't have a bearing on data being sent from the other side.
> I'm more interesting in the receiving / host side which hasn't closed any part of it's connection and receives those 3 separate packets (PSH, PSH+ FIN, RST)
PSH flag isn't relevant to the connection lifecycle. Receiving a FIN means the other side is done and has no more data to send. Receiving a RST is not normal, but there are lots of buggy network stacks (or sysctl tuning for busy webservers) which drop the TCB sooner than 2*MSL aka ~4 minutes timeout rather than waiting.
More information about the freebsd-net