I have TCP FIN flag question? - Programmer

This is a discussion on I have TCP FIN flag question? - Programmer ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: I have TCP FIN flag question?

  1. I have TCP FIN flag question?

    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... =====================

  2. Re: I have TCP FIN flag question?

    In article , 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
    byte in the data stream. It must be retransmitted just like anything
    else.

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

  3. Re: I have TCP FIN flag question?

    In article , 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

  4. Re: I have TCP FIN flag question?

    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.



+ Reply to Thread