Re: tcptrace Connections set to INACTIve after 4 minutes idle time.

From: Brian Utterback (brian.utterback@Sun.COM)
Date: 01/29/03

  • Next message: kem: "Re: tcptrace Connections set to INACTIve after 4 minutes idle time." 

    Message-ID: <3E37E701.2000406@sun.com>
Date: Wed, 29 Jan 2003 09:36:49 -0500
From: Brian Utterback <brian.utterback@Sun.COM>
Subject: Re: tcptrace Connections set to INACTIve after 4 minutes idle time.

    That makes no sense. When analyzing a capture file, the tcptrace process
    is short lived. It doesn't
    matter how much memory it uses, within reason, since it will be
    returning those resources as soon
    as it is done running. In real time mode, any memory used will be held
    forever.

    Further, 4 minutes is not a heuristic at all, it is a single arbitrary
    constant. It is not good for all types
    of traffic, or I wouldn't have had a problem. It is terrible for telnet
    or rlogin connections, or any
    connections that will invoke keepalive, or a connection that aborts from
    no response. All of these
    involve phenomena that have more than 4 minutes of idle time.

    Ramani Yellapragada wrote:

    >>Apparently, tcptrace will mark a TCP connection as INACTIVE after 4
    >>minutes of idle time. This means that
    >>subsequent packets on the same connection are counted as a new
    >>connection. I am not sure of the reasoning
    >>here, but I notice that there is a variable to set the idle time
    >>connection for continuous capture mode, but the
    >>time is hard coded for capture file mode. I think this should at least
    >>be settable.
    >>
    >>
    >
    >This is what I feel. In capture file mode, we want to timeout connections
    >to free up the memory space. And 4 minutes is a good heuristic for all
    >types of traffic. But in real-time we want to timeout connections as it
    >may have many implications such as an intrusion taking place. Also in
    >real-time, based on the traffic characterisitics and the type of traffic
    >that we are capturing, we want to set the timeout. Hence the parameter is
    >settable in only real-time mode.
    >
    >Thanks,
    >Ramani.
    >
    >
    > 

    -- 
blu

    NTP: the protocol that ensures that a good time is had by all.
--------------------------------------------------------------------------------
Brian Utterback - PTS Network Support - Sun Microsystems Inc.,
Ph/VM: 781-442-1343, Em:brian.utterback@sun.com

    ----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.

    This archive was generated by hypermail 2b30 : 01/29/03 EST