Packet Trace Data Files

Trace 1 - Trace of all IP traffic on Ethernet segment. Contains approximately 87,000 packets and 6.5Mb. Trace includes packet headers only.
Trace 2 - Anonymous FTP session with dir, get and put. Contains approximately 930Kbytes and 2300 packets.
Trace 3 - Anonymous FTP session using mput in both ascii and binary modes. Contains approximately 33Kbytes and 340 packets.
Trace 4 - Anonymous FTP session using mget in both ascii and binary modes. Contains approximately 37Kbytes and 370 packets.
Trace 5 - TELNET session (headers only). Contains approximately 45Kbytes and 560 packets.
Trace 6 - SMTP session with delivery of one mail message from SMTP client to SMTP server. Contains approximately 3,000 bytes and 30 packets.
Trace 7 - WWW browser session accessing multiple URLs from multiple WWW servers. Contains approximately 590Kbytes and 1,270 packets.
Trace 8 - X Window System application protocol messages from several clients, including xterm, emacs, xspread and xpaint to an X server. Contains approximately 760Kbytes and 5,500 packets.

About the packet trace data files

All of the trace data comes from the CD accompanying Computer Networks and Internets, 2nd edition by Douglas Comer, Prentice Hall, ISBN 0-13-083617-6. The CD was created by Ralph Droms.

The packet trace data files contain packet traces from an Ethernet segment at Bucknell University. The original traces were generated with the Solaris snoop utility. Some traces were post-processed to remove private data such as passwords from the packets.

Each data file is composed of a fixed header followed by a series of variable-length records. The data for each packet is stored in a separate record. Each record contains a header describing the packet and a timestamp, as well as the contents of one packet. The packets are Ethernet frames, including the source and destination addresses, the protocol type and the frame data.

The data file header consists of 4 32-bit integers, which can be ignored. The fixed header in each record has the format (where an int32 is a 32-bit integer):

struct rechdr {
    int32 framelen;         /* length of the frame, as received      */
    int32 tracelen;         /* length of the frame, as saved in file */
    int32 recrdlen;         /* length of entire record, with header  */
    int32 pad;              /* ignore */
    struct timeval {        /* timestamp when packet was received    */
        int32 tv_sec;           /* seconds since 1/1/70              */
        int32 tv_usec;          /* ... and microseconds              */
    } timestamp;

/*   Ethernet Frame format */
struct EtherFrame {
      char   destaddr[6];         /* destination address */
      char   sourceaddr[6];       /* source address */
      _int16 frame_type;          /* frame type */

/*   Internet Protocol header format */
struct IPheader {
      char   ver_hlen;            /* 4 bit version and 4 bit header length */
      char   service_type;        /* service type */
      _int16 datagram_length;     /* total length of IP packet */
      _int16 ident;               /* indentification flags */
      _int16 flags_offset;        /* flags and fragment offset */
      char   time_to_live;        /* time to live */
      char   pkt_type;            /* type */
      _int16 checksum;            /* header checksum */
      struct in_addr       IP_source;    /* source IP address */
      struct in_addr       IP_dest;      /* destination IP address */

/*  TCP Segment format */
struct TCPsegment {
      _int16 source_port;         /* port number of source */
      _int16 dest_port;           /* destination port number */
      _int32 seqnum;              /* sequence number */
      _int32 acknum;              /* achnowledgement number */
      _int16 stuff;               /* hlen and code bits */
      _int16 window;              /* window buffer space */
      _int16 checksum;            /* segment checksum */
      _int16 urgent;              /* urgent pointer */
The packet data then follows immediately after the data. The following code fragment gives an outline of a program to read and process one of the data files:
lseek(ifile, 16, SEEK_SET); /* skip file header                      */
                            /* read next record header; quit at EOF  */
while ((i = read(ifile, &hdrbuf, sizeof(struct rechdr))) > 0) {
                            /* read next packet; size of packet is   */
                            /* ... length of record - header         */
    read (ifile, pktbuf, hdrbuf.recrdlen - sizeof (struct rechdr));
     * process packet here
Note: The code fragment given above was extracted from a program written for Solaris 2.4; you'll need to adapt the code for your local computer.  A sample program written by Dr. Williams is available here.

As mentioned above, some files have had the data removed from the packet records. Files without data are annotated (headers only). The packet headers can be analyzed and printed, and can be used, for example, to trace the packets exchanged during a TCP a connection or to develop histogram plots based on protocol types. The record header contains the length of the original packet along with the time the packet was received, allowing the computation of network segment load statistics.