Fri May 25, 2001

Shawn Ostermann
ostermann@cs.ohiou.edu

tcptrace is a TCP connection analysis tool.  It can tell you detailed
information about TCP connections by sifting through dump files.  The
dump file formats supported are:
   Standard tcpdump format (you need the pcap library)
   Sun's snoop format
   Macintosh Etherpeek format
   HP/NetMetrix protocol analysis format
   NS simulator output format
   NetScout
   NLANR Tsh Format

To see the graphs, you'll also need Tim Shepard's xplot program,
available at http://www.xplot.org

I've switched to using "./configure" to set up the Makefile.  That
seems to have eased portability problems a great deal.  Just say
"./configure" and then "make" to build the program.

Most of the rest of the Docs are on the web.  Check out:
  http://www.tcptrace.org/


Supported Platforms
-------------------

The program is developed here at OU on Sparc machines running Solaris
8.  Our intention is that it also run under common Unix variants.  In
particular, we try to test each release on the following platforms:
  NetBSD
  FreeBSD
  Linux
  Darwin/OSX (Mac)
  Tru64 (Alpha)

We appreciate feedback and fixes on these or other platforms and will
attempt to modify the program to work on other platforms if we can get
enough help from people with access to those platforms and the changes
are not too "esthetically disagreeable".

Running the program
-------------------

Some simple examples:

0) What are the args and what do they mean???
     tcptrace

1) Run the program quickly over a dump file
     tcptrace dumpfile

2) Get longer output
     tcptrace -l dumpfile

3) Generate lots of pretty plot files (you need xplot to see them)
     tcptrace -G dumpfile

4) Print the segment contents as you go
     tcptrace -p dumpfile

5) Print progress info (useful for large files)
     tcptrace -t dumpfile

Of course, you can chain arguments together until you get just what
you want.


Let me know what you think....

Shawn

Wed May 22, 2002

Matt Muggeridge
Matt.Muggeridge@hp.com

The information contained in this document describes the OpenVMS port
of the tcptrace tool, written by Shawn Ostermann.  Refer to the
"README" file for more information on tcptrace.

This document contains:

   A) Running tcptrace
   B) Build and Install
   C) Code Changes to Support OpenVMS


A) Running tcptrace
-------------------

OpenVMS applications that parse command-line arguments, such as
tcptrace, must be invoked with a foreign command.  A foreign command
can be manually created by declaring a DCL symbol, or automatically
created by defining the DCL$PATH logical to include the directory
path of your application. The examples below use a DCL symbol.

There is a name-space clash with "tcptrace".  TCP/IP Services V5.0 and
later ship an application named TCPTRACE.EXE which is used to capture
trace information, similar to "tcpdump".  To avoid this name-space
clash, it is recommended that this "tcptrace" program is invoked by a
different name.  In the examples below, the name used is "tcpanal",
for TCP Analysis.

The steps for running tcpanal are as follows:

  1) Creating the foreign command
   This is created for you in the DCL command procedure MAKE_VMS.COM.
   If desired, modify MAKE_VMS.COM to change the name of the foreign
   command.  By default, a command similar to the following is used in
   MAKE_VMS.COM:
     $ tcpanal :== $<directory path>tcptrace.exe

  2) Execute the foreign command
     $ tcpanal


B) Build and Install
--------------------
tcptrace on OpenVMS was built and tested using:

  Compaq C V6.4-006 on OpenVMS Alpha V7.2-2 and OpenVMS Alpha V7.3,
  Compaq C V6.2-009 on OpenVMS Alpha V7.2-2
  No VAX testing has been attempted.

Step 1: Get pcap library
  If you don't want to analyse dump files that were created using the
  PCAP library, such as tcpdump, WinDump, Ethereal, then you should
  comment out "GROK_TCPDUMP" from the MAKE_VMS.COM procedure and it
  will be skipped in the compilation.

Step 2: Edit MAKE_VMS.COM
  Only necessary if you want to change the file formats supported,
  the modules compiled in, compiler flags, etc (it's commented)

Step 3: Run "$ @MAKE_VMS"
  That should create tcptrace and define the foreign symbol for
  invoking it.  The foreign symbol is needed due to the name-space
  clash (see README_VMS.TXT).  It is suggested you use the name
  "tcpanal".

  To manually create a foreign command use syntax similar to:

  $ tcpanal :== $<directory path>tcptrace.exe

  For automatic foreign commands, copy tcptrace.exe to a directory
  specified in the DCL$PATH logical.  E.g. assuming DCL$PATH logical
  has been created as:

  $ define DCL$PATH disk$tools:[bin]
  $ copy tcptrace.exe disk$tools:[bin]tcpanal.exe


C) Code Changes to Support OpenVMS
----------------------------------

New Files
====================================================================
readme.OpenVMS   - this file
make_vms.com	 - DCL command procedure to build tcptrace
snprintf_vms.c	 - replacement for snprintf()
includes_vms.tlb - library of include files not shipped with OpenVMS
tcptrace.opt     - linker options file

Missing Header Files - includes_vms.tlb
---------------------------------------
  The following header files are not supplied with the current version
  of OpenVMS compilers nor TCP/IP.  They have been built into a text
  library "includes_vms.tlb" which is referenced during compilation.

	 netinet/in_systm.h
	 machine/endian.h
	 netinet/if_ether.h
	 netinet/ip.h
	 netinet/udp.h
	 netinet/tcp.h (newer version needed than in tcpip$examples)
	 pcap.h (from PCAP distribution)
	 net/bpf.h

  The command used to build this library was:

      $ libr/create/text includes_vms in_systm.h, endian.h, -
        if_ether.h, ip.h, udp.h, tcp.h, pcap.h, bpf.h


