Is the reported TCP behaviour correct ? - TCP-IP

This is a discussion on Is the reported TCP behaviour correct ? - TCP-IP ; Dear guys, I'm testing a TCP/IP implementation on an embedded device. I've noted a strange behaviour involving a FIN segment and I would like to have your opinions about that. This is the dump captured with Ethereal: No. Source Destination ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Is the reported TCP behaviour correct ?

  1. Is the reported TCP behaviour correct ?

    Dear guys,

    I'm testing a TCP/IP implementation on an embedded device. I've noted a
    strange behaviour
    involving a FIN segment and I would like to have your opinions about
    that.

    This is the dump captured with Ethereal:

    No. Source Destination Info
    613 192.168.1.3 193.205.245.10 1039 > nicname [ACK] Seq=0
    Ack=518912 Win=16384 Len=0
    No. Source Destination Info
    614 193.205.245.10 192.168.1.3 nicname > 1039 [ACK] Seq=521472
    Ack=0 Win=25344 Len=1408
    No. Source Destination Info
    615 192.168.1.3 193.205.245.10 [TCP Dup ACK 613#1] 1039 >
    nicname [ACK] Seq=0 Ack=518912 Win=16384 Len=0
    No. Source Destination Info
    616 193.205.245.10 192.168.1.3 nicname > 1039 [FIN, ACK]
    Seq=522880 Ack=0 Win=25344 Len=1221
    No. Source Destination Info
    617 192.168.1.3 193.205.245.10 [TCP Dup ACK 613#2] 1039 >
    nicname [ACK] Seq=0 Ack=518912 Win=16384 Len=0
    No. Source Destination Info
    618 193.205.245.10 192.168.1.3 [TCP Retransmission] nicname >
    1039 [PSH, ACK] Seq=518912 Ack=0 Win=25344 Len=1408
    No. Source Destination Info
    620 192.168.1.3 193.205.245.10 1039 > nicname [ACK] Seq=0
    Ack=524101 Win=11195 Len=0
    No. Source Destination Info
    621 193.205.245.10 192.168.1.3 [TCP Out-Of-Order] nicname >
    1039 [FIN, ACK] Seq=524101 Ack=0 Win=25344 Len=0
    No. Source Destination Info
    622 192.168.1.3 193.205.245.10 1039 > nicname [ACK] Seq=0
    Ack=524102 Win=16384 Len=0
    No. Source Destination Info
    623 192.168.1.3 193.205.245.10 1039 > nicname [FIN, ACK] Seq=0
    Ack=524102 Win=16384 Len=0
    No. Source Destination Info
    624 192.168.1.3 193.205.245.10 1040 > nicname [SYN] Seq=0
    Ack=0 Win=16384 Len=0 MSS=1460
    No. Source Destination Info
    625 193.205.245.10 192.168.1.3 nicname > 1039 [ACK] Seq=524102
    Ack=1 Win=25344 Len=0

    Peer 192.168.1.3 is the embedded device, peer 193.205.245.10 is a whois
    server.

    The strange behaviour I see is the following:

    - Peer 192.168.1.3 losts segment # 613
    - Peer 192.168.1.3 requires to retransmit it (# 615)
    - Peer 193.205.245.10 sends a FIN segment (# 616) with 1221 bytes of
    data
    - Peer 192.168.1.3 requires to retransmit segment # 613 again (# 617)
    - Peer 193.205.245.10 resends segment # 613 (# 618)
    - Peer 192.168.1.3 ackwnoledges all data received EXCEPT FIN (# 620)
    - Peer 193.205.245.10 resends a FIN segment
    - Peer 192.168.1.3 ackwnoledges FIN

    My question is: should peer 192.168.1.3 also ackwnoledge FIN with
    segment # 620 ? If it did
    so, peer 193.205.245.10 didn't send a FIN segment again. Can I accept
    this behaviour ?

    Best Regards

    /Alessandro


  2. Re: Is the reported TCP behaviour correct ?

    alessandro.strazzero@gmail.com writes:
    > My question is: should peer 192.168.1.3 also ackwnoledge FIN with
    > segment # 620 ? If it did
    > so, peer 193.205.245.10 didn't send a FIN segment again.


    Assuming it didn't trim that FIN flag away, yes, it could have ACK'd
    it and saved the peer the trouble of resending.

    > Can I accept
    > this behaviour ?


    You'll have to answer that.

    Or better yet, you could complain to the vendor in question and ask
    them if they think it's a problem worth fixing.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: Is the reported TCP behaviour correct ?


    James Carlson wrote:

    > > Can I accept
    > > this behaviour ?


    > You'll have to answer that.


    One of the annoying things you learn when you develop a TCP/IP stack is
    that you can't make any assumptions. Even reasonable ones will be
    falsified sooner or later by a sufficiently crazy implementation you
    have to interoperate with. The hard part is recognizing when you're
    making assumptions.

    DS


  4. Re: Is the reported TCP behaviour correct ?

    "David Schwartz" writes:
    > James Carlson wrote:
    >
    > > > Can I accept
    > > > this behaviour ?

    >
    > > You'll have to answer that.

    >
    > One of the annoying things you learn when you develop a TCP/IP stack is
    > that you can't make any assumptions. Even reasonable ones will be
    > falsified sooner or later by a sufficiently crazy implementation you
    > have to interoperate with. The hard part is recognizing when you're
    > making assumptions.


    True, but I think the original poster's real question was different.

    I believe he was asking whether he could perform some sort of
    "acceptance test" on this piece of equipment -- whether he could tell
    the vendor that he was refusing to accept it because of this
    slightly[1] anomalous behavior.

    The underlying problem (it's actually a feature, but no doubt that the
    original poster thinks otherwise) is that there's no such thing for
    TCP/IP. What's acceptable is, fundamentally, what _works_. That's
    what users actually care about -- not puritanical obedience to some
    mighty specification, but rather wide interoperability with peers.

    So, the answer to his question is "maybe." Maybe he can accept it,
    maybe he can't. This packet trace doesn't really help prove the case
    one way or the other, and it's something he alone can resolve.

    [1] Only slightly. There are some possibly good reasons you might
    want to do exactly what this embedded system was doing, including
    being able to ensure that the peer didn't go away too early. It
    might well be a work-around for some other interoperability
    problem, such as dealing with one of those lame devices that
    always emits RST to close a socket.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread