I have TCP FIN flag question?

[Guest]

Archived from groups: microsoft.public.windowsnt.protocol.tcpip,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.os.ms-windows.programmer.networks (More info?)

Hi all,

I have a question about processing the FIN flag in TCP. I expect I know
the proper behavior, but I'd like to run it by other people to sanity
check my thinking (before I claim some unnamed operating system has a
bug in their TCP/IP stack).

Suppose machine A sends data to machine B. Machine B has problems keeping
up with the data and ACKs what it can (but not all that machine A has sent).
Machine A sends it's last block of data with the FIN PSH ASK flags on. Since
machine B is still catching up (or in general, the packet may have been lost
on it's way to machine B), machine B doesn't see the original FIN, but
continues to ACK the data as it processes the data. Machine A ends up
resending the last block of data to machine B and machine B finally sees
the data and ACKs it. Am I correct in thinking that machine A IS REQUIRED TO
set the FIN flag when it resent it's last block of data?? Without that,
machine B would never know the connection was terminated, right? Sure, it
sounds obvious, but when you see something being done (apparently wrong) by
one of the most widely used TCP/IP stacks in the world, you have to wonder??

Thanks,

Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: patrick@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==================== What goes around, comes around... =====================

 

[Guest]

Archived from groups: microsoft.public.windowsnt.protocol.tcpip,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.os.ms-windows.programmer.networks (More info?)

In article <c5p6ph$r28$1@pyrite.mv.net>, patrick@klos.com wrote:

> Hi all,
>
> I have a question about processing the FIN flag in TCP. I expect I know
> the proper behavior, but I'd like to run it by other people to sanity
> check my thinking (before I claim some unnamed operating system has a
> bug in their TCP/IP stack).
>
> Suppose machine A sends data to machine B. Machine B has problems keeping
> up with the data and ACKs what it can (but not all that machine A has sent).
> Machine A sends it's last block of data with the FIN PSH ASK flags on. Since
> machine B is still catching up (or in general, the packet may have been lost
> on it's way to machine B), machine B doesn't see the original FIN, but
> continues to ACK the data as it processes the data. Machine A ends up
> resending the last block of data to machine B and machine B finally sees
> the data and ACKs it. Am I correct in thinking that machine A IS REQUIRED TO
> set the FIN flag when it resent it's last block of data?? Without that,
> machine B would never know the connection was terminated, right? Sure, it
> sounds obvious, but when you see something being done (apparently wrong) by
> one of the most widely used TCP/IP stacks in the world, you have to wonder??

Yes. The way to think of it is that the FIN flag is a virtual <eof>
byte in the data stream. It must be retransmitted just like anything
else.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

 

[Guest]

Archived from groups: microsoft.public.windowsnt.protocol.tcpip,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.os.ms-windows.programmer.networks (More info?)

In article <c5p6ph$r28$1@pyrite.mv.net>, patrick@klos.com writes:
| Hi all,
|
| I have a question about processing the FIN flag in TCP. I expect I know
| the proper behavior, but I'd like to run it by other people to sanity
| check my thinking (before I claim some unnamed operating system has a
| bug in their TCP/IP stack).
|
| Suppose machine A sends data to machine B. Machine B has problems keeping
| up with the data and ACKs what it can (but not all that machine A has sent).
| Machine A sends it's last block of data with the FIN PSH ASK flags on. Since
| machine B is still catching up (or in general, the packet may have been lost
| on it's way to machine B), machine B doesn't see the original FIN, but
| continues to ACK the data as it processes the data. Machine A ends up
| resending the last block of data to machine B and machine B finally sees
| the data and ACKs it. Am I correct in thinking that machine A IS REQUIRED TO
| set the FIN flag when it resent it's last block of data??

Machine A is required to retransmit the FIN (just like data, FIN occupies
sequence space) until it is acknowledged (or there is a timeout or whatever).
But the FIN doesn't absolutely have to be set in what I think you are calling
the last block of data. It is possible (though, granted, unlikely) that the
data will be re-packetized such that the FIN ends up in a different (length)
last block of data. It's even possible that the FIN could be sent alone in a
packet separate from the data. I vaguely remember a bug where a FIN could get
lost under some circumstances that confused persist and timeout retransmits.

Dan Lanciani
ddl@danlan.*com

 

[Guest]

Archived from groups: microsoft.public.windowsnt.protocol.tcpip,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.os.ms-windows.programmer.networks (More info?)

KB254930--"TCP Session with Server Never Closes"
http://support.microsoft.com/?kbid=254930

patrick@klos.com wrote:
> Hi all,
>
> I have a question about processing the FIN flag in TCP. I expect I
> know
> the proper behavior, but I'd like to run it by other people to sanity
> check my thinking (before I claim some unnamed operating system has a
> bug in their TCP/IP stack).
>
Assuming that the OS is the suggested by the groups to which you post....
What version? There's KB254930--"TCP Session with Server Never Closes"
http://support.microsoft.com/?kbid=254930 which contains the words, "sends a
FIN request (which the network loses)."
--
Alan J. McFarlane
http://homepage.ntlworld.com/alanjmcf/
Please follow-up in the newsgroup for the benefit of all.