Missing snprintf() - snprintf_vms()
-----------------------------------
The current version of the CRTL does not support snprintf().  An
OpenVMS specific module was created "snprintf_vms.c" to resolve this.
The redefinition was made in tcptrace.h (see below).

Modified Files
====================================================================

compress.c
----------
The current release of OpenVMS does not support fork().  These
occurrences were changed to vfork().

filter_parser.c
---------------
OpenVMS uses a builtin function for alloca().  The necessary
redefinitions were made.

gcache.c
--------
Check if bzero or bcopy are defined before redefining them.  On
OpenVMS bzero and bcopy are defined to use the C builtins which are
supposed to be higher performing.

tcptrace.h
----------
Define snprintf() to point to OpenVMS declaration snprintf_vms()


Matt.

--- end ---

To build tcptrace on windows using the cygwin UNIX environment follow the
steps below:

1. For Windows 95/98/Me:
       cp cygwin-libs/win9x/libwpcap.a cygwin-libs/

   For Windows NT/2000/XP:
       cp cygwin-libs/winNT/libwpcap.a cygwin-libs/

2. ./configure
3. make (This leaves tcptrace.exe in the current directory)
4. Installation:
       - Copy the *.dll files from cygwin-libs/win9x/ "OR" cygwin-libs/winNT/
         into C:\WINDOWS\System32\ (OR C:\WINDOWS\System\)
       - Copy tcptrace.exe (just built in step 3) into C:\WINDOWS\

You should now be able to access tcptrace system-wide.

--Avinash Lakhiani (alakhian@tcptrace.org)
  4 July 2002

If you have trouble, try this suggestion from Peter Waltenberg:

>> From peterw@dascom.com Mon Jul 13 22:32 EST 1998
>> X-Priority: 3 (Normal)
>> Date: Tue, 14 Jul 1998 08:31:57 +1000 (EST)
>> Reply-To: peterw@dascom.com
>> Organization: DASCOM
>> Sender: peterw@mulga.surf.dascom.com
>> From: Peter Waltenberg <peterw@dascom.com>
>> To: Shawn Ostermann <sdo@picard.cs.ohiou.edu>
>> Subject: Re: tcptrace
>>
>> On Linux with glibc-2 it needs
>>
>> DEFINES += -D_BSD_SOURCE
>>
>> to build properly.
>>
>> It's simply a matter of which "style" of tcphdr struct naming is
>> pulled in from the include files.
>>
>> From memory the "-D_BSD_SOURCE" is safe for older Linux setups as
>> well, however I can't test it.
>>
>> Peter

There are currently four mailing lists that pertain to tcptrace.  The
two intended for normal users are the "tcptrace" and "tcptrace-announce"
mailing lists.

tcptrace-announce is a very low traffic list, which probably only sees
one or two messages a year.  Everyone who uses tcptrace is encouraged to
subscribe to this list, as it is used to spread the word when significant
new versions of the program come out and major bugs are found and fixed.
You can subscribe to the tcptrace-announce list by sending an email to
majordomo@tcptrace.org that contains the text "subscribe tcptrace-announce".
Should you wish to be removed from the list, all you need to do is send
an email to majordomo@tcptrace.org with the text "unsubscribe tcptrace-announce"
in the body.  No one except the list owner at tcptrace.org may post to this
list.

The list that serves as a forum for most tcptrace related discussion can
be subscribed to by sending email to majordomo@tcptrace.org with the text
"subscribe tcptrace" contained in the body.  Unsubscribing is as easy as
sending majordomo@tcptrace.org a message containing "unsubscribe tcptrace" in
the body.  Posting to this list is restricted to list members only, due to
problems with spam and such.  Traffic on this list is rather light as well,
mostly occurring in short spurts when someone has a question or shares some
tcptrace related software they've written with the community.  You may post
to the list by sending your message to tcptrace@tcptrace.org, if you are
subscribed to the list.  Before posting questions to this list, please consider
that there are about 400 members, so if your question is just something basic
about compiling the program or reading input files perhaps the tcptrace-
maintainers list discussed in the next paragraph is a better venue to ask it.
Problems with subscribing/unsubscribing should be sent to
owner-tcptrace@tcptrace.org

There are also two lists "tcptrace-bugs" and "tcptrace-maintainers" which are
used for notifying us that there is a problem.  If you find what you think is
a bug in the software, please send a message to tcptrace-bugs@tcptrace.org.
This list has all the active tcptrace developers on it, so usually someone can
get on it and write a bugfix fairly quickly, but it's also quite nice when
people send in their own bugfix code.  tcptrace-maintainers@tcptrace.org is
the list which you can use to contact all the people responsible for keeping
up the tcptrace mailing lists, website, and CVS tree.  Problems compiling
tcptrace and questions about how to use the software or interpreting the
output it produces should be addressed to the tcptrace-maintainers list.
You will generally receive an answer fairly promptly.

tcptrace was written by Shawn Ostermann at Ohio University, who can be
reached at ostermann@cs.ohiou.edu to ask questions about the licensing
of the software.

HTML archives of the "tcptrace" and "tcptrace-bugs" lists can be found on
the tcptrace website at http://www.tcptrace.org.

Mon Jul 14, 1997

I added a "plugin module" interface (actually, "compile-in") which
makes it a lot easier to add warts to the program for special purpose
tasks.  There's an example in the modules.h header file (commented
out) that include the module in mod_http.c

