Subject: Automated TCP test

From: Péter Krémer <[email-masked]>
Date: Wed, 07 Jul 1999 13:54:32 +0200

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.

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 7 Jul 1999 09:09:16 -0700 (PDT)

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.

-- 
Vivek Kashyap
[email-masked]
503 578 3422 (o)