Loading ...
Sorry, an error occurred while loading the content.

Automated TCP test

Expand Messages
  • Péter Krémer
    Hi! We have been working on platform independent solution for automated TCP tests. Although, we do not feel 100% ready, we decided to share our experience with
    Message 1 of 2 , Jul 7, 1999
    • 0 Attachment
      Hi!

      We have been working on platform independent solution for automated TCP
      tests. Although, we do not feel 100% ready, we decided to share our
      experience with this forum and also looking forward to get valuable
      feedback from you.

      Briefly, we test TCP features without performing any modification to
      the tested implementation (using the black-box method).
      The basic idea behind the applied methodology is to drive the TCP under
      test into a specific state then apply a stimuli and check if we got the
      right answer.

      We believe that this approach is advantageous to the whole community,
      since it gives a measure of correctness of implementations according to
      the RFC.

      We have been working parallel to the discussions in this list and
      managed to develop formal description of tests, based on previous
      versions of "Known TCP Implementation Problems (RFC 2525)". All test
      cases are written in TTCN, an abstract notation, which has common use
      in telecom protocol tests.

      The use of such an abstraction allows TCP testers to write test scripts
      based on this notation or use available tools for automatic compilation
      and execution. We also performed these tests on 4 different
      implementations (Linux, Solaris, FreeBSD and NT) and managed to detect
      errors, which are not addressed by the RFC mentioned before. A
      postscript version of the paper (submitted to INFOCOM2000)describing
      method and experiences can be found online on

      http://www.cs.columbia.edu/~hgs/papers/infocom2000/591-2818661292.ps

      We are awaiting your comments,

      Roland Gecse, Peter Kremer.
    • Vivek Kashyap
      Hi, I had some time back found a problem not listed in rfc2525. you ... in certain situations the server fails to enter persist state.
      Message 2 of 2 , Jul 7, 1999
      • 0 Attachment
        Hi,
        I had some time back found a problem not listed in rfc2525. you
        might find it of interest:


        ---------------------------------------------------------------------

        in certain situations the server fails to enter persist state.


        =========================================================================


        1) Scenario ... not entering persist state

        <Seen on FreeBSD 2.2.6. A quick look at BSDlite code indicates
        it is present there too and so by implication in many BSD
        derived implementations>


        Server: Client:

        listen,accept,read... connect,write,
        In a loop
        write read()..not reading all so
        that the window fills up
        shutdown (..,SHUT_WR)

        (app blocked on write)
        send FIN
        (ack all data and window of 0)
        rcv FIN
        send ACK
        rcv ACK
        wait in CLOSE_WAIT wait in FIN_WAIT2



        The server stays in CLOSE_WAIT state blocking the application.
        The client is in FIN_WAIT2 awaiting a FIN from the server.

        Analysis:

        The server fails to enter the persist state because:

        When a FIN is received tcp immediately arranges to ACK it but
        in BSDLite/FreeBSD 2.2.6 implementations it does not check for
        entry into persist mode if TF_ACKNOW/t_force flags are set.
        Thus the ACK is sent but TCP does not enter persist mode. So
        the server will not send any probes and there is no retransmit
        timer running. The client is in FIN_WAIT2 and might terminate
        directly based on the FIN_WAIT2 timer. In the case that I looked
        at the client machine had crashed.
        Thus the server will forever stay in CLOSE_WAIT since it is never
        going to probe, so will never get a RST and hence the app will
        never get an indication of the peer having gone away. Of course,
        if there is no FIN_WAIT2 timer implemented then both ends will
        always stay in their respective states.


        Note: (based on BSD sockets API)
        This will occur only when a shutdown() is called since the
        client side TCP is still willing to read data until a close or
        shutdown(..,RD) is done. Therefore it is perfectly ok in sending
        a FIN and a window of 0.


        >
        > Hi!
        >
        > We have been working on platform independent solution for automated TCP
        > tests. Although, we do not feel 100% ready, we decided to share our
        > experience with this forum and also looking forward to get valuable
        > feedback from you.
        >
        > Briefly, we test TCP features without performing any modification to
        > the tested implementation (using the black-box method).
        > The basic idea behind the applied methodology is to drive the TCP under
        > test into a specific state then apply a stimuli and check if we got the
        > right answer.
        >
        > We believe that this approach is advantageous to the whole community,
        > since it gives a measure of correctness of implementations according to
        > the RFC.
        >
        > We have been working parallel to the discussions in this list and
        > managed to develop formal description of tests, based on previous
        > versions of "Known TCP Implementation Problems (RFC 2525)". All test
        > cases are written in TTCN, an abstract notation, which has common use
        > in telecom protocol tests.
        >
        > The use of such an abstraction allows TCP testers to write test scripts
        > based on this notation or use available tools for automatic compilation
        > and execution. We also performed these tests on 4 different
        > implementations (Linux, Solaris, FreeBSD and NT) and managed to detect
        > errors, which are not addressed by the RFC mentioned before. A
        > postscript version of the paper (submitted to INFOCOM2000)describing
        > method and experiences can be found online on
        >
        > http://www.cs.columbia.edu/~hgs/papers/infocom2000/591-2818661292.ps
        >
        > We are awaiting your comments,
        >
        > Roland Gecse, Peter Kremer.
        >


        --
        Vivek Kashyap
        viv@...
        503 578 3422 (o)
      Your message has been successfully submitted and would be delivered to recipients shortly.