Shawn

Mon Jul 14, 1997

To read tcpdump files, you need to packet capture library from LBL.
If you already have tcpdump, then your probably already have it
installed.  If not, then check out:

	ftp://ftp.ee.lbl.gov/libpcap.tar.Z

These sources have been tested with the 0.4 version of libpcap...

--sdo

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

The pcap README file:

@(#) $Header$ (LBL)

LIBPCAP 0.4
Lawrence Berkeley National Laboratory
Network Research Group
libpcap@ee.lbl.gov
ftp://ftp.ee.lbl.gov/libpcap.tar.Z

This directory contains source code for libpcap, a system-independent
interface for user-level packet capture.  libpcap provides a portable
framework for low-level network monitoring.  Applications include
network statistics collection, security monitoring, network debugging,
etc.  Since almost every system vendor provides a different interface
for packet capture, and since we've developed several tools that
require this functionality, we've created this system-independent API
to ease in porting and to alleviate the need for several
system-dependent packet capture modules in each application.

Note well: this interface is new and is likely to change.

The libpcap interface supports a filtering mechanism based on the
architecture in the BSD packet filter.  BPF is described in the 1993
Winter Usenix paper ``The BSD Packet Filter: A New Architecture for
User-level Packet Capture''.  A compressed postscript version is in:

	ftp://ftp.ee.lbl.gov/papers/bpf-usenix93.ps.Z.

Although most packet capture interfaces support in-kernel filtering,
libpcap utilizes in-kernel filtering only for the BPF interface.
On systems that don't have BPF, all packets are read into user-space
and the BPF filters are evaluated in the libpcap library, incurring
added overhead (especially, for selective filters).  Ideally, libpcap
would translate BPF filters into a filter program that is compatible
with the underlying kernel subsystem, but this is not yet implemented.

BPF is standard in 4.4BSD, BSD/386, NetBSD, and FreeBSD.  DEC OSF/1
uses the packetfilter interface but has been extended to accept BPF
filters (which libpcap utilizes).  Also, you can add BPF filter support
to Ultrix using the kernel source and/or object patches available in:

	ftp://gatekeeper.dec.com/pub/DEC/net/bpfext42.tar.Z.

Problems, bugs, questions, desirable enhancements, source code
contributions, etc., should be sent to the email address
"libpcap@ee.lbl.gov".

 - Steve McCanne
   Craig Leres
   Van Jacobson

[I got the following very useful note from a user at SGI with some notes
 on compiler problems.  As nobody has ever mentioned these problems before,
 I suspect that they are peculiar to the SGI C compiler.  Perhaps these
 notes will be helpful to others...

 sdo - Fri Sep 18, 1998]


Date: Mon, 14 Sep 1998 22:07:02 -0300
From: Alejandro Saez <xxxxxxxxxxxx>
Organization: Silicon Chile
To: ostermann@cs.ohiou.edu
Subject: IRIX problem solved

Hi,

[...]

I compiled the program on a IRIX 6.2 SGI workstation. First of all,
the SGI cc compiler didn't work basically because it doesn't accept
(unlike gcc) unterminated strings for formated output functions (it
forces you to have a long line) so this was a problem for the
postscript generation bit. I installed gcc, and here a new problem
arose. Some of your files (mfiles.c, tcptrace.c and plotter.c),
includes and uses the stdarg.h include file. This file uses a SGI
compiler built-in macro called __builtin_alignof, so when using gcc,
ld would complain about not being able to resolve that symbol (makes
sense, it's provided by cc). I was able to solve it by making a local
copy of stdarg.h and changing ocurences of __builtin_alignof by
__alignof__ which is a gcc extension. Of course I had to change
#include <stdarg.h> for #include "stdarg.h" but the nice thing is it
worked (well, it compiled and run with no arguments). I though you
would like to hear about this. Hope comes in handy.


------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.

------------------------------------------------------------
Mon Sep 21, 1998


[...] After I got your e-mail I did a full search and realized that
the gcc distribution included the stdarg.h file (they were pretty
hidden too, and undocumented ) . Funny since I've compiled with gcc on
other SGI boxes and always used SGI's includes, and it made sense,
they are the STANDARD libraries, it never ocurred to me that I needed
two pairs of standard library headers, until now that this one include
depended on a compiler internal.  So maybe is not a good idea to
include the stuff in the notes, or at least say that it's only
necessary if you are using the gcc compiler and SGI's header files,
which of course doesn't make much sense.

README - Time Line Graphs

NOTE:
-----
This code is lacking about a 1000 lines of intellegence that is needed
to draw these graphs correctly. The basic problem we face is that we have
the time values for the segments arriving/leaving on one end since the
traffic dump is carried out on that end. The time values for the other end
have to be estimated based on some heuristic. This requires a lot of
intellegence and requires taking care of various conditions like
retransmits, timeouts etc. The current heuristic is a simple one of
adding/subtacting 1/3rd of the rtt.

We started this project thinking it is easy to draw these graphs, and then
realized that it is infact quite a complicated task. All this works with a
-L option at command line, but may not accurately reflect the segment
timings.

We are currently working on fixing this problem and should be able to
provide more accurate results in the near future.

For tcptrace maintainers:
-------------------------

I have left the code in here as the starting point to work on. Whoever is
working on this project would want to clean up this file trace.c (based on
the diffs below), and continue development as a seperate module.

Don't forget to update this file when this option is fully developed.

--Avinash (alakhian@tcptrace.org)
9 July 2002

-------------------
 DIFFS - plotter.c
-------------------

68,75d67
<     Bool header_done;           /* Flag indicating plotter header written to file */
<     Bool axis_switched;         /* Switch x & y axis types.
< 				 * (Needed for Time Line Charts,
< 				 * Default = FALSE)
< 				 */
<     char *title;                /* Plotter title */
<     char *xlabel;               /* Plotter x-axis label */
<     char *ylabel;               /* Plotter y-axis label */
91,92d82
< static void WritePlotHeader(PLOTTER pl);
< static void CallDoPlot(PLOTTER pl, char *plot_cmd, int plot_argc, ...);
94a85,88
>
>
>
>
114,119d107
<     struct plotter_info *ppi;
<
<     ppi = &pplotters[pl];
<
<     /* see if we're graphing from "0" OR if the axis type is switched */
<     if (graph_time_zero || ppi->axis_switched) {
120a109,111
>     /* see if we're graphing from "0" */
>     if (graph_time_zero) {
> 	struct plotter_info *ppi = &pplotters[pl];
268c259
<
---
>
273,276d263
<
<     /* Write the plotter header if not already written */
<     if(!ppi->header_done)
<      WritePlotHeader(pl);
327a315,336
>     /* graph coordinates... */
>     /*  X coord is timeval unless graph_time_zero is true */
>     /*  Y is signed except when it's a sequence number */
>     /* ugly hack -- unsigned makes the graphs hard to work with and is
>        only needed for the time sequence graphs */
>     /* suggestion by Michele Clark at UNC - make them double instead */
>     Mfprintf(f,"%s %s\n",
> 	     graph_time_zero?"dtime":"timeval",
> 	     ((strcmp(ylabel,"sequence number") == 0)&&(!graph_seq_zero))?
> 	     "double":"signed");
>
>     if (show_title) {
> 	if (xplot_title_prefix)
> 	    Mfprintf(f,"title\n%s %s\n",
> 		     ExpandFormat(xplot_title_prefix),
> 		     title);
> 	else
> 	    Mfprintf(f,"title\n%s\n", title);
>     }
>     Mfprintf(f,"xlabel\n%s\n", xlabel);
>     Mfprintf(f,"ylabel\n%s\n", ylabel);
>
331,338c340
<     ppi->axis_switched = FALSE;
<     ppi->header_done = FALSE;
<
<     /* Save these fields to be writtn to the plotter header later in DoPlot() */
<     ppi->title  = strdup(title);
<     ppi->xlabel = strdup(xlabel);
<     ppi->ylabel = strdup(ylabel);
<
---
>
369,373c371
<
<         /* Write the plotter header if not already written */
<         if(!ppi->header_done)
< 	 WritePlotHeader(pl);
<
---
>
424,425c422,423
<    if (colorplot)
< 	CallDoPlot(pl, color, 0);
---
>     if (colorplot)
> 	DoPlot(pl,"%s",color);
437c435,437
<     CallDoPlot(pl,"line", 4, t1, x1, t2, x2);
---
>     DoPlot(pl,"line %s %u %s %u",
> 	   xp_timestamp(pl,t1), x1,
> 	   xp_timestamp(pl,t2), x2);
449c449,451
<     CallDoPlot(pl,"dline", 4, t1, x1, t2, x2);
---
>     DoPlot(pl,"dline %s %u %s %u",
>            xp_timestamp(pl,t1), x1,
>            xp_timestamp(pl,t2), x2);
459c461
<     CallDoPlot(pl,"diamond", 2, t, x);
---
>     DoPlot(pl,"diamond %s %u", xp_timestamp(pl,t), x);
469c471
<     CallDoPlot(pl,"dot", 2, t, x);
---
>     DoPlot(pl,"dot %s %u", xp_timestamp(pl,t), x);
479c481
<     CallDoPlot(pl,"plus", 2, t, x);
---
>     DoPlot(pl,"plus %s %u", xp_timestamp(pl,t), x);
489c491
<     CallDoPlot(pl,"box", 2, t, x);
---
>     DoPlot(pl,"box %s %u", xp_timestamp(pl,t), x);
501,503c503
<     char arrow_type[7];
<     snprintf(arrow_type, sizeof(arrow_type), "%carrow", dir);
<     CallDoPlot(pl, arrow_type, 2, t, x);
---
>     DoPlot(pl,"%carrow %s %u", dir, xp_timestamp(pl,t), x);
554,556c554
<     char tick_type[6];
<     snprintf(tick_type, sizeof(tick_type), "%ctick", dir);
<     CallDoPlot(pl, tick_type, 2, t, x);
---
>     DoPlot(pl,"%ctick %s %u", dir, xp_timestamp(pl,t), x);
643,646c641
<     char text_type[6];
<     snprintf(text_type, sizeof(text_type), "%stext", where);
<
<     CallDoPlot(pl, text_type, 2, t, x);
---
>     DoPlot(pl,"%stext %s %u", where, xp_timestamp(pl,t), x);
653c648
<     CallDoPlot(pl, str, 0);
---
>     DoPlot(pl,"%s", str);
656,663d650
< void
< plotter_invisible(
<     PLOTTER pl,
<     struct timeval	t,
<     u_long		x)
< {
<     CallDoPlot(pl,"invisible", 2, t, x);
< }
665d651
<
768,925d753
< /* This function may be called with 0, 2 or 4 arguments depending on plot command.
<  * case 0:
<  *   The arguments t1, x1, t2, x2 do not hold any valid values, and are not used.
<  * case 2:
<  *   Arguments t2 and x2 are the same as arguments t1 and x1. Only t1 and x1 are used.
<  * case 4:
<  *   All arguments are valid and are used.
<  */
< static void
< CallDoPlot(
<     PLOTTER pl,
<     char *plot_cmd,
<     int plot_argc,
<     ...)
< {
<    struct timeval t1;
<    u_long x1;
<    struct timeval t2;
<    u_long x2;
<    va_list ap;
<    struct plotter_info *ppi;
<    char fmt[200];
<
<    if (pl == NO_PLOTTER)
<      return;
<
<    if (pl > plotter_ix) {
<       fprintf(stderr,"Illegal plotter: %d\n", pl);
<       exit(-1);
<    }
<
<    ppi = &pplotters[pl];
<
<    /* Get the arguments from the variable list */
<    va_start(ap, plot_argc);
<    if(plot_argc > 0)
<      {
< 	t1 = va_arg(ap, struct timeval);
< 	x1 = va_arg(ap, u_long);
<      }
<    if(plot_argc > 2)
<      {
< 	t2 = va_arg(ap, struct timeval);
< 	x2 = va_arg(ap, u_long);
<      }
<    va_end(ap);
<
<    if(ppi->axis_switched) {
<       switch(plot_argc) {
<        case 0:
< 	 snprintf(fmt, sizeof(fmt), "%s%c", plot_cmd, NULL);
< 	 DoPlot(pl, fmt);
< 	 break;
<        case 2:
< 	 snprintf(fmt, sizeof(fmt), "%s %%u -%%s%c", plot_cmd, NULL);
< 	 DoPlot(pl, fmt,
< 		x1, xp_timestamp(pl,t1));
< 	 break;
<        case 4:
< 	 snprintf(fmt, sizeof(fmt), "%s %%u -%%s %%u -%%s%c", plot_cmd, NULL);
< 	 DoPlot(pl, fmt,
< 		x1, xp_timestamp(pl,t1),
< 		x2, xp_timestamp(pl,t2));
< 	 break;
<        default:
< 	 fprintf(stderr, "CallDoPlot: Illegal number of arguments (%d)\n", plot_argc);
<       }
<    }
<    else {
<       switch(plot_argc) {
<        case 0:
< 	 snprintf(fmt, sizeof(fmt), "%s%c", plot_cmd, NULL);
< 	 DoPlot(pl, fmt);
< 	 break;
<        case 2:
< 	 snprintf(fmt, sizeof(fmt), "%s %%s %%u%c", plot_cmd, NULL);
< 	 DoPlot(pl, fmt,
< 		xp_timestamp(pl,t1), x1);
< 	 break;
<        case 4:
< 	 snprintf(fmt, sizeof(fmt), "%s %%s %%u %%s %%u%c", plot_cmd, NULL);
< 	 DoPlot(pl, fmt,
< 		xp_timestamp(pl,t1), x1,
< 		xp_timestamp(pl,t2), x2);
< 	 break;
<        default:
< 	 fprintf(stderr, "CallDoPlot: Illegal number of arguments (%d)\n", plot_argc);
<       }
<    }
<
<    return;
< }
<
< static void
< WritePlotHeader(
<     PLOTTER pl)
< {
<    MFILE *f = NULL;
<    struct plotter_info *ppi;
<
<    if (pl == NO_PLOTTER)
<      return;
<
<    if (pl > plotter_ix) {
<       fprintf(stderr,"Illegal plotter: %d\n", pl);
<       exit(-1);
<    }
<
<    ppi = &pplotters[pl];
<
<    if ((f = ppi->fplot) == NULL)
<      return;
<
<    if(ppi->axis_switched) {
<       /* Header for the Time Line Charts */
<       Mfprintf(f,"%s %s\n", "unsigned", "dtime");
<    }
<    else {
<       /* Header for all other plots */
<       /* graph coordinates... */
<       /*  X coord is timeval unless graph_time_zero is true */
<       /*  Y is signed except when it's a sequence number */
<       /* ugly hack -- unsigned makes the graphs hard to work with and is
<        only needed for the time sequence graphs */
<       /* suggestion by Michele Clark at UNC - make them double instead */
<       Mfprintf(f,"%s %s\n",
< 	       graph_time_zero?"dtime":"timeval",
< 	       ((strcmp(ppi->ylabel,"sequence number") == 0)&&(!graph_seq_zero))?
< 	       "double":"signed");
<    }
<
<    if (show_title) {
<       if (xplot_title_prefix)
< 	Mfprintf(f,"title\n%s %s\n",
< 		 ExpandFormat(xplot_title_prefix),
< 		 ppi->title);
<       else
< 	Mfprintf(f,"title\n%s\n", ppi->title);
<    }
<
<    Mfprintf(f,"xlabel\n%s\n", ppi->xlabel);
<    Mfprintf(f,"ylabel\n%s\n", ppi->ylabel);
<
<    /* Indicate that the header has now been written to the plotter file */
<    ppi->header_done = TRUE;
<
<    return;
< }
<
< /* Switch the x and y axis type (Needed for Time Line Charts. Default = FLASE) */
< void plotter_switch_axis(
<     PLOTTER pl,
<     Bool flag)
< {
<    struct plotter_info *ppi = &pplotters[pl];
<
<    ppi->axis_switched = flag;
< }

--------------------
 DIFFS - tcptrace.h
--------------------

450,452d449
<     /* Time Line Graph */
<     PLOTTER     tline_plotter;
<
634d630
< extern Bool graph_tline;
744,746c740
< void plotter_nothing(PLOTTER, timeval);
< void plotter_invisible(PLOTTER, timeval, u_long);
< void plotter_switch_axis(PLOTTER, Bool);
---
> void plotter_nothing(PLOTTER pl, struct timeval t);
991d984
< #define TLINE_FILE_EXTENSION		"_tline.xpl"

--------------------
 DIFFS - tcptrace.c
--------------------

107d106
< Bool graph_tline = FALSE;
531d529
<   -L      create time line graph[s]\n\
1800d1797
< 		    graph_tline = TRUE;
1802,1804d1798
< 		  case 'L': graph_tline = TRUE;
< 		    fprintf(stderr, "\nWarning: You have chosen the option '-L' to plot Time Line Graphs.\n         This option is yet under development and may not reflect accurate results.\n         Please take a look at the file README.tline_graphs for more details.\n\n");
< 		    break;
1927d1920
< 		  case 'L': graph_tline = !TRUE; break;
1998a1992
>     fprintf(stderr,"graph tsg:        %s\n", BOOL2STR(graph_tsg));
2001,2004d1994
<     fprintf(stderr,"graph tsg:        %s\n", BOOL2STR(graph_tsg));
<     fprintf(stderr,"graph segsize:    %s\n", BOOL2STR(graph_segsize));
<     fprintf(stderr,"graph owin:       %s\n", BOOL2STR(graph_owin));
<     fprintf(stderr,"graph tline:      %s\n", BOOL2STR(graph_tline));


-----------------
 DIFFS - trace.c
-----------------

74,75d73
< static int tline_left  = 0; /* left and right time lines for the time line charts */
< static int tline_right = 0;
138,140d135
< char *a2b_seg_color     = "green";     /* colors for segments on the time line chart */
< char *b2a_seg_color     = "yellow";
<
470,521d464
<     /* init time line graphs (Avinash, 2 July 2002) */
<     ptp->a2b.tline_plotter = ptp->b2a.tline_plotter = NO_PLOTTER;
<     if (graph_tline && !ptp->ignore_pair) {
< 	if (!ignore_non_comp || (SYN_SET(ptcp))) {
< 	    /* We don't want the standard a2b type name so we will specify
< 	     * a filename of type a_b when we call new_plotter.
< 	     */
< 	    char filename[25];
< 	    snprintf(filename,sizeof(filename),"%s_%s",
< 		     ptp->a2b.host_letter, ptp->a2b.ptwin->host_letter);
<
< 	    snprintf(title,sizeof(title),"%s_==>_%s (time line graph)",
< 		    ptp->a_endpoint, ptp->b_endpoint);
< 	    /* We will keep both the plotters the same since we want all
< 	     * segments going in either direction to be plotted on the same
< 	     * graph
< 	     */
< 	    ptp->a2b.tline_plotter = ptp->b2a.tline_plotter =
< 		new_plotter(&ptp->a2b,filename,title,
< 			    "segments",
< 			    "relative time",
< 			    TLINE_FILE_EXTENSION);
<
< 	    /* Switch the x & y axis types.
< 	     * The default is x - timeval, y - unsigned,
< 	     * we need x - unsigned, y - dtime.
< 	     * Both the plotters are the same so we will
< 	     * only call this function once.
< 	     */
< 	    plotter_switch_axis(ptp->a2b.tline_plotter, TRUE);
<
< 	    /* set graph zero points */
< 	    plotter_nothing(ptp->a2b.tline_plotter, current_time);
< 	    plotter_nothing(ptp->b2a.tline_plotter, current_time);
<
< 	    /* Some graph initializations
< 	     * Generating a drawing space between x=0-100.
< 	     * The time lines will be at x=40 for source, x=60 for destination.
< 	     * Rest of the area on either sides will be used to print segment
< 	     * information.
< 	     *
< 	     *  seg info |----->|
< 	     *           |<-----| seg info
< 	     */
< 	    tline_left  = 40;
< 	    tline_right = 60;
< 	    plotter_invisible(ptp->a2b.tline_plotter, current_time, 0);
< 	    plotter_invisible(ptp->a2b.tline_plotter, current_time, 100);
< 	}
<     }
<
<
1159d1101
<     PLOTTER     tlinepl;
1412,1414d1353
<
<     /* plotter shorthand (NOTE: we are using one plotter for both directions) */
<     tlinepl      = thisdir->tline_plotter;
1415a1355
>
1726,1861c1666
<     }
<
<    /* graph time line */
<    /* Since the axis types have been switched specially for these graphs,
<     * x is actually used as y and y as x
<     * -Avinash.
<     *
<     * NOTE: This code is lacking about a 1000 lines of intellegence that is needed
<     * ----- to draw these graphs correctly. I have left it in here as the starting
<     *       point to work on. Whoever is working on this project would want to clean
<     *       up this file trace.c (based on the patches in the README.tline_graphs
<     *       file), and continue development as a seperate module. We started this
<     *       project thinking it is easy to draw these graphs, and then realized that
<     *       it is infact quite a complicated task. All this works with a -L option at
<     *       command line.
<     */
<    if (tlinepl != NO_PLOTTER) {
<       char buf1[200];
<       char buf2[50];
<       static seqnum a2b_first_seqnum = 0;
<       static seqnum b2a_first_seqnum = 0;
<       /* 1/3rd rtt. Since we have the timestamps only on one side, we calculate the
<        * arrrival/departure time of the segments on the other side by adding/subtracting
<        * 1/3rd rtt. We assume that it takes 1/3rd time for the segment to travel in
<        * either direction, and 1/3rd time for processing.
<        * We also skew the calculated times so that the acks are not seen before the
<        * segments actually arrive.
<        */
<       struct timeval one3rd_rtt;
<       struct timeval copy_current_time;
<       /* Make a copy of the current time (Needed for calculations) */
<       copy_current_time.tv_sec  = current_time.tv_sec;
<       copy_current_time.tv_usec = current_time.tv_usec;
<       /* Compute 1/3rd rtt */
<       one3rd_rtt.tv_sec  = 0;
<       one3rd_rtt.tv_usec = thisdir->rtt_last/3;
<       /* Adjust seconds and microseconds */
<       while(one3rd_rtt.tv_usec >= US_PER_SEC) {
< 	 one3rd_rtt.tv_usec -= US_PER_SEC;
< 	 one3rd_rtt.tv_sec += 1;
<       }
<
<       /* Initializations */
<       memset(&buf1, 0, sizeof(buf1));
<       memset(&buf2, 0, sizeof(buf2));
<
<       /* Segment information */
<       /* Check the flags */
<       if(SYN_SET(ptcp))
< 	strncat(buf1, "SYN ", 4);
<       if(FIN_SET(ptcp))
< 	strncat(buf1, "FIN ", 4);
<       if(RESET_SET(ptcp))
< 	strncat(buf1, "RST ", 4);
<       if(PUSH_SET(ptcp))
< 	strncat(buf1, "PSH ", 4);
<       if(URGENT_SET(ptcp))
< 	strncat(buf1, "URG ", 4);
<
<
<       /* Write the sequence numbers */
<       if(dir == A2B) {
< 	 /* Use relative sequence numbers after the first segment in either direction */
< 	 snprintf(buf2, sizeof(buf2), "%u:%u(%u) %c", (start - a2b_first_seqnum),
< 		  (end - a2b_first_seqnum), (end-start), NULL);
< 	 strncat(buf1, buf2, strlen(buf2));
< 	 if(a2b_first_seqnum == 0 && !SYN_SET(ptcp)) // Don't use relative sequence numbers until handshake is complete.
< 	   a2b_first_seqnum = thisdir->min_seq;
<       }else if(dir == B2A) {
< 	 /* Use relative sequence numbers after the first segment in either direction */
< 	 snprintf(buf2, sizeof(buf2), "%u:%u(%u) %c", (start - b2a_first_seqnum),
< 		  (end - b2a_first_seqnum), (end-start), NULL);
< 	 strncat(buf1, buf2, strlen(buf2));
< 	 if(b2a_first_seqnum == 0 && !SYN_SET(ptcp))
< 	   b2a_first_seqnum = thisdir->min_seq;
<       }
<
<       /* Acknowledgements */
<       if(ACK_SET(ptcp)) {
< 	 memset(&buf2, 0, sizeof(buf2));
< 	 if(dir == A2B)
< 	   snprintf(buf2, sizeof(buf2), "ack %u %c", (th_ack - b2a_first_seqnum), NULL);
< 	 else if(dir == B2A)
< 	   snprintf(buf2, sizeof(buf2), "ack %u %c", (th_ack - a2b_first_seqnum), NULL);
< 	 strncat(buf1, buf2, strlen(buf2));
<       }
<
<       /* Advertised Window */
< 	 memset(&buf2, 0, sizeof(buf2));
< 	 snprintf(buf2, sizeof(buf2), "win %u %c", eff_win,NULL);
< 	 strncat(buf1, buf2, strlen(buf2));
<
<       /* Retransmits */
<       if(retrans) {
< 	 memset(&buf2, 0, sizeof(buf2));
< 	 snprintf(buf2, sizeof(buf2), "R %c", NULL);
< 	 strncat(buf1, buf2, strlen(buf2));
<       }
<
<       /* Hardware Duplicates */
<       if(hw_dup) {
< 	 memset(&buf2, 0, sizeof(buf2));
< 	 snprintf(buf2, sizeof(buf2), "HD %c", NULL);
< 	 strncat(buf1, buf2, strlen(buf2));
<       }
<
<       /* Draw the segment ------>/<------- */
<       if(dir == A2B) {
< 	 tv_add(&copy_current_time, one3rd_rtt);
< 	 plotter_line(tlinepl, ptp_save->first_time, tline_left, copy_current_time, tline_left);
< 	 plotter_line(tlinepl, ptp_save->first_time, tline_right, copy_current_time, tline_right);
< 	 if(SYN_SET(ptcp)|| FIN_SET(ptcp) || RESET_SET(ptcp))
< 	   plotter_perm_color(tlinepl, synfin_color);
< 	 else
< 	   plotter_perm_color(tlinepl, a2b_seg_color);
< 	 plotter_line(tlinepl, current_time, tline_left, copy_current_time, tline_right);
< 	 plotter_rarrow(tlinepl, copy_current_time, tline_right);
< 	 plotter_perm_color(tlinepl, default_color);
< 	 plotter_text(tlinepl, current_time, tline_left, "l", buf1);
<       }
<       else if(dir == B2A) {
< 	 tv_sub(&copy_current_time, one3rd_rtt);
< 	 plotter_line(tlinepl, ptp_save->first_time, tline_left, copy_current_time, tline_left);
< 	 plotter_line(tlinepl, ptp_save->first_time, tline_right, copy_current_time, tline_right);
< 	 if(SYN_SET(ptcp)|| FIN_SET(ptcp) || RESET_SET(ptcp))
< 	   plotter_perm_color(tlinepl, synfin_color);
< 	 else
< 	   plotter_perm_color(tlinepl, b2a_seg_color);
< 	 plotter_line(tlinepl, copy_current_time, tline_right, current_time, tline_left);
< 	 plotter_larrow(tlinepl, current_time, tline_left);
< 	 plotter_perm_color(tlinepl, default_color);
< 	 plotter_text(tlinepl, copy_current_time, tline_right, "r", buf1);
<       }
<
<    }
<
---
>      }

>> When I plot a2b_tput.xpl I get two curves, one red and one blue
>> plus the yellow dots for packets. What is not clear for me is what
>> are the blue and red curves represents with respect to throughput?

Sorry, that stuff hasn't been documented very well, partly because I'm
not sure how to display it more clearly, but here's what it means:

The yellow dots are the instantaneous throughput samples.  They're
calculated by using the time since the last segment for the connection
and the size of the current segment to get bytes/second for this
sample.

The red line is the result of averaging together multiple yellow
dots.  By default (see -A), the red line uses the last 10 segments to
calculate a throughput.  Higher -A values give smoother curves.

The blue line is simply a running average throughput from the
beginning of the transfer, and it's final value is the same as what is
reported for the connection's transfer rate.

Hope that helps.  As I said, I'm not really sure what should be on
this graph.  What's there is the stuff that we've wanted here locally,
but I'd be glad to hear other ideas!

Shawn

Fri May 25, 2001

The version 6 beta version mostly compiles fine on Tru64/Alpha
machines with the following exceptions:

1) You need to modify tcptrace.h to find the unusual definitions that
   Tru64 uses for the bit-field level TCP and IP fields

#define IP_HL(pip)   ((pip)->ip_vhl&0xf)
#define IP_V(pip)    ((pip)->ip_vhl>>4)
#define TH_X2(ptcp)  ((ptcp)->th_xoff&0xf)
#define TH_OFF(ptcp) ((ptcp)->th_xoff>>4)

2) the NS module can't handle those, so you'll need to remove
   "-DGROK_NS" from the Makefile (which will remove NS input file support)

