Graham Old wrote:
>
> Sorry your both wrong. The correct TCP close method is
>
> A ----- FIN -----> B
> A <--- FIN+ACK --- B
> A ----- ACK -----> B
>
> Or it can be
>
> A ----- FIN -----> B
> A <--- ACK --- B
> A <---- FIN ------ B
> A ---- ACK --> B
>
Arrghh... What a mess... Old sleepy-head here just went
ahead and did a lot of packet capturing to see what
the h--l happens in different situations, just to be
on the safe side.
The most common variant is
A ---- FIN+ACK ----> B
A <---- ACK -------- B
A <--- FIN+ACK ----- B
A ----- ACK -------> B
The ACKs on the FIN packets are simply there because
the endpoint ACKnowledges previously received data.
This is consistent with Graham's 2nd example.
It is ALSO consistent with how one would expect the
interface between the TCP stack and the application
to work:
* TCP stack receives FIN (+ACK)
* TCP stack responds with ACK
* TCP stack tells application that it's received the FIN
* The application decides to close, and tells the TCP stack
to do so
* TCP stack sends FIN (+ACK)
* Other end responds with ACK
Now, _IF_ the recipient of the first FIN decides to wait
before sending the ACK, thereby giving the local application
a chance of deciding to FIN itself, you _could_ see a
A ---- FIN (+ACK) ---> B
A <--- FIN + ACK ----- B
A ------- ACK -------> B
scenario, but I (personally) have never seen one. Maybe
I'm just blind :-)
Then there's the simultaneous close scenario, which is
more common on high delay lines than on short distance
links. This is also what Lisa talked about.
A ---- FIN (+ACK) ---> B \ These two are sent at the same time,
A <--- FIN (+ACK) ---- B / not aware of eachother at the time of sending
A ------- ACK -------> B \ They both have to acknowledge eachother's FINs
A <------ ACK -------- B /
And some weird ass scenarios I've seen previously, like
A ------- SYN -------> B
<-- SYN+ACK ---- B (gets lost in transit)
A ----- SYN+FIN -----> B (A gives up)
A <------ RST -------- B (B doesn't understand what the hell A is
talking about and asks him to cease and decist)
Urghl.
To all the readers: Sorry for the confusion I may have previously
caused by opening my mouth without first connecting my brain. I
hope this serves to clarify things, except for the last example :-)
/Mike
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 �RNSK�LDSVIK
Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50
Mobile: +46 (0)70 248 00 33
WWW: http://www.enternet.se E-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