README.version: convention used for version numbers,
                and release instructions

Convention followed for version numbers:
----------------------------------------

Starting with release 6.2.0 of tcptrace, we will be using version
numbers similar to those used for linux software. Following is the
convention followed for version numbers of the form x.y.z:

 - 'z' changes for small bug fixes

 - 'y' changes for certain feature enhancements and reasonably large
       modifications. Also, even numbers indicate stable release and
       odd numbers are for development versions

 - 'x' changes when a whole lot has changed since the previous release


Release Instructions:
---------------------

NOTE: Stable release in this example      : 6.4.0
----- Development version that follows    : 6.5.0

~/tcptrace-cvs$ cvs tag release-6_4_0
~/tcptrace-cvs$ cd
~$ cvs export -d tcptrace-6.4.0 -r release-6_4_0 tcptrace
~$ tar cf tcptrace-6.4.0.tar tcptrace-6.4.0

etc. to create the build.

After that, go back to the tcptrace cvs workspace and *immediately* do the
following:

~/tcptrace-cvs$ cvs tag start-6_5
~/tcptrace-cvs$ cvs tag -b branch-6_5

Then modify the two branches appropriately:

*FOR BUG FIXES*
^^^^^^^^^^^^^^^
~/$ cvs co -d tcptrace-stable tcptrace
(change to *6.4.1, 6.4.2* etc. for each bug fixed and check in)

*FOR NEW FEATURE DEVELOPMENT*
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~/$ cvs co -d tcptrace-devel -r branch-6_5 tcptrace
(change to *6.5.0* and check in)

Now anyone checking out 'tcptrace' with no args will get the
current *stable* branch (bug-fixes only), and anyone checking out with
'-r branch-6_5' would get the current development version with all of its
glorious new features, etc.

Version numbers then go on as 6.4.1, 6.4.2 bug-fixes and,
6.5.1, 6.5.2 etc for development versions until released as 6.6.0 or 7.0.0,
depending on magnitude of development.

--Avinash Lakhiani (alakhian@tcptrace.org)
--Ethan Blanton    (eblanton@tcptrace.org)
  27 Jul 2002

Introduction:
-------------
xpl2gpl is a utility that converters tcptrace-style xplot input to gnuplot input.
This converter gives a nearly perfect gnuplot reproduction of the corresponding
xplot graph.

Installation:
-------------
Simply copy the script file xpl2gpl to a system-wide area like /bin, /usr/bin,
/usr/local/bin or any other suitable location if you wish to make it available to
all users.

Usage:
------
xpl2gpl [-s] <file_name[.xpl]>

This would produce files by the names "file_name.gpl", "file_name.datasets" and
"file_name.labels".
Load the file "file_name.gpl" in gnuplot and it should give you the plot. The
contents of the other files are as follows:
"file_name.datasets" : contains all the plotting coordinates.
"file_name.labels    : contains all the labels of the plot.

"file_name.ps" is the postscript version of the plot that is created when the
file "file_name.gpl" is loaded in gnuplot.


Options:
--------
-s : seperate files (for expert users)

If you wish to plot only some data from the xpl file, you may use the -s (seperate
files) option which generates a bunch of data-files filtered based on the color
and plotting style.

Look at the xplot version of the plot, and based upon the color and style, you may
alter the corresponding lines in the ".gpl" file, for whatever data you want to
alter in the plot.


On behalf of Dr. Shawn Ostermann,

Avinash Lakhiani
Email: avinash.lakhiani@ohiou.edu
Ohio University.

Jun 18, 2001