From 5d18909f051071ca5d247717c804d525cec0c356 Mon Sep 17 00:00:00 2001 From: Sam Leffler Date: Mon, 4 Sep 2006 19:43:23 +0000 Subject: [PATCH] Import of libpcap v0.9.4 --- contrib/libpcap/CHANGES | 31 +- contrib/libpcap/CREDITS | 1 + contrib/libpcap/README.dag | 51 +- contrib/libpcap/VERSION | 2 +- contrib/libpcap/config.h.in | 3 + contrib/libpcap/configure | 10 +- contrib/libpcap/configure.in | 8 +- contrib/libpcap/doc/pcap.html | 997 +++++++++++++++++++ contrib/libpcap/doc/pcap.txt | 1680 +++++++++++++++++++++++++++++++++ contrib/libpcap/doc/pcap.xml | 746 +++++++++++++++ contrib/libpcap/ethertype.h | 8 +- contrib/libpcap/fad-win32.c | 14 +- contrib/libpcap/gencode.c | 271 ++++-- contrib/libpcap/gencode.h | 5 +- contrib/libpcap/grammar.y | 5 +- contrib/libpcap/pcap-bpf.c | 24 +- contrib/libpcap/pcap-bpf.h | 14 +- contrib/libpcap/pcap-dag.c | 597 +++++++----- contrib/libpcap/pcap-dag.h | 4 +- contrib/libpcap/pcap-dlpi.c | 29 +- contrib/libpcap/pcap-int.h | 21 +- contrib/libpcap/pcap-linux.c | 17 +- contrib/libpcap/pcap-stdinc.h | 3 + contrib/libpcap/pcap-win32.c | 5 +- contrib/libpcap/pcap.3 | 28 +- contrib/libpcap/pcap.c | 9 +- contrib/libpcap/pcap.h | 16 +- contrib/libpcap/savefile.c | 29 +- contrib/libpcap/scanner.l | 5 +- 29 files changed, 4249 insertions(+), 384 deletions(-) create mode 100644 contrib/libpcap/doc/pcap.html create mode 100644 contrib/libpcap/doc/pcap.txt create mode 100644 contrib/libpcap/doc/pcap.xml diff --git a/contrib/libpcap/CHANGES b/contrib/libpcap/CHANGES index d187a99aba6e..3a93ec59f180 100644 --- a/contrib/libpcap/CHANGES +++ b/contrib/libpcap/CHANGES @@ -1,6 +1,17 @@ -@(#) $Header: /tcpdump/master/libpcap/CHANGES,v 1.59.2.1 2005/07/05 21:04:27 mcr Exp $ (LBL) +@(#) $Header: /tcpdump/master/libpcap/CHANGES,v 1.59.2.8 2005/09/05 09:17:47 guy Exp $ (LBL) -Tue. July 5, 2005. ken@xelerance.com. Summary for 3.9.x tcpdump +Mon. September 5, 2005. ken@xelerance.com. Summary for 0.9.4 libpcap release + + Support for radiotap on Linux (Mike Kershaw) + Fixes for HP-UX + Support for additional Juniper link-layer types + Fixes for filters on MPLS-encapsulated packets + "vlan" filter fixed + "pppoed" and "pppoes" filters added; the latter modifies later + parts of the filter expression to look at the PPP headers and + headers in the PPP payload + +Tue. July 5, 2005. ken@xelerance.com. Summary for 0.9.3 libpcap release Fixes for compiling on nearly every platform, including improved 64bit support @@ -9,16 +20,12 @@ Tue. July 5, 2005. ken@xelerance.com. Summary for 3.9.x tcpdump OpenBSD pf format support IrDA capture (Linux only) -Tue. May 27, 2005. mcr@sandelman.ottawa.on.ca. Summary for 0.9.1 release - - Numerous fixes for - Tue. March 30, 2004. mcr@sandelman.ottawa.on.ca. Summary for 3.8.3 release Fixed minor problem in gencode.c that would appear on 64-bit platforms. Version number is now sane. - + Mon. March 29, 2004. mcr@sandelman.ottawa.on.ca. Summary for 3.8.2 release updates for autoconf 2.5 @@ -31,13 +38,13 @@ Wed. November 12, 2003. mcr@sandelman.ottawa.on.ca. Summary for 0.8 release Win32 patches from NetGroup, Politecnico di Torino (Italy) OpenBSD pf, DLT_PFLOG added Many changes to ATM support. - lookup pcap_lookupnet() + lookup pcap_lookupnet() Added DLT_ARCNET_LINUX, DLT_ENC, DLT_IEEE802_11_RADIO, DLT_SUNATM, DLT_IP_OVER_FC, DLT_FRELAY, others. Sigh. More AIX wonderfulness. - Document updates. + Document updates. Changes to API: pcap_next_ex(), pcap_breakloop(), pcap_dump_flush(), - pcap_list_datalinks(), pcap_set_datalink(), + pcap_list_datalinks(), pcap_set_datalink(), pcap_lib_version(), pcap_datalink_val_to_name(), pcap_datalink_name_to_val(), new error returns. @@ -58,7 +65,7 @@ Monday October 23, 2001. mcr@sandelman.ottawa.on.ca. Summary for 0.7 release Added pcap_findalldevs() call to get list of interfaces in a MI way. - pcap_stats() has been documented as to what its counters mean on + pcap_stats() has been documented as to what its counters mean on each platform. Tuesday January 9, 2001. guy@alum.mit.edu. Summary for 0.6 release @@ -131,7 +138,7 @@ Greg Troxel - Added a new "pcap_compile_nopcap()", which lets you compile a filter expression into a BPF program without having an open live capture or capture file. - + v0.4 Sat Jul 25 12:40:09 PDT 1998 - Fix endian problem with DLT_NULL devices. From FreeBSD via Bill diff --git a/contrib/libpcap/CREDITS b/contrib/libpcap/CREDITS index 6b78ed47f9f6..193f2dbd3d13 100644 --- a/contrib/libpcap/CREDITS +++ b/contrib/libpcap/CREDITS @@ -63,6 +63,7 @@ Additional people who have contributed patches: Mark Pizzolato Martin Husemann Matthew Luckie + Mike Kershaw Mike Wiacek Monroe Williams Nicolas Dade diff --git a/contrib/libpcap/README.dag b/contrib/libpcap/README.dag index eb1471b9ffed..49b3e738c731 100644 --- a/contrib/libpcap/README.dag +++ b/contrib/libpcap/README.dag @@ -37,12 +37,57 @@ cards and will not capture from the native OS packet stream. ---------------------------------------------------------------------- +Libpcap when built for DAG cards against dag-2.5.1 or later releases: + +Timeouts are supported. pcap_dispatch() will return after to_ms milliseconds +regardless of how many packets are received. If to_ms is zero pcap_dispatch() +will block waiting for data indefinitely. + +pcap_dispatch() will block on and process a minimum of 64kB of data (before +filtering) for efficiency. This can introduce high latencies on quiet +interfaces unless a timeout value is set. The timeout expiring will override +the 64kB minimum causing pcap_dispatch() to process any available data and +return. + +pcap_setnonblock is supported. When nonblock is set, pcap_dispatch() will +check once for available data, process any data available up to count, then +return immediately. + +pcap_findalldevs() is supported, e.g. dag0, dag1... + +Some DAG cards can provide more than one 'stream' of received data. +This can be data from different physical ports, or separated by filtering +or load balancing mechanisms. Receive streams have even numbers, e.g. +dag0:0, dag0:2 etc. Specifying transmit streams for capture is not supported. + +pcap_setfilter() is supported, BPF programs run in userspace. + +pcap_setdirection() is not supported. Only received traffic is captured. +DAG cards normally do not have IP or link layer addresses assigned as +they are used to passively monitor links. + +pcap_breakloop() is supported. + +pcap_datalink() and pcap_list_datalinks() are supported. The DAG card does +not attempt to set the correct datalink type automatically where more than +one type is possible. + +pcap_stats() is supported. ps_drop is the number of packets dropped due to +RX stream buffer overflow, this count is before filters are applied (it will +include packets that would have been dropped by the filter). The RX stream +buffer size is user configurable outside libpcap, typically 16-512MB. + +pcap_get_selectable_fd() is not supported, DAG cards do not support +poll/select methods. + +pcap_inject() and pcap_sendpacket() are not supported. + +---------------------------------------------------------------------- + Please submit bug reports via . -Please also visit our Web pages at: +Please also visit our Web site at: http://www.endace.com/ - http://dag.cs.waikato.ac.nz/ For more information about Endace DAG cards contact . - diff --git a/contrib/libpcap/VERSION b/contrib/libpcap/VERSION index f374f6662e9a..a602fc9e2833 100644 --- a/contrib/libpcap/VERSION +++ b/contrib/libpcap/VERSION @@ -1 +1 @@ -0.9.1 +0.9.4 diff --git a/contrib/libpcap/config.h.in b/contrib/libpcap/config.h.in index 43a6b94c900b..6943adb54802 100644 --- a/contrib/libpcap/config.h.in +++ b/contrib/libpcap/config.h.in @@ -13,6 +13,9 @@ /* define if you have the DAG API */ #undef HAVE_DAG_API +/* define if you have streams capable DAG API */ +#undef HAVE_DAG_STREAMS_API + /* Define to 1 if you have the declaration of `ether_hostton', and to 0 if you don't. */ #undef HAVE_DECL_ETHER_HOSTTON diff --git a/contrib/libpcap/configure b/contrib/libpcap/configure index 42b8153c3481..bb94054c43a0 100755 --- a/contrib/libpcap/configure +++ b/contrib/libpcap/configure @@ -1,5 +1,5 @@ #! /bin/sh -# From configure.in Revision: 1.120.2.6 . +# From configure.in Revision: 1.120.2.7 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.57. # @@ -5791,6 +5791,14 @@ fi LDFLAGS=$saved_ldflags + if test "$dag_version" = 2.5.x; then + +cat >>confdefs.h <<\_ACEOF +#define HAVE_DAG_STREAMS_API 1 +_ACEOF + + fi + # See if we can find a specific version string. echo "$as_me:$LINENO: checking the DAG API version" >&5 echo $ECHO_N "checking the DAG API version... $ECHO_C" >&6 diff --git a/contrib/libpcap/configure.in b/contrib/libpcap/configure.in index fbc70b88132e..e14d0d032732 100755 --- a/contrib/libpcap/configure.in +++ b/contrib/libpcap/configure.in @@ -1,4 +1,4 @@ -dnl @(#) $Header: /tcpdump/master/libpcap/configure.in,v 1.120.2.6 2005/06/20 21:37:43 guy Exp $ (LBL) +dnl @(#) $Header: /tcpdump/master/libpcap/configure.in,v 1.120.2.7 2005/07/07 06:56:03 guy Exp $ (LBL) dnl dnl Copyright (c) 1994, 1995, 1996, 1997 dnl The Regents of the University of California. All rights reserved. @@ -6,7 +6,7 @@ dnl dnl Process this file with autoconf to produce a configure script. dnl -AC_REVISION($Revision: 1.120.2.6 $) +AC_REVISION($Revision: 1.120.2.7 $) AC_PREREQ(2.50) AC_INIT(pcap.c) @@ -569,6 +569,10 @@ if test $ac_cv_lbl_dag_api = yes; then AC_CHECK_LIB([dag], [dag_attach_stream], [dag_version="2.5.x"], [dag_version="2.4.x"]) LDFLAGS=$saved_ldflags + if test "$dag_version" = 2.5.x; then + AC_DEFINE(HAVE_DAG_STREAMS_API, 1, [define if you have streams capable DAG API]) + fi + # See if we can find a specific version string. AC_MSG_CHECKING([the DAG API version]) if test -r "$dag_root/VERSION"; then diff --git a/contrib/libpcap/doc/pcap.html b/contrib/libpcap/doc/pcap.html new file mode 100644 index 000000000000..94e351400ff0 --- /dev/null +++ b/contrib/libpcap/doc/pcap.html @@ -0,0 +1,997 @@ + +PCAP New Generation Dump File Format + + + + + + +
 TOC 
+
+ + + + +
Network Working GroupL. Degioanni
Internet-DraftF. Risso
Expires: August 30, 2004Politecnico di Torino
 March 2004
+

PCAP New Generation Dump File Format
+

pcap
+ +

Status of this Memo

+

+This document is an Internet-Draft and is +in full conformance with all provisions of Section 10 of RFC2026.

+

+Internet-Drafts are working documents of the Internet Engineering +Task Force (IETF), its areas, and its working groups. +Note that other groups may also distribute working documents as +Internet-Drafts.

+

+Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any time. +It is inappropriate to use Internet-Drafts as reference material or to cite +them other than as "work in progress."

+

+The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt.

+

+The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html.

+

+This Internet-Draft will expire on August 30, 2004.

+ +

Copyright Notice

+

+Copyright (C) The Internet Society (2004). All Rights Reserved.

+ +

Abstract

+ +

This document describes a format to dump captured packets on a file. This format is extensible and it is currently proposed for implementation in the libpcap/WinPcap packet capture library. +


+

Table of Contents

+

+1.  +Objectives
+2.  +General File Structure
+2.1  +General Block Structure
+2.2  +Block Types
+2.3  +Block Hierarchy and Precedence
+2.4  +Data format
+3.  +Block Definition
+3.1  +Section Header Block (mandatory)
+3.2  +Interface Description Block (mandatory)
+3.3  +Packet Block (optional)
+3.4  +Simple Packet Block (optional)
+3.5  +Name Resolution Block (optional)
+3.6  +Interface Statistics Block (optional)
+4.  +Options
+5.  +Experimental Blocks (deserved to a further investigation)
+5.1  +Other Packet Blocks (experimental)
+5.2  +Compression Block (experimental)
+5.3  +Encryption Block (experimental)
+5.4  +Fixed Length Block (experimental)
+5.5  +Directory Block (experimental)
+5.6  +Traffic Statistics and Monitoring Blocks (experimental)
+5.7  +Event/Security Block (experimental)
+6.  +Conclusions
+7.  +Most important open issues
+§  +Intellectual Property and Copyright Statements
+

+
+ +
+
 TOC 
+

1. Objectives

+ +

The problem of exchanging packet traces becomes more and more critical every day; unfortunately, no standard solutions exist for this task right now. One of the most accepted packet interchange formats is the one defined by libpcap, which is rather old and does not fit for some of the nowadays applications especially in terms of extensibility. +

+

This document proposes a new format for dumping packet traces. The following goals are being pursued: +

+
    +
  • Extensibility: aside of some common functionalities, third parties should be able to enrich the information embedded in the file with proprietary extensions, which will be ignored by tools that are not able to understand them. +
    • +
  • Portability: a capture trace must contain all the information needed to read data independently from network, hardware and operating system of the machine that made the capture. +
    • +
  • Merge/Append data: it should be possible to add data at the end of a given file, and the resulting file must still be readable. +
    • +
+
+
 TOC 
+

2. General File Structure

+ +

2.1 General Block Structure

+ +

A capture file is organized in blocks, that are appended one to another to form the file. All the blocks share a common format, which is shown in Figure 1. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Block Type                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Block Total Length                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Block Body                           /
+   /          /* variable length, aligned to 32 bits */            /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Block Total Length                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Basic block structure. 
+ +

The fields have the following meaning: +

+
    +
  • Block Type (32 bits): unique value that identifies the block. Values whose Most Significant Bit (MSB) is equal to 1 are reserved for local use. They allow to save private data to the file and to extend the file format. +
    • +
  • Block Total Length: total size of this block, in bytes. For instance, a block that does not have a body has a length of 12 bytes. +
    • +
  • Block Body: content of the block. +
    • +
  • Block Total Length: total size of this block, in bytes. This field is duplicated for permitting backward file navigation. +
    • +
+

This structure, shared among all blocks, makes easy to process a file and to skip unneeded or unknown blocks. Blocks can be nested one inside the others (NOTE: needed?). Some of the blocks are mandatory, i.e. a dump file is not valid if they are not present, other are optional. +

+

The structure of the blocks allows to define other blocks if needed. A parser that does non understand them can simply ignore their content. +

+

2.2 Block Types

+ +

The currently defined blocks are the following: +

+
    +
  1. Section Header Block: it defines the most important characteristics of the capture file. +
    2. +
  2. Interface Description Block: it defines the most important characteristics of the interface(s) used for capturing traffic. +
    3. +
  3. Packet Block: it contains a single captured packet, or a portion of it. +
    4. +
  4. Simple Packet Block: it contains a single captured packet, or a portion of it, with only a minimal set of information about it. +
    5. +
  5. Name Resolution Block: it defines the mapping from numeric addresses present in the packet dump and the canonical name counterpart. +
    6. +
  6. Capture Statistics Block: it defines how to store some statistical data (e.g. packet dropped, etc) which can be useful to undestand the conditions in which the capture has been made. +
    7. +
  7. Compression Marker Block: TODO +
    8. +
  8. Encryption Marker Block: TODO +
    9. +
  9. Fixed Length Marker Block: TODO +
    10. +
+

The following blocks instead are considered interesting but the authors believe that they deserve more in-depth discussion before being defined: +

+
    +
  1. Further Packet Blocks +
    2. +
  2. Directory Block +
    3. +
  3. Traffic Statistics and Monitoring Blocks +
    4. +
  4. Alert and Security Blocks +
    5. +
+

TODO Currently standardized Block Type codes are specified in Appendix 1. +

+

2.3 Block Hierarchy and Precedence

+ +

The file must begin with a Section Header Block. However, more than one Section Header Block can be present on the dump, each one covering the data following it till the next one (or the end of file). A Section includes the data delimited by two Section Header Blocks (or by a Section Header Block and the end of the file), including the first Section Header Block. +

+

In case an application cannot read a Section because of different version number, it must skip everything until the next Section Header Block. Note that, in order to properly skip the blocks until the next section, all blocks must have the fields Type and Length at the beginning. This is a mandatory requirement that must be maintained in future versions of the block format. +

+

Figure 2 shows two valid files: the first has a typical configuration, with a single Section Header that covers the whole file. The second one contains three headers, and is normally the result of file concatenation. An application that understands only version 1.0 of the file format skips the intermediate section and restart processing the packets after the third Section Header. +


+ +
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | SHB v1.0  |                      Data                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   Typical configuration with a single Section Header Block 
+
+
+   |--   1st Section   --|--   2nd Section   --|--  3rd Section  --|
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | SHB v1.0  |  Data   | SHB V1.1  |  Data   | SHB V1.0  |  Data |  
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   Configuration with three different Section Header Blocks
+
+
 File structure example: the Section Header Block. 
+ +

NOTE: TO BE COMPLETED with some examples of other blocks +

+

2.4 Data format

+ +

Data contained in each section will always be saved according to the characteristics (little endian / big endian) of the dumping machine. This refers to all fields that are saved as numbers and that span over two or more bytes. +

+

The approach of having each section saved in the native format of the generating host is more efficient because it avoids translation of data when reading / writing on the host itself, which is the most common case when generating/processing capture dumps. +

+

TODO Probably we have to specify something more here. Is what we're saying enough to avoid any kind of ambiguity?. +

+
+
 TOC 
+

3. Block Definition

+ +

This section details the format of the body of the blocks currently defined. +

+

3.1 Section Header Block (mandatory)

+ +

The Section Header Block is mandatory. It identifies the beginning of a section of the capture dump file. Its format is shown in Figure 3. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Magic                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Major            |             Minor             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               / 
+   /                      Options (variable)                       / 
+   /                                                               / 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Section Header Block format. 
+ +

The meaning of the fields is: +

+
    +
  • Magic: magic number, whose value is the hexadecimal number 0x1A2B3C4D. This number can be used to distinguish section that have been saved on little-endian machines from the one saved on big-endian machines. +
    • +
  • Major: number of the current mayor version of the format. Current value is 1. +
    • +
  • Minor: number of the current minor version of the format. Current value is 0. +
    • +
  • Options: optionally, a list of options (formatted according to the rules defined in Section 4) can be present. +
    • +
+

Aside form the options defined in Section 4, the following options are valid within this block: +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
NameCodeLengthDescription
Hardware2variableAn ascii string containing the description of the hardware used to create this section.
Operating System3variableAn ascii string containing the name of the operating system used to create this section.
User Application3variableAn ascii string containing the name of the application used to create this section.
+ +

The Section Header Block does not contain data but it rather identifies a list of blocks (interfaces, packets) that are logically correlated. This block does not contain any reference to the size of the section it is currently delimiting, therefore the reader cannot skip a whole section at once. In case a section must be skipped, the user has to repeatedly skip all the blocks contained within it; this makes the parsing of the file slower but it permits to append several capture dumps at the same file. +

+

3.2 Interface Description Block (mandatory)

+ +

The Interface Description Block is mandatory. This block is needed to specify the characteristics of the network interface on which the capture has been made. In order to properly associate the captured data to the corresponding interface, the Interface Description Block must be defined before any other block that uses it; therefore, this block is usually placed immediately after the Section Header Block. +

+

An Interface Description Block is valid only inside the section which it belongs to. The structure of a Interface Description Block is shown in Figure 4. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Interface ID         |           LinkType            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            SnapLen                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               / 
+   /                      Options (variable)                       / 
+   /                                                               / 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Interface Description Block format. 
+ +

The meaning of the fields is: +

+
    +
  • Interface ID: a progressive number that identifies uniquely any interface inside current section. Two Interface Description Blocks can have the same Interface ID only if they are in different sections of the file. The Interface ID is referenced by the packet blocks. +
    • +
  • LinkType: a value that defines the link layer type of this interface. +
    • +
  • SnapLen: maximum number of bytes dumped from each packet. The portion of each packet that exceeds this value will not be stored in the file. +
    • +
  • Options: optionally, a list of options (formatted according to the rules defined in Section 4) can be present. +
    • +
+

In addition to the options defined in Section 4, the following options are valid within this block: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameCodeLengthDescription
if_name2VariableName of the device used to capture data.
if_IPv4addr38Interface network address and netmask.
if_IPv6addr417Interface network address and prefix length (stored in the last byte).
if_MACaddr56Interface Hardware MAC address (48 bits).
if_EUIaddr68Interface Hardware EUI address (64 bits), if available.
if_speed78Interface speed (in bps).
if_tsaccur81Precision of timestamps. If the Most Significant Bit is equal to zero, the remaining bits indicates the accuracy as as a negative power of 10 (e.g. 6 means microsecond accuracy). If the Most Significant Bit is equal to zero, the remaining bits indicates the accuracy as as negative power of 2 (e.g. 10 means 1/1024 of second). If this option is not present, a precision of 10^-6 is assumed.
if_tzone94Time zone for GMT support (TODO: specify better).
if_flags104Interface flags. (TODO: specify better. Possible flags: promiscuous, inbound/outbound, traffic filtered during capture).
if_filter11variableThe filter (e.g. "capture only TCP traffic") used to capture traffic. The first byte of the Option Data keeps a code of the filter used (e.g. if this is a libpcap string, or BPF bytecode, and more). More details about this format will be presented in Appendix XXX (TODO).
if_opersystem12variableAn ascii string containing the name of the operating system of the machine that hosts this interface. This can be different from the same information that can be contained by the Section Header Block (Section 3.1) because the capture can have been done on a remote machine.
+ +

3.3 Packet Block (optional)

+ +

A Packet Block is the standard container for storing the packets coming from the network. The Packet Block is optional because packets can be stored either by means of this block or the Simple Packet Block, which can be used to speed up dump generation. The format of a packet block is shown in Figure 5. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Interface ID          |          Drops Count          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Timestamp (High)                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Timestamp (Low)                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Captured Len                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Packet Len                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                          Packet Data                          |
+   |                                                               |
+   |              /* variable length, byte-aligned */              |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               / 
+   /                      Options (variable)                       / 
+   /                                                               / 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Packet Block format. 
+ +

The Packet Block has the following fields: +

+
    +
  • Interface ID: Specifies the interface this packet comes from, and corresponds to the ID of one of the Interface Description Blocks present in this section of the file (see Figure 4). +
    • +
  • Drops Count: a local drop counter. It specified the number of packets lost (by the interface and the operating system) between this packet and the preceding one. The value xFFFF (in hexadecimal) is reserved for those systems in which this information is not available. +
    • +
  • Timestamp (High): the most significative part of the timestamp. in standard Unix format, i.e. from 1/1/1970. +
    • +
  • Timestamp (Low): the less significative part of the timestamp. The way to interpret this field is specified by the 'ts_accur' option (see Figure 4) of the Interface Description block referenced by this packet. If the Interface Description block does not contain a 'ts_accur' option, then this field is expressed in microseconds. +
    • +
  • Captured Len: number of bytes captured from the packet (i.e. the length of the Packet Data field). It will be the minimum value among the actual Packet Length and the snapshot length (defined in Figure 4). +
    • +
  • Packet Len: actual length of the packet when it was transmitted on the network. Can be different from Captured Len if the user wants only a snapshot of the packet. +
    • +
  • Packet Data: the data coming from the network, including link-layer headers. The length of this field is Captured Len. The format of the link-layer headers depends on the LinkType field specified in the Interface Description Block (see Section 3.2) and it is specified in Appendix XXX (TODO). +
    • +
  • Options: optionally, a list of options (formatted according to the rules defined in Section 4) can be present. +
    • +
+

+

+

3.4 Simple Packet Block (optional)

+ +

The Simple Packet Block is a lightweight container for storing the packets coming from the network. Its presence is optional. +

+

A Simple Packet Block is similar to a Packet Block (see Section 3.3), but it is smaller, simpler to process and contains only a minimal set of information. This block is preferred to the standard Packet Block when performance or space occupation are critical factors, such as in sustained traffic dump applications. A capture file can contain both Packet Blocks and Simple Packet Blocks: for example, a capture tool could switch from Packet Blocks to Simple Packet Blocks when the hardware resources become critical. +

+

The Simple Packet Block does not contain the Interface ID field. Therefore, it must be assumed that all the Simple Packet Blocks have been captured on the interface previously specified in the Interface Description Block. +

+

Figure 6 shows the format of the Simple Packet Block. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Packet Len                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                          Packet Data                          |
+   |                                                               |
+   |              /* variable length, byte-aligned */              |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Simple Packet Block format. 
+ +

The Packet Block has the following fields: +

+
    +
  • Packet Len: actual length of the packet when it was transmitted on the network. Can be different from captured len if the packet has been truncated. +
    • +
  • Packet data: the data coming from the network, including link-layers headers. The length of this field can be derived from the field Block Total Length, present in the Block Header. +
    • +
+

The Simple Packet Block does not contain the timestamp because this is one of the most costly operations on PCs. Additionally, there are applications that do not require it; e.g. an Intrusion Detection System is interested in packets, not in their timestamp. +

+

The Simple Packet Block is very efficient in term of disk space: a snapshot of length 100 bytes requires only 16 bytes of overhead, which corresponds to an efficiency of more than 86%. +

+

3.5 Name Resolution Block (optional)

+ +

The Name Resolution Block is used to support the correlation of numeric addresses (present in the captured packets) and their corresponding canonical names and it is optional. Having the literal names saved in the file, this prevents the need of a name resolution in a delayed time, when the association between names and addresses can be different from the one in use at capture time. Moreover, The Name Resolution Block avoids the need of issuing a lot of DNS requests every time the trace capture is opened, and allows to have name resolution also when reading the capture with a machine not connected to the network. +

+

The format of the Name Resolution Block is shown in Figure 7. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Record Type              |         Record Length         | 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Record Value                            |
+   |              /* variable length, byte-aligned */              |
+   |               + + + + + + + + + + + + + + + + + + + + + + + + +
+   |               |               |               |               |
+   +-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + + + + +
+             . . . other records . . .
+   |  Record Type == end_of_recs   |  Record Length == 00          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               / 
+   /                      Options (variable)                       / 
+   /                                                               / 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Name Resolution Block format. 
+ +

A Name Resolution Block is a zero-terminated list of records (in the TLV format), each of which contains an association between a network address and a name. There are three possible types of records: +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
NameCodeLengthDescription
end_of_recs00End of records
ip4_rec1VariableSpecifies an IPv4 address (contained in the first 4 bytes), followed by one or more zero-terminated strings containing the DNS entries for that address.
ip6_rec1VariableSpecifies an IPv6 address (contained in the first 16 bytes), followed by one or more zero-terminated strings containing the DNS entries for that address.
+ +

After the list or Name Resolution Records, optionally, a list of options (formatted according to the rules defined in Section 4) can be present. +

+

A Name Resolution Block is normally placed at the beginning of the file, but no assumptions can be taken about its position. Name Resolution Blocks can be added in a second time by tools that process the file, like network analyzers. +

+

In addiction to the options defined in Section 4, the following options are valid within this block: +

+ + + + + + + + + + + + +
NameCodeLengthDescription
ns_dnsname2VariableAn ascii string containing the name of the machine (DNS server) used to perform the name resolution.
+ +

3.6 Interface Statistics Block (optional)

+ +

The Interface Statistics Block contains the capture statistics for a given interface and it is optional. The statistics are referred to the interface defined in the current Section identified by the Interface ID field. +

+

The format of the Interface Statistics Block is shown in Figure 8. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         IfRecv                                |
+   |                          (high + low)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         IfDrop                                |
+   |                          (high + low)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         FilterAccept                          |
+   |                          (high + low)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         OSDrop                                |
+   |                          (high + low)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         UsrDelivered                          |
+   |                          (high + low)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Interface ID         |           Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               / 
+   /                      Options (variable)                       / 
+   /                                                               / 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Interface Statistics Block format. 
+ +

The fields have the following meaning: +

+
    +
  • IfRecv: number of packets received from the interface during the capture. This number is reported as a 64 bits value, in which the most significat bits are located in the first four bytes of the field. +
    • +
  • IfDrop: number of packets dropped by the interface during the capture due to lack of resources. +
    • +
  • FilterAccept: number of packets accepeted by filter during current capture. +
    • +
  • OSDrop: number of packets dropped by the operating system during the capture. +
    • +
  • UsrDelivered: number of packets delivered to the user. UsrDelivered can be different from the value 'FilterAccept - OSDropped' because some packets could still lay in the OS buffers when the capture ended. +
    • +
  • Interface ID: reference to an Interface Description Block. +
    • +
  • Reserved: Reserved to future use. +
    • +
  • Options: optionally, a list of options (formatted according to the rules defined in Section 4) can be present. +
    • +
+

In addiction to the options defined in Section 4, the following options are valid within this block: +

+ + + + + + + + + + + + + + + + + + +
NameCodeLengthDescription
isb_starttime28Time in which the capture started; time will be stored in two blocks of four bytes each, containing the timestamp in seconds and nanoseconds.
isb_endtime38Time in which the capture started; time will be stored in two blocks of four bytes each, containing the timestamp in seconds and nanoseconds.
+ +
+
 TOC 
+

4. Options

+ +

Almost all blocks have the possibility to embed optional fields. Optional fields can be used to insert some information that may be useful when reading data, but that it is not really needed for packet processing. Therefore, each tool can be either read the content of the optional fields (if any), or skip them at once. +

+

Skipping all the optional fields at once is straightforward because most of the blocks have a fixed length, therefore the field Block Length (present in the General Block Structure, see Section 2.1) can be used to skip everything till the next block. +

+

Options are a list of Type - Length - Value fields, each one containing a single value: +

+
    +
  • Option Type (2 bytes): it contains the code that specifies the type of the current TLV record. Option types whose Most Significant Bit is equal to one are reserved for local use; therefore, there is no guarantee that the code used is unique among all capture files (generated by other applications). In case of vendor-specific extensions that have to be identified uniquely, vendors must request an Option Code whose MSB is equal to zero. +
    • +
  • Option Length (2 bytes): it contains the length of the following 'Option Value' field. +
    • +
  • Option Value (variable length): it contains the value of the given option. The length of this field as been specified by the Option Length field. +
    • +
+

Options may be repeated several times (e.g. an interface that has several IP addresses associated to it). The option list is terminated by a special code which is the 'End of Option'. +

+

The format of the optional fields is shown in Figure 9. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Option Code              |         Option Length         | 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Option Value                            |
+   |              /* variable length, byte-aligned */              |
+   |               + + + + + + + + + + + + + + + + + + + + + + + + +
+   |               /               /               /               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                 . . . other options . . .                     /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Option Code == opt_endofopt  |  Option Length == 0          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Options format. 
+ +

The following codes can always be present in any optional field: +

+ + + + + + + + + + + + + + + + + + +
NameCodeLengthDescription
opt_endofopt00End of options: it is used to delimit the end of the optional fields. This block cannot be repeated within a given list of options.
opt_comment1variableComment: it is an ascii string containing a comment that is associated to the current block.
+ +
+
 TOC 
+

5. Experimental Blocks (deserved to a further investigation)

+ +

5.1 Other Packet Blocks (experimental)

+ +

Can some other packet blocks (besides the two described in the previous paragraphs) be useful? +

+

5.2 Compression Block (experimental)

+ +

The Compression Block is optional. A file can contain an arbitrary number of these blocks. A Compression Block, as the name says, is used to store compressed data. Its format is shown in Figure 10. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Compr. Type  |                                               |
+   +-+-+-+-+-+-+-+-+                                               |
+   |                                                               |
+   |                       Compressed Data                         |
+   |                                                               |
+   |              /* variable length, byte-aligned */              |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Compression Block format. 
+ +

The fields have the following meaning: +

+
    +
  • Compression Type: specifies the compression algorithm. Possible values for this field are 0 (uncompressed), 1 (Lempel Ziv), 2 (Gzip), other?? Probably some kind of dumb and fast compression algorithm could be effective with some types of traffic (for example web), but which? +
    • +
  • Compressed Data: data of this block. Once decompressed, it is made of other blocks. +
    • +
+

5.3 Encryption Block (experimental)

+ +

The Encryption Block is optional. A file can contain an arbitrary number of these blocks. An Encryption Block is used to sotre encrypted data. Its format is shown in Figure 11. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Encr. Type  |                                               |
+   +-+-+-+-+-+-+-+-+                                               |
+   |                                                               |
+   |                       Compressed Data                         |
+   |                                                               |
+   |              /* variable length, byte-aligned */              |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Encryption Block format. 
+ +

The fields have the following meaning: +

+
    +
  • Compression Type: specifies the encryption algorithm. Possible values for this field are ??? NOTE: this block should probably contain other fields, depending on the encryption algorithm. To be define precisely. +
    • +
  • Encrypted Data: data of this block. Once decripted, it consists of other blocks. +
    • +
+

5.4 Fixed Length Block (experimental)

+ +

The Fixed Length Block is optional. A file can contain an arbitrary number of these blocks. A Fixed Length Block can be used to optimize the access to the file. Its format is shown in Figure 12. +A Fixed Length Block stores records with constant size. It contains a set of Blocks (normally Packet Blocks or Simple Packet Blocks), of wihich it specifies the size. Knowing this size a priori helps to scan the file and to load some portions of it without truncating a block, and is particularly useful with cell-based networks like ATM. +


+ +
+    0                   1                   2                   3   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Cell Size            |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+   |                                                               |
+   |                        Fixed Size Data                        |
+   |                                                               |
+   |              /* variable length, byte-aligned */              |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
 Fixed Length Block format. 
+ +

The fields have the following meaning: +

+
    +
  • Cell size: the size of the blocks contained in the data field. +
    • +
  • Fixed Size Data: data of this block. +
    • +
+

5.5 Directory Block (experimental)

+ +

If present, this block contains the following information: +

+
    +
  • number of indexed packets (N) +
    • +
  • table with position and length of any indexed packet (N entries) +
    • +
+

A directory block must be followed by at least N packets, otherwise it must be considered invalid. It can be used to efficiently load portions of the file to memory and to support operations on memory mapped files. This block can be added by tools like network analyzers as a consequence of file processing. +

+

5.6 Traffic Statistics and Monitoring Blocks (experimental)

+ +

One or more blocks could be defined to contain network statistics or traffic monitoring information. They could be use to store data collected from RMON or Netflow probes, or from other network monitoring tools. +

+

5.7 Event/Security Block (experimental)

+ +

This block could be used to store events. Events could contain generic information (for example network load over 50%, server down...) or security alerts. An event could be: +

+
    +
  • skipped, if the application doesn't know how to do with it +
    • +
  • processed independently by the packets. In other words, the applications skips the packets and processes only the alerts +
    • +
  • processed in relation to packets: for example, a security tool could load only the packets of the file that are near a security alert; a monitorg tool could skip the packets captured while the server was down. +
    • +
+
+
 TOC 
+

6. Conclusions

+ +

The file format proposed in this document should be very versatile and satisfy a wide range of applications. +In the simplest case, it can contain a raw dump of the network data, made of a series of Simple Packet Blocks. +In the most complex case, it can be used as a repository for heterogeneous information. +In every case, the file remains easy to parse and an application can always skip the data it is not interested in; at the same time, different applications can share the file, and each of them can benfit of the information produced by the others. +Two or more files can be concatenated obtaining another valid file. +

+
+
 TOC 
+

7. Most important open issues

+ +
    +
  • Data, in the file, must be byte or word aligned? Currently, the structure of this document is not consistent with respect to this point. +
    • +

+
 TOC 
+

Intellectual Property Statement

+

+The IETF takes no position regarding the validity or scope of +any intellectual property or other rights that might be claimed +to pertain to the implementation or use of the technology +described in this document or the extent to which any license +under such rights might or might not be available; neither does +it represent that it has made any effort to identify any such +rights. Information on the IETF's procedures with respect to +rights in standards-track and standards-related documentation +can be found in BCP-11. Copies of claims of rights made +available for publication and any assurances of licenses to +be made available, or the result of an attempt made +to obtain a general license or permission for the use of such +proprietary rights by implementors or users of this +specification can be obtained from the IETF Secretariat.

+

+The IETF invites any interested party to bring to its +attention any copyrights, patents or patent applications, or +other proprietary rights which may cover technology that may be +required to practice this standard. Please address the +information to the IETF Executive Director.

+

Full Copyright Statement

+

+Copyright (C) The Internet Society (2004). All Rights Reserved.

+

+This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published and +distributed, in whole or in part, without restriction of any kind, +provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of +developing Internet standards in which case the procedures for +copyrights defined in the Internet Standards process must be +followed, or as required to translate it into languages other than +English.

+

+The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assignees.

+

+This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+

Acknowledgment

+

+Funding for the RFC Editor function is currently provided by the +Internet Society.

+ diff --git a/contrib/libpcap/doc/pcap.txt b/contrib/libpcap/doc/pcap.txt new file mode 100644 index 000000000000..cfa6645fc24f --- /dev/null +++ b/contrib/libpcap/doc/pcap.txt @@ -0,0 +1,1680 @@ + + +Network Working Group L. Degioanni +Internet-Draft F. Risso +Expires: August 30, 2004 Politecnico di Torino + March 2004 + + + PCAP New Generation Dump File Format + pcap + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 30, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes a format to dump captured packets on a file. + This format is extensible and it is currently proposed for + implementation in the libpcap/WinPcap packet capture library. + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 1] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +Table of Contents + + 1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. General File Structure . . . . . . . . . . . . . . . . . . . . 4 + 2.1 General Block Structure . . . . . . . . . . . . . . . . . . . 4 + 2.2 Block Types . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3 Block Hierarchy and Precedence . . . . . . . . . . . . . . . . 5 + 2.4 Data format . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Block Definition . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1 Section Header Block (mandatory) . . . . . . . . . . . . . . . 8 + 3.2 Interface Description Block (mandatory) . . . . . . . . . . . 9 + 3.3 Packet Block (optional) . . . . . . . . . . . . . . . . . . . 13 + 3.4 Simple Packet Block (optional) . . . . . . . . . . . . . . . . 15 + 3.5 Name Resolution Block (optional) . . . . . . . . . . . . . . . 16 + 3.6 Interface Statistics Block (optional) . . . . . . . . . . . . 18 + 4. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5. Experimental Blocks (deserved to a further investigation) . . 23 + 5.1 Other Packet Blocks (experimental) . . . . . . . . . . . . . . 23 + 5.2 Compression Block (experimental) . . . . . . . . . . . . . . . 23 + 5.3 Encryption Block (experimental) . . . . . . . . . . . . . . . 23 + 5.4 Fixed Length Block (experimental) . . . . . . . . . . . . . . 24 + 5.5 Directory Block (experimental) . . . . . . . . . . . . . . . . 25 + 5.6 Traffic Statistics and Monitoring Blocks (experimental) . . . 25 + 5.7 Event/Security Block (experimental) . . . . . . . . . . . . . 25 + 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 7. Most important open issues . . . . . . . . . . . . . . . . . . 28 + Intellectual Property and Copyright Statements . . . . . . . . 29 + + + + + + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 2] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +1. Objectives + + The problem of exchanging packet traces becomes more and more + critical every day; unfortunately, no standard solutions exist for + this task right now. One of the most accepted packet interchange + formats is the one defined by libpcap, which is rather old and does + not fit for some of the nowadays applications especially in terms of + extensibility. + + This document proposes a new format for dumping packet traces. The + following goals are being pursued: + + o Extensibility: aside of some common functionalities, third parties + should be able to enrich the information embedded in the file with + proprietary extensions, which will be ignored by tools that are + not able to understand them. + + o Portability: a capture trace must contain all the information + needed to read data independently from network, hardware and + operating system of the machine that made the capture. + + o Merge/Append data: it should be possible to add data at the end of + a given file, and the resulting file must still be readable. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 3] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +2. General File Structure + +2.1 General Block Structure + + A capture file is organized in blocks, that are appended one to + another to form the file. All the blocks share a common format, which + is shown in Figure 1. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Block Body / + / /* variable length, aligned to 32 bits */ / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Basic block structure. + + The fields have the following meaning: + + o Block Type (32 bits): unique value that identifies the block. + Values whose Most Significant Bit (MSB) is equal to 1 are reserved + for local use. They allow to save private data to the file and to + extend the file format. + + o Block Total Length: total size of this block, in bytes. For + instance, a block that does not have a body has a length of 12 + bytes. + + o Block Body: content of the block. + + o Block Total Length: total size of this block, in bytes. This field + is duplicated for permitting backward file navigation. + + This structure, shared among all blocks, makes easy to process a file + and to skip unneeded or unknown blocks. Blocks can be nested one + inside the others (NOTE: needed?). Some of the blocks are mandatory, + i.e. a dump file is not valid if they are not present, other are + optional. + + The structure of the blocks allows to define other blocks if needed. + A parser that does non understand them can simply ignore their + content. + + + +Degioanni & Risso Expires August 30, 2004 [Page 4] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +2.2 Block Types + + The currently defined blocks are the following: + + 1. Section Header Block: it defines the most important + characteristics of the capture file. + + 2. Interface Description Block: it defines the most important + characteristics of the interface(s) used for capturing traffic. + + 3. Packet Block: it contains a single captured packet, or a portion + of it. + + 4. Simple Packet Block: it contains a single captured packet, or a + portion of it, with only a minimal set of information about it. + + 5. Name Resolution Block: it defines the mapping from numeric + addresses present in the packet dump and the canonical name + counterpart. + + 6. Capture Statistics Block: it defines how to store some + statistical data (e.g. packet dropped, etc) which can be useful + to undestand the conditions in which the capture has been made. + + 7. Compression Marker Block: TODO + + 8. Encryption Marker Block: TODO + + 9. Fixed Length Marker Block: TODO + + The following blocks instead are considered interesting but the + authors believe that they deserve more in-depth discussion before + being defined: + + 1. Further Packet Blocks + + 2. Directory Block + + 3. Traffic Statistics and Monitoring Blocks + + 4. Alert and Security Blocks + + TODO Currently standardized Block Type codes are specified in + Appendix 1. + +2.3 Block Hierarchy and Precedence + + The file must begin with a Section Header Block. However, more than + + + +Degioanni & Risso Expires August 30, 2004 [Page 5] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + one Section Header Block can be present on the dump, each one + covering the data following it till the next one (or the end of + file). A Section includes the data delimited by two Section Header + Blocks (or by a Section Header Block and the end of the file), + including the first Section Header Block. + + In case an application cannot read a Section because of different + version number, it must skip everything until the next Section Header + Block. Note that, in order to properly skip the blocks until the next + section, all blocks must have the fields Type and Length at the + beginning. This is a mandatory requirement that must be maintained in + future versions of the block format. + + Figure 2 shows two valid files: the first has a typical + configuration, with a single Section Header that covers the whole + file. The second one contains three headers, and is normally the + result of file concatenation. An application that understands only + version 1.0 of the file format skips the intermediate section and + restart processing the packets after the third Section Header. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SHB v1.0 | Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Typical configuration with a single Section Header Block + + + |-- 1st Section --|-- 2nd Section --|-- 3rd Section --| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Configuration with three different Section Header Blocks + + Figure 2: File structure example: the Section Header Block. + + NOTE: TO BE COMPLETED with some examples of other blocks + +2.4 Data format + + Data contained in each section will always be saved according to the + characteristics (little endian / big endian) of the dumping machine. + This refers to all fields that are saved as numbers and that span + over two or more bytes. + + The approach of having each section saved in the native format of the + generating host is more efficient because it avoids translation of + data when reading / writing on the host itself, which is the most + common case when generating/processing capture dumps. + + + +Degioanni & Risso Expires August 30, 2004 [Page 6] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + TODO Probably we have to specify something more here. Is what we're + saying enough to avoid any kind of ambiguity?. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 7] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +3. Block Definition + + This section details the format of the body of the blocks currently + defined. + +3.1 Section Header Block (mandatory) + + The Section Header Block is mandatory. It identifies the beginning of + a section of the capture dump file. Its format is shown in Figure 3. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Major | Minor | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Section Header Block format. + + The meaning of the fields is: + + o Magic: magic number, whose value is the hexadecimal number + 0x1A2B3C4D. This number can be used to distinguish section that + have been saved on little-endian machines from the one saved on + big-endian machines. + + o Major: number of the current mayor version of the format. Current + value is 1. + + o Minor: number of the current minor version of the format. Current + value is 0. + + o Options: optionally, a list of options (formatted according to the + rules defined in Section 4) can be present. + + Aside form the options defined in Section 4, the following options + are valid within this block: + + +----------------+----------------+----------------+----------------+ + | Name | Code | Length | Description | + +----------------+----------------+----------------+----------------+ + | Hardware | 2 | variable | An ascii | + | | | | string | + + + +Degioanni & Risso Expires August 30, 2004 [Page 8] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + | | | | containing the | + | | | | description of | + | | | | the hardware | + | | | | used to create | + | | | | this section. | + | | | | | + | Operating | 3 | variable | An ascii | + | System | | | string | + | | | | containing the | + | | | | name of the | + | | | | operating | + | | | | system used to | + | | | | create this | + | | | | section. | + | | | | | + | User | 3 | variable | An ascii | + | Application | | | string | + | | | | containing the | + | | | | name of the | + | | | | application | + | | | | used to create | + | | | | this section. | + +----------------+----------------+----------------+----------------+ + + Table 1 + + The Section Header Block does not contain data but it rather + identifies a list of blocks (interfaces, packets) that are logically + correlated. This block does not contain any reference to the size of + the section it is currently delimiting, therefore the reader cannot + skip a whole section at once. In case a section must be skipped, the + user has to repeatedly skip all the blocks contained within it; this + makes the parsing of the file slower but it permits to append several + capture dumps at the same file. + +3.2 Interface Description Block (mandatory) + + The Interface Description Block is mandatory. This block is needed to + specify the characteristics of the network interface on which the + capture has been made. In order to properly associate the captured + data to the corresponding interface, the Interface Description Block + must be defined before any other block that uses it; therefore, this + block is usually placed immediately after the Section Header Block. + + An Interface Description Block is valid only inside the section which + it belongs to. The structure of a Interface Description Block is + shown in Figure 4. + + + + +Degioanni & Risso Expires August 30, 2004 [Page 9] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | LinkType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SnapLen | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Interface Description Block format. + + The meaning of the fields is: + + o Interface ID: a progressive number that identifies uniquely any + interface inside current section. Two Interface Description Blocks + can have the same Interface ID only if they are in different + sections of the file. The Interface ID is referenced by the packet + blocks. + + o LinkType: a value that defines the link layer type of this + interface. + + o SnapLen: maximum number of bytes dumped from each packet. The + portion of each packet that exceeds this value will not be stored + in the file. + + o Options: optionally, a list of options (formatted according to the + rules defined in Section 4) can be present. + + In addition to the options defined in Section 4, the following + options are valid within this block: + + +----------------+----------------+----------------+----------------+ + | Name | Code | Length | Description | + +----------------+----------------+----------------+----------------+ + | if_name | 2 | Variable | Name of the | + | | | | device used to | + | | | | capture data. | + | | | | | + | if_IPv4addr | 3 | 8 | Interface | + | | | | network | + | | | | address and | + | | | | netmask. | + | | | | | + | if_IPv6addr | 4 | 17 | Interface | + + + +Degioanni & Risso Expires August 30, 2004 [Page 10] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + | | | | network | + | | | | address and | + | | | | prefix length | + | | | | (stored in the | + | | | | last byte). | + | | | | | + | if_MACaddr | 5 | 6 | Interface | + | | | | Hardware MAC | + | | | | address (48 | + | | | | bits). | + | | | | | + | if_EUIaddr | 6 | 8 | Interface | + | | | | Hardware EUI | + | | | | address (64 | + | | | | bits), if | + | | | | available. | + | | | | | + | if_speed | 7 | 8 | Interface | + | | | | speed (in | + | | | | bps). | + | | | | | + | if_tsaccur | 8 | 1 | Precision of | + | | | | timestamps. If | + | | | | the Most | + | | | | Significant | + | | | | Bit is equal | + | | | | to zero, the | + | | | | remaining bits | + | | | | indicates the | + | | | | accuracy as as | + | | | | a negative | + | | | | power of 10 | + | | | | (e.g. 6 means | + | | | | microsecond | + | | | | accuracy). If | + | | | | the Most | + | | | | Significant | + | | | | Bit is equal | + | | | | to zero, the | + | | | | remaining bits | + | | | | indicates the | + | | | | accuracy as as | + | | | | negative power | + | | | | of 2 (e.g. 10 | + | | | | means 1/1024 | + | | | | of second). If | + | | | | this option is | + | | | | not present, a | + + + +Degioanni & Risso Expires August 30, 2004 [Page 11] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + | | | | precision of | + | | | | 10^-6 is | + | | | | assumed. | + | | | | | + | if_tzone | 9 | 4 | Time zone for | + | | | | GMT support | + | | | | (TODO: specify | + | | | | better). | + | | | | | + | if_flags | 10 | 4 | Interface | + | | | | flags. (TODO: | + | | | | specify | + | | | | better. | + | | | | Possible | + | | | | flags: | + | | | | promiscuous, | + | | | | inbound/outbou | + | | | | nd, traffic | + | | | | filtered | + | | | | during | + | | | | capture). | + | | | | | + | if_filter | 11 | variable | The filter | + | | | | (e.g. "capture | + | | | | only TCP | + | | | | traffic") used | + | | | | to capture | + | | | | traffic. The | + | | | | first byte of | + | | | | the Option | + | | | | Data keeps a | + | | | | code of the | + | | | | filter used | + | | | | (e.g. if this | + | | | | is a libpcap | + | | | | string, or BPF | + | | | | bytecode, and | + | | | | more). More | + | | | | details about | + | | | | this format | + | | | | will be | + | | | | presented in | + | | | | Appendix XXX | + | | | | (TODO). | + | | | | | + | if_opersystem | 12 | variable | An ascii | + | | | | string | + | | | | containing the | + + + +Degioanni & Risso Expires August 30, 2004 [Page 12] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + | | | | name of the | + | | | | operating | + | | | | system of the | + | | | | machine that | + | | | | hosts this | + | | | | interface. | + | | | | This can be | + | | | | different from | + | | | | the same | + | | | | information | + | | | | that can be | + | | | | contained by | + | | | | the Section | + | | | | Header Block | + | | | | (Section 3.1) | + | | | | because the | + | | | | capture can | + | | | | have been done | + | | | | on a remote | + | | | | machine. | + +----------------+----------------+----------------+----------------+ + + Table 2 + + +3.3 Packet Block (optional) + + A Packet Block is the standard container for storing the packets + coming from the network. The Packet Block is optional because packets + can be stored either by means of this block or the Simple Packet + Block, which can be used to speed up dump generation. The format of a + packet block is shown in Figure 5. + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 13] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | Drops Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (High) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (Low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Captured Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Packet Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Packet Block format. + + The Packet Block has the following fields: + + o Interface ID: Specifies the interface this packet comes from, and + corresponds to the ID of one of the Interface Description Blocks + present in this section of the file (see Figure 4). + + o Drops Count: a local drop counter. It specified the number of + packets lost (by the interface and the operating system) between + this packet and the preceding one. The value xFFFF (in + hexadecimal) is reserved for those systems in which this + information is not available. + + o Timestamp (High): the most significative part of the timestamp. in + standard Unix format, i.e. from 1/1/1970. + + o Timestamp (Low): the less significative part of the timestamp. The + way to interpret this field is specified by the 'ts_accur' option + (see Figure 4) of the Interface Description block referenced by + this packet. If the Interface Description block does not contain a + 'ts_accur' option, then this field is expressed in microseconds. + + o Captured Len: number of bytes captured from the packet (i.e. the + + + +Degioanni & Risso Expires August 30, 2004 [Page 14] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + length of the Packet Data field). It will be the minimum value + among the actual Packet Length and the snapshot length (defined in + Figure 4). + + o Packet Len: actual length of the packet when it was transmitted on + the network. Can be different from Captured Len if the user wants + only a snapshot of the packet. + + o Packet Data: the data coming from the network, including + link-layer headers. The length of this field is Captured Len. The + format of the link-layer headers depends on the LinkType field + specified in the Interface Description Block (see Section 3.2) and + it is specified in Appendix XXX (TODO). + + o Options: optionally, a list of options (formatted according to the + rules defined in Section 4) can be present. + + +3.4 Simple Packet Block (optional) + + The Simple Packet Block is a lightweight container for storing the + packets coming from the network. Its presence is optional. + + A Simple Packet Block is similar to a Packet Block (see Section 3.3), + but it is smaller, simpler to process and contains only a minimal set + of information. This block is preferred to the standard Packet Block + when performance or space occupation are critical factors, such as in + sustained traffic dump applications. A capture file can contain both + Packet Blocks and Simple Packet Blocks: for example, a capture tool + could switch from Packet Blocks to Simple Packet Blocks when the + hardware resources become critical. + + The Simple Packet Block does not contain the Interface ID field. + Therefore, it must be assumed that all the Simple Packet Blocks have + been captured on the interface previously specified in the Interface + Description Block. + + Figure 6 shows the format of the Simple Packet Block. + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 15] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Packet Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Simple Packet Block format. + + The Packet Block has the following fields: + + o Packet Len: actual length of the packet when it was transmitted on + the network. Can be different from captured len if the packet has + been truncated. + + o Packet data: the data coming from the network, including + link-layers headers. The length of this field can be derived from + the field Block Total Length, present in the Block Header. + + The Simple Packet Block does not contain the timestamp because this + is one of the most costly operations on PCs. Additionally, there are + applications that do not require it; e.g. an Intrusion Detection + System is interested in packets, not in their timestamp. + + The Simple Packet Block is very efficient in term of disk space: a + snapshot of length 100 bytes requires only 16 bytes of overhead, + which corresponds to an efficiency of more than 86%. + +3.5 Name Resolution Block (optional) + + The Name Resolution Block is used to support the correlation of + numeric addresses (present in the captured packets) and their + corresponding canonical names and it is optional. Having the literal + names saved in the file, this prevents the need of a name resolution + in a delayed time, when the association between names and addresses + can be different from the one in use at capture time. Moreover, The + Name Resolution Block avoids the need of issuing a lot of DNS + requests every time the trace capture is opened, and allows to have + name resolution also when reading the capture with a machine not + connected to the network. + + The format of the Name Resolution Block is shown in Figure 7. + + + + +Degioanni & Risso Expires August 30, 2004 [Page 16] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Record Type | Record Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Record Value | + | /* variable length, byte-aligned */ | + | + + + + + + + + + + + + + + + + + + + + + + + + + + | | | | | + +-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + + + + + + . . . other records . . . + | Record Type == end_of_recs | Record Length == 00 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Name Resolution Block format. + + A Name Resolution Block is a zero-terminated list of records (in the + TLV format), each of which contains an association between a network + address and a name. There are three possible types of records: + + +----------------+----------------+----------------+----------------+ + | Name | Code | Length | Description | + +----------------+----------------+----------------+----------------+ + | end_of_recs | 0 | 0 | End of records | + | | | | | + | ip4_rec | 1 | Variable | Specifies an | + | | | | IPv4 address | + | | | | (contained in | + | | | | the first 4 | + | | | | bytes), | + | | | | followed by | + | | | | one or more | + | | | | zero-terminate | + | | | | d strings | + | | | | containing the | + | | | | DNS entries | + | | | | for that | + | | | | address. | + | | | | | + | ip6_rec | 1 | Variable | Specifies an | + | | | | IPv6 address | + | | | | (contained in | + | | | | the first 16 | + | | | | bytes), | + + + +Degioanni & Risso Expires August 30, 2004 [Page 17] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + | | | | followed by | + | | | | one or more | + | | | | zero-terminate | + | | | | d strings | + | | | | containing the | + | | | | DNS entries | + | | | | for that | + | | | | address. | + +----------------+----------------+----------------+----------------+ + + Table 3 + + After the list or Name Resolution Records, optionally, a list of + options (formatted according to the rules defined in Section 4) can + be present. + + A Name Resolution Block is normally placed at the beginning of the + file, but no assumptions can be taken about its position. Name + Resolution Blocks can be added in a second time by tools that process + the file, like network analyzers. + + In addiction to the options defined in Section 4, the following + options are valid within this block: + + +----------------+----------------+----------------+----------------+ + | Name | Code | Length | Description | + +----------------+----------------+----------------+----------------+ + | ns_dnsname | 2 | Variable | An ascii | + | | | | string | + | | | | containing the | + | | | | name of the | + | | | | machine (DNS | + | | | | server) used | + | | | | to perform the | + | | | | name | + | | | | resolution. | + +----------------+----------------+----------------+----------------+ + + +3.6 Interface Statistics Block (optional) + + The Interface Statistics Block contains the capture statistics for a + given interface and it is optional. The statistics are referred to + the interface defined in the current Section identified by the + Interface ID field. + + The format of the Interface Statistics Block is shown in Figure 8. + + + + +Degioanni & Risso Expires August 30, 2004 [Page 18] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IfRecv | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IfDrop | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FilterAccept | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OSDrop | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | UsrDelivered | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Interface Statistics Block format. + + The fields have the following meaning: + + o IfRecv: number of packets received from the interface during the + capture. This number is reported as a 64 bits value, in which the + most significat bits are located in the first four bytes of the + field. + + o IfDrop: number of packets dropped by the interface during the + capture due to lack of resources. + + o FilterAccept: number of packets accepeted by filter during current + capture. + + o OSDrop: number of packets dropped by the operating system during + the capture. + + o UsrDelivered: number of packets delivered to the user. + UsrDelivered can be different from the value 'FilterAccept - + OSDropped' because some packets could still lay in the OS buffers + when the capture ended. + + + + +Degioanni & Risso Expires August 30, 2004 [Page 19] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + o Interface ID: reference to an Interface Description Block. + + o Reserved: Reserved to future use. + + o Options: optionally, a list of options (formatted according to the + rules defined in Section 4) can be present. + + In addiction to the options defined in Section 4, the following + options are valid within this block: + + +----------------+----------------+----------------+----------------+ + | Name | Code | Length | Description | + +----------------+----------------+----------------+----------------+ + | isb_starttime | 2 | 8 | Time in which | + | | | | the capture | + | | | | started; time | + | | | | will be stored | + | | | | in two blocks | + | | | | of four bytes | + | | | | each, | + | | | | containing the | + | | | | timestamp in | + | | | | seconds and | + | | | | nanoseconds. | + | | | | | + | isb_endtime | 3 | 8 | Time in which | + | | | | the capture | + | | | | started; time | + | | | | will be stored | + | | | | in two blocks | + | | | | of four bytes | + | | | | each, | + | | | | containing the | + | | | | timestamp in | + | | | | seconds and | + | | | | nanoseconds. | + +----------------+----------------+----------------+----------------+ + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 20] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +4. Options + + Almost all blocks have the possibility to embed optional fields. + Optional fields can be used to insert some information that may be + useful when reading data, but that it is not really needed for packet + processing. Therefore, each tool can be either read the content of + the optional fields (if any), or skip them at once. + + Skipping all the optional fields at once is straightforward because + most of the blocks have a fixed length, therefore the field Block + Length (present in the General Block Structure, see Section 2.1) can + be used to skip everything till the next block. + + Options are a list of Type - Length - Value fields, each one + containing a single value: + + o Option Type (2 bytes): it contains the code that specifies the + type of the current TLV record. Option types whose Most + Significant Bit is equal to one are reserved for local use; + therefore, there is no guarantee that the code used is unique + among all capture files (generated by other applications). In case + of vendor-specific extensions that have to be identified uniquely, + vendors must request an Option Code whose MSB is equal to zero. + + o Option Length (2 bytes): it contains the length of the following + 'Option Value' field. + + o Option Value (variable length): it contains the value of the given + option. The length of this field as been specified by the Option + Length field. + + Options may be repeated several times (e.g. an interface that has + several IP addresses associated to it). The option list is terminated + by a special code which is the 'End of Option'. + + The format of the optional fields is shown in Figure 9. + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 21] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Code | Option Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Value | + | /* variable length, byte-aligned */ | + | + + + + + + + + + + + + + + + + + + + + + + + + + + | / / / | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / . . . other options . . . / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Code == opt_endofopt | Option Length == 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: Options format. + + The following codes can always be present in any optional field: + + +----------------+----------------+----------------+----------------+ + | Name | Code | Length | Description | + +----------------+----------------+----------------+----------------+ + | opt_endofopt | 0 | 0 | End of | + | | | | options: it is | + | | | | used to | + | | | | delimit the | + | | | | end of the | + | | | | optional | + | | | | fields. This | + | | | | block cannot | + | | | | be repeated | + | | | | within a given | + | | | | list of | + | | | | options. | + | | | | | + | opt_comment | 1 | variable | Comment: it is | + | | | | an ascii | + | | | | string | + | | | | containing a | + | | | | comment that | + | | | | is associated | + | | | | to the current | + | | | | block. | + +----------------+----------------+----------------+----------------+ + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 22] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +5. Experimental Blocks (deserved to a further investigation) + +5.1 Other Packet Blocks (experimental) + + Can some other packet blocks (besides the two described in the + previous paragraphs) be useful? + +5.2 Compression Block (experimental) + + The Compression Block is optional. A file can contain an arbitrary + number of these blocks. A Compression Block, as the name says, is + used to store compressed data. Its format is shown in Figure 10. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Compr. Type | | + +-+-+-+-+-+-+-+-+ | + | | + | Compressed Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: Compression Block format. + + The fields have the following meaning: + + o Compression Type: specifies the compression algorithm. Possible + values for this field are 0 (uncompressed), 1 (Lempel Ziv), 2 + (Gzip), other?? Probably some kind of dumb and fast compression + algorithm could be effective with some types of traffic (for + example web), but which? + + o Compressed Data: data of this block. Once decompressed, it is made + of other blocks. + + +5.3 Encryption Block (experimental) + + The Encryption Block is optional. A file can contain an arbitrary + number of these blocks. An Encryption Block is used to sotre + encrypted data. Its format is shown in Figure 11. + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 23] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encr. Type | | + +-+-+-+-+-+-+-+-+ | + | | + | Compressed Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: Encryption Block format. + + The fields have the following meaning: + + o Compression Type: specifies the encryption algorithm. Possible + values for this field are ??? NOTE: this block should probably + contain other fields, depending on the encryption algorithm. To be + define precisely. + + o Encrypted Data: data of this block. Once decripted, it consists of + other blocks. + + +5.4 Fixed Length Block (experimental) + + The Fixed Length Block is optional. A file can contain an arbitrary + number of these blocks. A Fixed Length Block can be used to optimize + the access to the file. Its format is shown in Figure 12. A Fixed + Length Block stores records with constant size. It contains a set of + Blocks (normally Packet Blocks or Simple Packet Blocks), of wihich it + specifies the size. Knowing this size a priori helps to scan the file + and to load some portions of it without truncating a block, and is + particularly useful with cell-based networks like ATM. + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 24] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cell Size | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + | Fixed Size Data | + | | + | /* variable length, byte-aligned */ | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 12: Fixed Length Block format. + + The fields have the following meaning: + + o Cell size: the size of the blocks contained in the data field. + + o Fixed Size Data: data of this block. + + +5.5 Directory Block (experimental) + + If present, this block contains the following information: + + o number of indexed packets (N) + + o table with position and length of any indexed packet (N entries) + + A directory block must be followed by at least N packets, otherwise + it must be considered invalid. It can be used to efficiently load + portions of the file to memory and to support operations on memory + mapped files. This block can be added by tools like network analyzers + as a consequence of file processing. + +5.6 Traffic Statistics and Monitoring Blocks (experimental) + + One or more blocks could be defined to contain network statistics or + traffic monitoring information. They could be use to store data + collected from RMON or Netflow probes, or from other network + monitoring tools. + +5.7 Event/Security Block (experimental) + + This block could be used to store events. Events could contain + generic information (for example network load over 50%, server + down...) or security alerts. An event could be: + + + +Degioanni & Risso Expires August 30, 2004 [Page 25] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + o skipped, if the application doesn't know how to do with it + + o processed independently by the packets. In other words, the + applications skips the packets and processes only the alerts + + o processed in relation to packets: for example, a security tool + could load only the packets of the file that are near a security + alert; a monitorg tool could skip the packets captured while the + server was down. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 26] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +6. Conclusions + + The file format proposed in this document should be very versatile + and satisfy a wide range of applications. In the simplest case, it + can contain a raw dump of the network data, made of a series of + Simple Packet Blocks. In the most complex case, it can be used as a + repository for heterogeneous information. In every case, the file + remains easy to parse and an application can always skip the data it + is not interested in; at the same time, different applications can + share the file, and each of them can benfit of the information + produced by the others. Two or more files can be concatenated + obtaining another valid file. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 27] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +7. Most important open issues + + o Data, in the file, must be byte or word aligned? Currently, the + structure of this document is not consistent with respect to this + point. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 28] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Degioanni & Risso Expires August 30, 2004 [Page 29] + +Internet-Draft PCAP New Generation Dump File Format March 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Degioanni & Risso Expires August 30, 2004 [Page 30] + diff --git a/contrib/libpcap/doc/pcap.xml b/contrib/libpcap/doc/pcap.xml new file mode 100644 index 000000000000..ebbf3217fd59 --- /dev/null +++ b/contrib/libpcap/doc/pcap.xml @@ -0,0 +1,746 @@ + + + + + + + + PCAP New Generation Dump File Format + + Politecnico di Torino +
+ + Corso Duca degli Abruzzi, 24 + Torino + 10129 + Italy + + +39 011 564 7008 + loris.degioanni@polito.it + http://netgroup.polito.it/loris/ +
+ + + Politecnico di Torino +
+ + Corso Duca degli Abruzzi, 24 + Torino + 10129 + Italy + + +39 011 564 7008 + fulvio.risso@polito.it + http://netgroup.polito.it/fulvio.risso/ +
+ + + + + + General + + Internet-Draft + Libpcap, dump file format + +This document describes a format to dump captured packets on a file. This format is extensible and it is currently proposed for implementation in the libpcap/WinPcap packet capture library. + + + + + +
+The problem of exchanging packet traces becomes more and more critical every day; unfortunately, no standard solutions exist for this task right now. One of the most accepted packet interchange formats is the one defined by libpcap, which is rather old and does not fit for some of the nowadays applications especially in terms of extensibility. +This document proposes a new format for dumping packet traces. The following goals are being pursued: + +Extensibility: aside of some common functionalities, third parties should be able to enrich the information embedded in the file with proprietary extensions, which will be ignored by tools that are not able to understand them. +Portability: a capture trace must contain all the information needed to read data independently from network, hardware and operating system of the machine that made the capture. +Merge/Append data: it should be possible to add data at the end of a given file, and the resulting file must still be readable. + + +
+ + +
+ +
+A capture file is organized in blocks, that are appended one to another to form the file. All the blocks share a common format, which is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Block Body / + / /* variable length, aligned to 32 bits */ / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The fields have the following meaning: + + +Block Type (32 bits): unique value that identifies the block. Values whose Most Significant Bit (MSB) is equal to 1 are reserved for local use. They allow to save private data to the file and to extend the file format. +Block Total Length: total size of this block, in bytes. For instance, a block that does not have a body has a length of 12 bytes. +Block Body: content of the block. +Block Total Length: total size of this block, in bytes. This field is duplicated for permitting backward file navigation. + + +This structure, shared among all blocks, makes easy to process a file and to skip unneeded or unknown blocks. Blocks can be nested one inside the others (NOTE: needed?). Some of the blocks are mandatory, i.e. a dump file is not valid if they are not present, other are optional. +The structure of the blocks allows to define other blocks if needed. A parser that does non understand them can simply ignore their content. +
+ +
+The currently defined blocks are the following: + +Section Header Block: it defines the most important characteristics of the capture file. +Interface Description Block: it defines the most important characteristics of the interface(s) used for capturing traffic. +Packet Block: it contains a single captured packet, or a portion of it. +Simple Packet Block: it contains a single captured packet, or a portion of it, with only a minimal set of information about it. +Name Resolution Block: it defines the mapping from numeric addresses present in the packet dump and the canonical name counterpart. +Capture Statistics Block: it defines how to store some statistical data (e.g. packet dropped, etc) which can be useful to undestand the conditions in which the capture has been made. +Compression Marker Block: TODO +Encryption Marker Block: TODO +Fixed Length Marker Block: TODO + + +The following blocks instead are considered interesting but the authors believe that they deserve more in-depth discussion before being defined: + +Further Packet Blocks +Directory Block +Traffic Statistics and Monitoring Blocks +Alert and Security Blocks + + +TODO Currently standardized Block Type codes are specified in Appendix 1. + +
+ +
+The file must begin with a Section Header Block. However, more than one Section Header Block can be present on the dump, each one covering the data following it till the next one (or the end of file). A Section includes the data delimited by two Section Header Blocks (or by a Section Header Block and the end of the file), including the first Section Header Block. +In case an application cannot read a Section because of different version number, it must skip everything until the next Section Header Block. Note that, in order to properly skip the blocks until the next section, all blocks must have the fields Type and Length at the beginning. This is a mandatory requirement that must be maintained in future versions of the block format. + shows two valid files: the first has a typical configuration, with a single Section Header that covers the whole file. The second one contains three headers, and is normally the result of file concatenation. An application that understands only version 1.0 of the file format skips the intermediate section and restart processing the packets after the third Section Header. + +
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SHB v1.0 | Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Typical configuration with a single Section Header Block + + + |-- 1st Section --|-- 2nd Section --|-- 3rd Section --| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Configuration with three different Section Header Blocks + +
+ +NOTE: TO BE COMPLETED with some examples of other blocks + +
+ +
+Data contained in each section will always be saved according to the characteristics (little endian / big endian) of the dumping machine. This refers to all fields that are saved as numbers and that span over two or more bytes. +The approach of having each section saved in the native format of the generating host is more efficient because it avoids translation of data when reading / writing on the host itself, which is the most common case when generating/processing capture dumps. +TODO Probably we have to specify something more here. Is what we're saying enough to avoid any kind of ambiguity?. +
+ +
+ + + + +
+This section details the format of the body of the blocks currently defined. + +
+The Section Header Block is mandatory. It identifies the beginning of a section of the capture dump file. Its format is shown in . +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Major | Minor | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The meaning of the fields is: + +Magic: magic number, whose value is the hexadecimal number 0x1A2B3C4D. This number can be used to distinguish section that have been saved on little-endian machines from the one saved on big-endian machines. +Major: number of the current mayor version of the format. Current value is 1. +Minor: number of the current minor version of the format. Current value is 0. +Options: optionally, a list of options (formatted according to the rules defined in ) can be present. + + +Aside form the options defined in , the following options are valid within this block: + + + Name + Code + Length + Description + + Hardware + 2 + variable + An ascii string containing the description of the hardware used to create this section. + + Operating System + 3 + variable + An ascii string containing the name of the operating system used to create this section. + + User Application + 3 + variable + An ascii string containing the name of the application used to create this section. + + + +The Section Header Block does not contain data but it rather identifies a list of blocks (interfaces, packets) that are logically correlated. This block does not contain any reference to the size of the section it is currently delimiting, therefore the reader cannot skip a whole section at once. In case a section must be skipped, the user has to repeatedly skip all the blocks contained within it; this makes the parsing of the file slower but it permits to append several capture dumps at the same file. +
+ +
+The Interface Description Block is mandatory. This block is needed to specify the characteristics of the network interface on which the capture has been made. In order to properly associate the captured data to the corresponding interface, the Interface Description Block must be defined before any other block that uses it; therefore, this block is usually placed immediately after the Section Header Block. + +An Interface Description Block is valid only inside the section which it belongs to. The structure of a Interface Description Block is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | LinkType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SnapLen | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The meaning of the fields is: + +Interface ID: a progressive number that identifies uniquely any interface inside current section. Two Interface Description Blocks can have the same Interface ID only if they are in different sections of the file. The Interface ID is referenced by the packet blocks. +LinkType: a value that defines the link layer type of this interface. +SnapLen: maximum number of bytes dumped from each packet. The portion of each packet that exceeds this value will not be stored in the file. +Options: optionally, a list of options (formatted according to the rules defined in ) can be present. + + +In addition to the options defined in , the following options are valid within this block: + + + Name + Code + Length + Description + + if_name + 2 + Variable + Name of the device used to capture data. + + if_IPv4addr + 3 + 8 + Interface network address and netmask. + + if_IPv6addr + 4 + 17 + Interface network address and prefix length (stored in the last byte). + + if_MACaddr + 5 + 6 + Interface Hardware MAC address (48 bits). + + if_EUIaddr + 6 + 8 + Interface Hardware EUI address (64 bits), if available. + + if_speed + 7 + 8 + Interface speed (in bps). + + if_tsaccur + 8 + 1 + Precision of timestamps. If the Most Significant Bit is equal to zero, the remaining bits indicates the accuracy as as a negative power of 10 (e.g. 6 means microsecond accuracy). If the Most Significant Bit is equal to zero, the remaining bits indicates the accuracy as as negative power of 2 (e.g. 10 means 1/1024 of second). If this option is not present, a precision of 10^-6 is assumed. + + if_tzone + 9 + 4 + Time zone for GMT support (TODO: specify better). + + if_flags + 10 + 4 + Interface flags. (TODO: specify better. Possible flags: promiscuous, inbound/outbound, traffic filtered during capture). + + if_filter + 11 + variable + The filter (e.g. "capture only TCP traffic") used to capture traffic. The first byte of the Option Data keeps a code of the filter used (e.g. if this is a libpcap string, or BPF bytecode, and more). More details about this format will be presented in Appendix XXX (TODO). + + if_opersystem + 12 + variable + An ascii string containing the name of the operating system of the machine that hosts this interface. This can be different from the same information that can be contained by the Section Header Block () because the capture can have been done on a remote machine. + + + +
+ + + +
+A Packet Block is the standard container for storing the packets coming from the network. The Packet Block is optional because packets can be stored either by means of this block or the Simple Packet Block, which can be used to speed up dump generation. The format of a packet block is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | Drops Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (High) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (Low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Captured Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Packet Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The Packet Block has the following fields: + + +Interface ID: Specifies the interface this packet comes from, and corresponds to the ID of one of the Interface Description Blocks present in this section of the file (see ). +Drops Count: a local drop counter. It specified the number of packets lost (by the interface and the operating system) between this packet and the preceding one. The value xFFFF (in hexadecimal) is reserved for those systems in which this information is not available. +Timestamp (High): the most significative part of the timestamp. in standard Unix format, i.e. from 1/1/1970. +Timestamp (Low): the less significative part of the timestamp. The way to interpret this field is specified by the 'ts_accur' option (see ) of the Interface Description block referenced by this packet. If the Interface Description block does not contain a 'ts_accur' option, then this field is expressed in microseconds. +Captured Len: number of bytes captured from the packet (i.e. the length of the Packet Data field). It will be the minimum value among the actual Packet Length and the snapshot length (defined in ). +Packet Len: actual length of the packet when it was transmitted on the network. Can be different from Captured Len if the user wants only a snapshot of the packet. +Packet Data: the data coming from the network, including link-layer headers. The length of this field is Captured Len. The format of the link-layer headers depends on the LinkType field specified in the Interface Description Block (see ) and it is specified in Appendix XXX (TODO). +Options: optionally, a list of options (formatted according to the rules defined in ) can be present. + + + +
+ + +
+The Simple Packet Block is a lightweight container for storing the packets coming from the network. Its presence is optional. +A Simple Packet Block is similar to a Packet Block (see ), but it is smaller, simpler to process and contains only a minimal set of information. This block is preferred to the standard Packet Block when performance or space occupation are critical factors, such as in sustained traffic dump applications. A capture file can contain both Packet Blocks and Simple Packet Blocks: for example, a capture tool could switch from Packet Blocks to Simple Packet Blocks when the hardware resources become critical. +The Simple Packet Block does not contain the Interface ID field. Therefore, it must be assumed that all the Simple Packet Blocks have been captured on the interface previously specified in the Interface Description Block. + shows the format of the Simple Packet Block. + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Packet Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The Packet Block has the following fields: + +Packet Len: actual length of the packet when it was transmitted on the network. Can be different from captured len if the packet has been truncated. +Packet data: the data coming from the network, including link-layers headers. The length of this field can be derived from the field Block Total Length, present in the Block Header. + + +The Simple Packet Block does not contain the timestamp because this is one of the most costly operations on PCs. Additionally, there are applications that do not require it; e.g. an Intrusion Detection System is interested in packets, not in their timestamp. + +The Simple Packet Block is very efficient in term of disk space: a snapshot of length 100 bytes requires only 16 bytes of overhead, which corresponds to an efficiency of more than 86%. + +
+ + + +
+The Name Resolution Block is used to support the correlation of numeric addresses (present in the captured packets) and their corresponding canonical names and it is optional. Having the literal names saved in the file, this prevents the need of a name resolution in a delayed time, when the association between names and addresses can be different from the one in use at capture time. Moreover, The Name Resolution Block avoids the need of issuing a lot of DNS requests every time the trace capture is opened, and allows to have name resolution also when reading the capture with a machine not connected to the network. +The format of the Name Resolution Block is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Record Type | Record Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Record Value | + | /* variable length, byte-aligned */ | + | + + + + + + + + + + + + + + + + + + + + + + + + + + | | | | | + +-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + + + + + + . . . other records . . . + | Record Type == end_of_recs | Record Length == 00 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +A Name Resolution Block is a zero-terminated list of records (in the TLV format), each of which contains an association between a network address and a name. There are three possible types of records: + + + Name + Code + Length + Description + + end_of_recs + 0 + 0 + End of records + + ip4_rec + 1 + Variable + Specifies an IPv4 address (contained in the first 4 bytes), followed by one or more zero-terminated strings containing the DNS entries for that address. + + ip6_rec + 1 + Variable + Specifies an IPv6 address (contained in the first 16 bytes), followed by one or more zero-terminated strings containing the DNS entries for that address. + + +After the list or Name Resolution Records, optionally, a list of options (formatted according to the rules defined in ) can be present. + +A Name Resolution Block is normally placed at the beginning of the file, but no assumptions can be taken about its position. Name Resolution Blocks can be added in a second time by tools that process the file, like network analyzers. + +In addiction to the options defined in , the following options are valid within this block: + + + Name + Code + Length + Description + + ns_dnsname + 2 + Variable + An ascii string containing the name of the machine (DNS server) used to perform the name resolution. + + +
+ + +
+The Interface Statistics Block contains the capture statistics for a given interface and it is optional. The statistics are referred to the interface defined in the current Section identified by the Interface ID field. +The format of the Interface Statistics Block is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IfRecv | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IfDrop | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FilterAccept | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OSDrop | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | UsrDelivered | + | (high + low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The fields have the following meaning: + + +IfRecv: number of packets received from the interface during the capture. This number is reported as a 64 bits value, in which the most significat bits are located in the first four bytes of the field. +IfDrop: number of packets dropped by the interface during the capture due to lack of resources. +FilterAccept: number of packets accepeted by filter during current capture. +OSDrop: number of packets dropped by the operating system during the capture. +UsrDelivered: number of packets delivered to the user. UsrDelivered can be different from the value 'FilterAccept - OSDropped' because some packets could still lay in the OS buffers when the capture ended. +Interface ID: reference to an Interface Description Block. +Reserved: Reserved to future use. +Options: optionally, a list of options (formatted according to the rules defined in ) can be present. + + +In addiction to the options defined in , the following options are valid within this block: + + + Name + Code + Length + Description + + isb_starttime + 2 + 8 + Time in which the capture started; time will be stored in two blocks of four bytes each, containing the timestamp in seconds and nanoseconds. + + isb_endtime + 3 + 8 + Time in which the capture started; time will be stored in two blocks of four bytes each, containing the timestamp in seconds and nanoseconds. + + +
+
+ + + +
+Almost all blocks have the possibility to embed optional fields. Optional fields can be used to insert some information that may be useful when reading data, but that it is not really needed for packet processing. Therefore, each tool can be either read the content of the optional fields (if any), or skip them at once. +Skipping all the optional fields at once is straightforward because most of the blocks have a fixed length, therefore the field Block Length (present in the General Block Structure, see ) can be used to skip everything till the next block. + +Options are a list of Type - Length - Value fields, each one containing a single value: + + +Option Type (2 bytes): it contains the code that specifies the type of the current TLV record. Option types whose Most Significant Bit is equal to one are reserved for local use; therefore, there is no guarantee that the code used is unique among all capture files (generated by other applications). In case of vendor-specific extensions that have to be identified uniquely, vendors must request an Option Code whose MSB is equal to zero. +Option Length (2 bytes): it contains the length of the following 'Option Value' field. +Option Value (variable length): it contains the value of the given option. The length of this field as been specified by the Option Length field. + + +Options may be repeated several times (e.g. an interface that has several IP addresses associated to it). The option list is terminated by a special code which is the 'End of Option'. + +The format of the optional fields is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Code | Option Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Value | + | /* variable length, byte-aligned */ | + | + + + + + + + + + + + + + + + + + + + + + + + + + + | / / / | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / . . . other options . . . / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Code == opt_endofopt | Option Length == 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The following codes can always be present in any optional field: + + + Name + Code + Length + Description + + opt_endofopt + 0 + 0 + End of options: it is used to delimit the end of the optional fields. This block cannot be repeated within a given list of options. + + opt_comment + 1 + variable + Comment: it is an ascii string containing a comment that is associated to the current block. + + +
+ + + + +
+ +
+Can some other packet blocks (besides the two described in the previous paragraphs) be useful? +
+ +
+The Compression Block is optional. A file can contain an arbitrary number of these blocks. A Compression Block, as the name says, is used to store compressed data. Its format is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Compr. Type | | + +-+-+-+-+-+-+-+-+ | + | | + | Compressed Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The fields have the following meaning: + + +Compression Type: specifies the compression algorithm. Possible values for this field are 0 (uncompressed), 1 (Lempel Ziv), 2 (Gzip), other?? Probably some kind of dumb and fast compression algorithm could be effective with some types of traffic (for example web), but which? +Compressed Data: data of this block. Once decompressed, it is made of other blocks. + + +
+ + +
+The Encryption Block is optional. A file can contain an arbitrary number of these blocks. An Encryption Block is used to sotre encrypted data. Its format is shown in . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encr. Type | | + +-+-+-+-+-+-+-+-+ | + | | + | Compressed Data | + | | + | /* variable length, byte-aligned */ | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The fields have the following meaning: + +Compression Type: specifies the encryption algorithm. Possible values for this field are ??? NOTE: this block should probably contain other fields, depending on the encryption algorithm. To be define precisely. +Encrypted Data: data of this block. Once decripted, it consists of other blocks. + + +
+ + +
+The Fixed Length Block is optional. A file can contain an arbitrary number of these blocks. A Fixed Length Block can be used to optimize the access to the file. Its format is shown in . +A Fixed Length Block stores records with constant size. It contains a set of Blocks (normally Packet Blocks or Simple Packet Blocks), of wihich it specifies the size. Knowing this size a priori helps to scan the file and to load some portions of it without truncating a block, and is particularly useful with cell-based networks like ATM. + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cell Size | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + | Fixed Size Data | + | | + | /* variable length, byte-aligned */ | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +The fields have the following meaning: + +Cell size: the size of the blocks contained in the data field. +Fixed Size Data: data of this block. + + +
+ +
+If present, this block contains the following information: + +number of indexed packets (N) +table with position and length of any indexed packet (N entries) + + +A directory block must be followed by at least N packets, otherwise it must be considered invalid. It can be used to efficiently load portions of the file to memory and to support operations on memory mapped files. This block can be added by tools like network analyzers as a consequence of file processing. +
+ +
+One or more blocks could be defined to contain network statistics or traffic monitoring information. They could be use to store data collected from RMON or Netflow probes, or from other network monitoring tools. +
+ +
+This block could be used to store events. Events could contain generic information (for example network load over 50%, server down...) or security alerts. An event could be: + + +skipped, if the application doesn't know how to do with it +processed independently by the packets. In other words, the applications skips the packets and processes only the alerts +processed in relation to packets: for example, a security tool could load only the packets of the file that are near a security alert; a monitorg tool could skip the packets captured while the server was down. + + +
+ +
+ + + + +
+The file format proposed in this document should be very versatile and satisfy a wide range of applications. +In the simplest case, it can contain a raw dump of the network data, made of a series of Simple Packet Blocks. +In the most complex case, it can be used as a repository for heterogeneous information. +In every case, the file remains easy to parse and an application can always skip the data it is not interested in; at the same time, different applications can share the file, and each of them can benfit of the information produced by the others. +Two or more files can be concatenated obtaining another valid file. +
+ + +
+ +Data, in the file, must be byte or word aligned? Currently, the structure of this document is not consistent with respect to this point. + +
+ + + + diff --git a/contrib/libpcap/ethertype.h b/contrib/libpcap/ethertype.h index f2589361ddfe..2d21c6d9cc01 100644 --- a/contrib/libpcap/ethertype.h +++ b/contrib/libpcap/ethertype.h @@ -18,7 +18,7 @@ * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. * - * @(#) $Header: /tcpdump/master/libpcap/ethertype.h,v 1.13 2004/06/16 08:20:28 hannes Exp $ (LBL) + * @(#) $Header: /tcpdump/master/libpcap/ethertype.h,v 1.13.2.1 2005/09/05 09:08:03 guy Exp $ (LBL) */ /* @@ -108,6 +108,12 @@ #ifndef ETHERTYPE_MPLS_MULTI #define ETHERTYPE_MPLS_MULTI 0x8848 #endif +#ifndef ETHERTYPE_PPPOED +#define ETHERTYPE_PPPOED 0x8863 +#endif +#ifndef ETHERTYPE_PPPOES +#define ETHERTYPE_PPPOES 0x8864 +#endif #ifndef ETHERTYPE_LOOPBACK #define ETHERTYPE_LOOPBACK 0x9000 #endif diff --git a/contrib/libpcap/fad-win32.c b/contrib/libpcap/fad-win32.c index 91b0ef954439..8144fbb822a4 100644 --- a/contrib/libpcap/fad-win32.c +++ b/contrib/libpcap/fad-win32.c @@ -32,7 +32,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/fad-win32.c,v 1.11 2005/01/29 00:52:22 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/fad-win32.c,v 1.11.2.1 2005/09/01 22:07:41 risso Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -224,12 +224,22 @@ pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf) ULONG NameLength; char *name; - PacketGetAdapterNames(NULL, &NameLength); + if(!PacketGetAdapterNames(NULL, &NameLength) && NameLength == 0) + { + /* + * If PacketGetAdapterNames *and* sets the lenght of the buffer to zero, + * it means there was an error. + */ + snprintf(errbuf, PCAP_ERRBUF_SIZE, "PacketGetAdapterNames failed: %s", pcap_win32strerror()); + *alldevsp = NULL; + return -1; + } if (NameLength > 0) AdaptersName = (char*) malloc(NameLength); else { + snprintf(errbuf, PCAP_ERRBUF_SIZE, "no adapters found."); *alldevsp = NULL; return 0; } diff --git a/contrib/libpcap/gencode.c b/contrib/libpcap/gencode.c index 33ad950a8db6..86721719b874 100644 --- a/contrib/libpcap/gencode.c +++ b/contrib/libpcap/gencode.c @@ -21,7 +21,7 @@ */ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/gencode.c,v 1.221.2.24 2005/06/20 21:52:53 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/gencode.c,v 1.221.2.34 2005/09/05 09:08:04 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -100,8 +100,8 @@ static const char rcsid[] _U_ = static jmp_buf top_ctx; static pcap_t *bpf_pcap; -/* Hack for updating VLAN, MPLS offsets. */ -static u_int orig_linktype = -1U, orig_nl = -1U; +/* Hack for updating VLAN, MPLS, and PPPoE offsets. */ +static u_int orig_linktype = -1U, orig_nl = -1U, label_stack_depth = -1U; /* XXX */ #ifdef PCAP_FDDIPAD @@ -205,6 +205,7 @@ static struct block *gen_thostop(const u_char *, int); static struct block *gen_wlanhostop(const u_char *, int); static struct block *gen_ipfchostop(const u_char *, int); static struct block *gen_dnhostop(bpf_u_int32, int); +static struct block *gen_mpls_linktype(int); static struct block *gen_host(bpf_u_int32, bpf_u_int32, int, int); #ifdef INET6 static struct block *gen_host6(struct in6_addr *, struct in6_addr *, int, int); @@ -778,6 +779,9 @@ init_linktype(p) off_proto = -1; off_payload = -1; + /* + * And assume we're not doing SS7. + */ off_sio = -1; off_opc = -1; off_dpc = -1; @@ -790,6 +794,7 @@ init_linktype(p) orig_linktype = -1; orig_nl = -1; + label_stack_depth = 0; reg_ll_size = -1; @@ -1113,8 +1118,12 @@ init_linktype(p) off_nl_nosnap = PFLOG_HDRLEN; /* no 802.2 LLC */ return; + case DLT_JUNIPER_MFR: case DLT_JUNIPER_MLFR: case DLT_JUNIPER_MLPPP: + case DLT_JUNIPER_PPP: + case DLT_JUNIPER_CHDLC: + case DLT_JUNIPER_FRELAY: off_linktype = 4; off_nl = 4; off_nl_nosnap = -1; /* no 802.2 LLC */ @@ -1135,6 +1144,7 @@ init_linktype(p) /* frames captured on a Juniper PPPoE service PIC * contain raw ethernet frames */ case DLT_JUNIPER_PPPOE: + case DLT_JUNIPER_ETHER: off_linktype = 16; off_nl = 18; /* Ethernet II */ off_nl_nosnap = 21; /* 802.3+802.2 */ @@ -1851,6 +1861,25 @@ gen_linktype(proto) { struct block *b0, *b1, *b2; + /* are we checking MPLS-encapsulated packets? */ + if (label_stack_depth > 0) { + switch (proto) { + case ETHERTYPE_IP: + case PPP_IP: + /* FIXME add other L3 proto IDs */ + return gen_mpls_linktype(Q_IP); + + case ETHERTYPE_IPV6: + case PPP_IPV6: + /* FIXME add other L3 proto IDs */ + return gen_mpls_linktype(Q_IPV6); + + default: + bpf_error("unsupported protocol over mpls"); + /* NOTREACHED */ + } + } + switch (linktype) { case DLT_EN10MB: @@ -2240,6 +2269,7 @@ gen_linktype(proto) /*NOTREACHED*/ break; + case DLT_JUNIPER_MFR: case DLT_JUNIPER_MLFR: case DLT_JUNIPER_MLPPP: case DLT_JUNIPER_ATM1: @@ -2250,6 +2280,10 @@ gen_linktype(proto) case DLT_JUNIPER_ES: case DLT_JUNIPER_MONITOR: case DLT_JUNIPER_SERVICES: + case DLT_JUNIPER_ETHER: + case DLT_JUNIPER_PPP: + case DLT_JUNIPER_FRELAY: + case DLT_JUNIPER_CHDLC: /* just lets verify the magic number for now - * on ATM we may have up to 6 different encapsulations on the wire * and need a lot of heuristics to figure out that the payload @@ -3034,6 +3068,40 @@ gen_dnhostop(addr, dir) return b1; } +/* + * Generate a check for IPv4 or IPv6 for MPLS-encapsulated packets; + * test the bottom-of-stack bit, and then check the version number + * field in the IP header. + */ +static struct block * +gen_mpls_linktype(proto) + int proto; +{ + struct block *b0, *b1; + + switch (proto) { + + case Q_IP: + /* match the bottom-of-stack bit */ + b0 = gen_mcmp(OR_NET, -2, BPF_B, 0x01, 0x01); + /* match the IPv4 version number */ + b1 = gen_mcmp(OR_NET, 0, BPF_B, 0x40, 0xf0); + gen_and(b0, b1); + return b1; + + case Q_IPV6: + /* match the bottom-of-stack bit */ + b0 = gen_mcmp(OR_NET, -2, BPF_B, 0x01, 0x01); + /* match the IPv4 version number */ + b1 = gen_mcmp(OR_NET, 0, BPF_B, 0x60, 0xf0); + gen_and(b0, b1); + return b1; + + default: + abort(); + } +} + static struct block * gen_host(addr, mask, proto, dir) bpf_u_int32 addr; @@ -3047,11 +3115,15 @@ gen_host(addr, mask, proto, dir) case Q_DEFAULT: b0 = gen_host(addr, mask, Q_IP, dir); - if (off_linktype != (u_int)-1) { - b1 = gen_host(addr, mask, Q_ARP, dir); - gen_or(b0, b1); - b0 = gen_host(addr, mask, Q_RARP, dir); - gen_or(b1, b0); + /* + * Only check for non-IPv4 addresses if we're not + * checking MPLS-encapsulated packets. + */ + if (label_stack_depth == 0) { + b1 = gen_host(addr, mask, Q_ARP, dir); + gen_or(b0, b1); + b0 = gen_host(addr, mask, Q_RARP, dir); + gen_or(b1, b0); } return b0; @@ -4393,6 +4465,7 @@ gen_proto(v, proto, dir) * * So we always check for ETHERTYPE_IP. */ + b0 = gen_linktype(ETHERTYPE_IP); #ifndef CHASE_CHAIN b1 = gen_cmp(OR_NET, 9, BPF_B, (bpf_int32)v); @@ -5983,6 +6056,7 @@ gen_inbound(dir) } break; + case DLT_JUNIPER_MFR: case DLT_JUNIPER_MLFR: case DLT_JUNIPER_MLPPP: case DLT_JUNIPER_ATM1: @@ -5993,6 +6067,10 @@ gen_inbound(dir) case DLT_JUNIPER_ES: case DLT_JUNIPER_MONITOR: case DLT_JUNIPER_SERVICES: + case DLT_JUNIPER_ETHER: + case DLT_JUNIPER_PPP: + case DLT_JUNIPER_FRELAY: + case DLT_JUNIPER_CHDLC: /* juniper flags (including direction) are stored * the byte after the 3-byte magic number */ if (dir) { @@ -6036,7 +6114,7 @@ gen_pf_ifname(const char *ifname) return (b0); } -/* PF firewall log matched interface */ +/* PF firewall log ruleset name */ struct block * gen_pf_ruleset(char *ruleset) { @@ -6175,7 +6253,11 @@ struct block * gen_vlan(vlan_num) int vlan_num; { - struct block *b0; + struct block *b0, *b1; + + /* can't check for VLAN-encapsulated packets inside MPLS */ + if (label_stack_depth > 0) + bpf_error("no VLAN match after MPLS"); /* * Change the offsets to point to the type and data fields within @@ -6207,30 +6289,28 @@ gen_vlan(vlan_num) * be done assuming a VLAN, even though the "or" could be viewed * as meaning "or, if this isn't a VLAN packet...". */ - orig_linktype = off_linktype; /* save original values */ - orig_nl = off_nl; + orig_linktype = off_linktype; /* save original values */ + orig_nl = off_nl; - switch (linktype) { + switch (linktype) { - case DLT_EN10MB: - off_linktype += 4; - off_nl_nosnap += 4; - off_nl += 4; - break; + case DLT_EN10MB: + off_linktype += 4; + off_nl_nosnap += 4; + off_nl += 4; + break; - default: - bpf_error("no VLAN support for data link type %d", - linktype); - /*NOTREACHED*/ - } + default: + bpf_error("no VLAN support for data link type %d", + linktype); + /*NOTREACHED*/ + } /* check for VLAN */ b0 = gen_cmp(OR_LINK, orig_linktype, BPF_H, (bpf_int32)ETHERTYPE_8021Q); /* If a specific VLAN is requested, check VLAN id */ if (vlan_num >= 0) { - struct block *b1; - b1 = gen_mcmp(OR_LINK, orig_nl, BPF_H, (bpf_int32)vlan_num, 0x0fff); gen_and(b0, b1); @@ -6247,7 +6327,7 @@ struct block * gen_mpls(label_num) int label_num; { - struct block *b0; + struct block *b0,*b1; /* * Change the offsets to point to the type and data fields within @@ -6258,44 +6338,46 @@ gen_mpls(label_num) * * XXX - this is a bit of a kludge. See comments in gen_vlan(). */ - orig_linktype = off_linktype; /* save original values */ orig_nl = off_nl; - switch (linktype) { - - case DLT_C_HDLC: /* fall through */ - case DLT_EN10MB: - off_nl_nosnap += 4; - off_nl += 4; - - b0 = gen_cmp(OR_LINK, orig_linktype, BPF_H, - (bpf_int32)ETHERTYPE_MPLS); - break; - - case DLT_PPP: - off_nl_nosnap += 4; - off_nl += 4; - - b0 = gen_cmp(OR_LINK, orig_linktype, BPF_H, - (bpf_int32)PPP_MPLS_UCAST); - break; - - /* FIXME add other DLT_s ... - * for Frame-Relay/and ATM this may get messy due to SNAP headers - * leave it for now */ - - default: - bpf_error("no MPLS support for data link type %d", + if (label_stack_depth > 0) { + /* just match the bottom-of-stack bit clear */ + b0 = gen_mcmp(OR_LINK, orig_nl-2, BPF_B, 0, 0x01); + } else { + /* + * Indicate that we're checking MPLS-encapsulated headers, + * to make sure higher level code generators don't try to + * match against IP-related protocols such as Q_ARP, Q_RARP + * etc. + */ + switch (linktype) { + + case DLT_C_HDLC: /* fall through */ + case DLT_EN10MB: + b0 = gen_cmp(OR_LINK, off_linktype, BPF_H, + (bpf_int32)ETHERTYPE_MPLS); + break; + + case DLT_PPP: + b0 = gen_cmp(OR_LINK, off_linktype, BPF_H, + (bpf_int32)PPP_MPLS_UCAST); + break; + + /* FIXME add other DLT_s ... + * for Frame-Relay/and ATM this may get messy due to SNAP headers + * leave it for now */ + + default: + bpf_error("no MPLS support for data link type %d", linktype); - b0 = NULL; - /*NOTREACHED*/ - break; + b0 = NULL; + /*NOTREACHED*/ + break; + } } /* If a specific MPLS label is requested, check it */ if (label_num >= 0) { - struct block *b1; - label_num = label_num << 12; /* label is shifted 12 bits on the wire */ b1 = gen_mcmp(OR_LINK, orig_nl, BPF_W, (bpf_int32)label_num, 0xfffff000); /* only compare the first 20 bits */ @@ -6303,9 +6385,84 @@ gen_mpls(label_num) b0 = b1; } + off_nl_nosnap += 4; + off_nl += 4; + label_stack_depth++; return (b0); } +/* + * Support PPPOE discovery and session. + */ +struct block * +gen_pppoed() +{ + /* check for PPPoE discovery */ + return gen_linktype((bpf_int32)ETHERTYPE_PPPOED); +} + +struct block * +gen_pppoes() +{ + struct block *b0; + + /* + * Test against the PPPoE session link-layer type. + */ + b0 = gen_linktype((bpf_int32)ETHERTYPE_PPPOES); + + /* + * Change the offsets to point to the type and data fields within + * the PPP packet. + * + * XXX - this is a bit of a kludge. If we were to split the + * compiler into a parser that parses an expression and + * generates an expression tree, and a code generator that + * takes an expression tree (which could come from our + * parser or from some other parser) and generates BPF code, + * we could perhaps make the offsets parameters of routines + * and, in the handler for an "AND" node, pass to subnodes + * other than the PPPoE node the adjusted offsets. + * + * This would mean that "pppoes" would, instead of changing the + * behavior of *all* tests after it, change only the behavior + * of tests ANDed with it. That would change the documented + * semantics of "pppoes", which might break some expressions. + * However, it would mean that "(pppoes and ip) or ip" would check + * both for VLAN-encapsulated IP and IP-over-Ethernet, rather than + * checking only for VLAN-encapsulated IP, so that could still + * be considered worth doing; it wouldn't break expressions + * that are of the form "pppoes and ..." which I suspect are the + * most common expressions involving "pppoes". "pppoes or ..." + * doesn't necessarily do what the user would really want, now, + * as all the "or ..." tests would be done assuming PPPoE, even + * though the "or" could be viewed as meaning "or, if this isn't + * a PPPoE packet...". + */ + orig_linktype = off_linktype; /* save original values */ + orig_nl = off_nl; + + /* + * The "network-layer" protocol is PPPoE, which has a 6-byte + * PPPoE header, followed by PPP payload, so we set the + * offsets to the network layer offset plus 6 bytes for + * the PPPoE header plus the values appropriate for PPP when + * encapsulated in Ethernet (which means there's no HDLC + * encapsulation). + */ + off_linktype = orig_nl + 6; + off_nl = orig_nl + 6 + 2; + off_nl_nosnap = orig_nl + 6 + 2; + + /* + * Set the link-layer type to PPP, as all subsequent tests will + * be on the encapsulated PPP header. + */ + linktype = DLT_PPP; + + return b0; +} + struct block * gen_atmfield_code(atmfield, jvalue, jtype, reverse) int atmfield; diff --git a/contrib/libpcap/gencode.h b/contrib/libpcap/gencode.h index 56f3257dc7e3..5abc2514125a 100644 --- a/contrib/libpcap/gencode.h +++ b/contrib/libpcap/gencode.h @@ -18,7 +18,7 @@ * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. * - * @(#) $Header: /tcpdump/master/libpcap/gencode.h,v 1.60.2.5 2005/06/20 21:30:17 guy Exp $ (LBL) + * @(#) $Header: /tcpdump/master/libpcap/gencode.h,v 1.60.2.6 2005/09/05 09:08:06 guy Exp $ (LBL) */ /* @@ -289,6 +289,9 @@ struct block *gen_inbound(int); struct block *gen_vlan(int); struct block *gen_mpls(int); +struct block *gen_pppoed(void); +struct block *gen_pppoes(void); + struct block *gen_atmfield_code(int atmfield, bpf_int32 jvalue, bpf_u_int32 jtype, int reverse); struct block *gen_atmtype_abbrev(int type); struct block *gen_atmmulti_abbrev(int type); diff --git a/contrib/libpcap/grammar.y b/contrib/libpcap/grammar.y index 19691869dafc..c2f96f144ce2 100644 --- a/contrib/libpcap/grammar.y +++ b/contrib/libpcap/grammar.y @@ -22,7 +22,7 @@ */ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/grammar.y,v 1.86.2.4 2005/06/20 21:30:17 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/grammar.y,v 1.86.2.5 2005/09/05 09:08:06 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -131,6 +131,7 @@ pcap_parse() %token LEN %token IPV6 ICMPV6 AH ESP %token VLAN MPLS +%token PPPOED PPPOES %token ISO ESIS CLNP ISIS L1 L2 IIH LSP SNP CSNP PSNP %token STP %token IPX @@ -333,6 +334,8 @@ other: pqual TK_BROADCAST { $$ = gen_broadcast($1); } | VLAN { $$ = gen_vlan(-1); } | MPLS pnum { $$ = gen_mpls($2); } | MPLS { $$ = gen_mpls(-1); } + | PPPOED { $$ = gen_pppoed(); } + | PPPOES { $$ = gen_pppoes(); } | pfvar { $$ = $1; } ; diff --git a/contrib/libpcap/pcap-bpf.c b/contrib/libpcap/pcap-bpf.c index 4a94cda6219a..97bd6027685e 100644 --- a/contrib/libpcap/pcap-bpf.c +++ b/contrib/libpcap/pcap-bpf.c @@ -20,7 +20,7 @@ */ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/pcap-bpf.c,v 1.86.2.4 2005/06/04 02:53:16 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/pcap-bpf.c,v 1.86.2.8 2005/07/10 10:55:31 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -105,7 +105,7 @@ static int odmlockid = 0; #include "gencode.h" /* for "no_optimize" */ static int pcap_setfilter_bpf(pcap_t *p, struct bpf_program *fp); -static int pcap_setdirection_bpf(pcap_t *, direction_t); +static int pcap_setdirection_bpf(pcap_t *, pcap_direction_t); static int pcap_set_datalink_bpf(pcap_t *p, int dlt); static int @@ -746,7 +746,7 @@ pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, u_int i; int is_ethernet; - bdl.bfl_list = (u_int *) malloc(sizeof(u_int) * (bdl.bfl_len + 1)); + bdl.bfl_list = (u_int *) malloc(sizeof(u_int) * bdl.bfl_len + 1); if (bdl.bfl_list == NULL) { (void)snprintf(ebuf, PCAP_ERRBUF_SIZE, "malloc: %s", pcap_strerror(errno)); @@ -997,9 +997,6 @@ pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, * there (and in sufficiently recent versions of OpenBSD * "select()" and "poll()" should work correctly). * - * In addition, in Mac OS X 10.4, "select()" and "poll()" don't - * work on *any* character devices, including BPF devices. - * * XXX - what about AIX? */ p->selectable_fd = p->fd; /* assume select() works until we know otherwise */ @@ -1011,9 +1008,6 @@ pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, if (strncmp(osinfo.release, "4.3-", 4) == 0 || strncmp(osinfo.release, "4.4-", 4) == 0) p->selectable_fd = -1; - } else if (strcmp(osinfo.sysname, "Darwin") == 0) { - if (strncmp(osinfo.release, "8.", 2) == 0) - p->selectable_fd = -1; } } @@ -1095,26 +1089,26 @@ pcap_setfilter_bpf(pcap_t *p, struct bpf_program *fp) * single device? IN, OUT or both? */ static int -pcap_setdirection_bpf(pcap_t *p, direction_t d) +pcap_setdirection_bpf(pcap_t *p, pcap_direction_t d) { #ifdef BIOCSSEESENT u_int seesent; #endif /* - * We don't support D_OUT. + * We don't support PCAP_D_OUT. */ - if (d == D_OUT) { + if (d == PCAP_D_OUT) { snprintf(p->errbuf, sizeof(p->errbuf), - "Setting direction to D_OUT is not supported on BPF"); + "Setting direction to PCAP_D_OUT is not supported on BPF"); return -1; } #ifdef BIOCSSEESENT - seesent = (d == D_INOUT); + seesent = (d == PCAP_D_INOUT); if (ioctl(p->fd, BIOCSSEESENT, &seesent) == -1) { (void) snprintf(p->errbuf, sizeof(p->errbuf), "Cannot set direction to %s: %s", - (d == D_INOUT) ? "D_INOUT" : "D_IN", + (d == PCAP_D_INOUT) ? "PCAP_D_INOUT" : "PCAP_D_IN", strerror(errno)); return (-1); } diff --git a/contrib/libpcap/pcap-bpf.h b/contrib/libpcap/pcap-bpf.h index 9811613a3a8f..764f12be09ff 100644 --- a/contrib/libpcap/pcap-bpf.h +++ b/contrib/libpcap/pcap-bpf.h @@ -37,7 +37,7 @@ * * @(#)bpf.h 7.1 (Berkeley) 5/7/91 * - * @(#) $Header: /tcpdump/master/libpcap/pcap-bpf.h,v 1.34.2.5 2005/05/27 23:33:00 guy Exp $ (LBL) + * @(#) $Header: /tcpdump/master/libpcap/pcap-bpf.h,v 1.34.2.6 2005/08/13 22:29:47 hannes Exp $ (LBL) */ /* @@ -593,6 +593,18 @@ struct bpf_version { */ #define DLT_LINUX_LAPD 177 +/* + * Juniper-private data link type, as per request from + * Hannes Gredler . + * The DLT_ are used for prepending meta-information + * like interface index, interface name + * before standard Ethernet, PPP, Frelay & C-HDLC Frames + */ +#define DLT_JUNIPER_ETHER 178 +#define DLT_JUNIPER_PPP 179 +#define DLT_JUNIPER_FRELAY 180 +#define DLT_JUNIPER_CHDLC 181 + /* * The instruction encodings. */ diff --git a/contrib/libpcap/pcap-dag.c b/contrib/libpcap/pcap-dag.c index 058785658937..ee482836a8e3 100644 --- a/contrib/libpcap/pcap-dag.c +++ b/contrib/libpcap/pcap-dag.c @@ -10,12 +10,14 @@ * called as required from their pcap-linux/bpf equivalents. * * Authors: Richard Littin, Sean Irvine ({richard,sean}@reeltwo.com) - * Modifications: Jesper Peterson, Koryn Grant + * Modifications: Jesper Peterson + * Koryn Grant + * Stephen Donnelly */ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/pcap-dag.c,v 1.21.2.1 2005/05/03 18:54:35 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/pcap-dag.c,v 1.21.2.3 2005/07/10 22:09:34 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -123,24 +125,24 @@ delete_pcap_dag(pcap_t *p) static void dag_platform_close(pcap_t *p) { - -#ifdef linux - if (p != NULL && p->md.device != NULL) { - if(dag_stop(p->fd) < 0) - fprintf(stderr,"dag_stop %s: %s\n", p->md.device, strerror(errno)); - if(dag_close(p->fd) < 0) - fprintf(stderr,"dag_close %s: %s\n", p->md.device, strerror(errno)); - - free(p->md.device); - } -#else + if (p != NULL) { +#ifdef HAVE_DAG_STREAMS_API + if(dag_stop_stream(p->fd, p->md.dag_stream) < 0) + fprintf(stderr,"dag_stop_stream: %s\n", strerror(errno)); + + if(dag_detach_stream(p->fd, p->md.dag_stream) < 0) + fprintf(stderr,"dag_detach_stream: %s\n", strerror(errno)); +#else if(dag_stop(p->fd) < 0) fprintf(stderr,"dag_stop: %s\n", strerror(errno)); +#endif /* HAVE_DAG_STREAMS_API */ if(dag_close(p->fd) < 0) fprintf(stderr,"dag_close: %s\n", strerror(errno)); - } +#ifdef linux + free(p->md.device); #endif + } delete_pcap_dag(p); /* Note: don't need to call close(p->fd) here as dag_close(p->fd) does this. */ } @@ -192,118 +194,190 @@ dag_read(pcap_t *p, int cnt, pcap_handler callback, u_char *user) int flags = p->md.dag_offset_flags; unsigned int nonblocking = flags & DAGF_NONBLOCK; - for (;;) - { - /* Get the next bufferful of packets (if necessary). */ - while (p->md.dag_mem_top - p->md.dag_mem_bottom < dag_record_size) { + /* Get the next bufferful of packets (if necessary). */ + while (p->md.dag_mem_top - p->md.dag_mem_bottom < dag_record_size) { + /* + * Has "pcap_breakloop()" been called? + */ + if (p->break_loop) { /* - * Has "pcap_breakloop()" been called? + * Yes - clear the flag that indicates that + * it has, and return -2 to indicate that + * we were told to break out of the loop. */ - if (p->break_loop) { - /* - * Yes - clear the flag that indicates that - * it has, and return -2 to indicate that - * we were told to break out of the loop. - */ - p->break_loop = 0; - return -2; - } - - p->md.dag_mem_top = dag_offset(p->fd, &(p->md.dag_mem_bottom), flags); - if (nonblocking && (p->md.dag_mem_top - p->md.dag_mem_bottom < dag_record_size)) - { - /* Pcap is configured to process only available packets, and there aren't any. */ - return 0; - } + p->break_loop = 0; + return -2; } + +#ifdef HAVE_DAG_STREAMS_API + /* dag_advance_stream() will block (unless nonblock is called) + * until 64kB of data has accumulated. + * If to_ms is set, it will timeout before 64kB has accumulated. + * We wait for 64kB because processing a few packets at a time + * can cause problems at high packet rates (>200kpps) due + * to inefficiencies. + * This does mean if to_ms is not specified the capture may 'hang' + * for long periods if the data rate is extremely slow (<64kB/sec) + * If non-block is specified it will return immediately. The user + * is then responsible for efficiency. + */ + p->md.dag_mem_top = dag_advance_stream(p->fd, p->md.dag_stream, (void**)&(p->md.dag_mem_bottom)); +#else + /* dag_offset does not support timeouts */ + p->md.dag_mem_top = dag_offset(p->fd, &(p->md.dag_mem_bottom), flags); +#endif /* HAVE_DAG_STREAMS_API */ + + if (nonblocking && (p->md.dag_mem_top - p->md.dag_mem_bottom < dag_record_size)) + { + /* Pcap is configured to process only available packets, and there aren't any, return immediately. */ + return 0; + } + + if(!nonblocking && + p->md.dag_timeout && + (p->md.dag_mem_top - p->md.dag_mem_bottom < dag_record_size)) + { + /* Blocking mode, but timeout set and no data has arrived, return anyway.*/ + return 0; + } + + } - /* Process the packets. */ - while (p->md.dag_mem_top - p->md.dag_mem_bottom >= dag_record_size) { + /* Process the packets. */ + while (p->md.dag_mem_top - p->md.dag_mem_bottom >= dag_record_size) { - unsigned short packet_len = 0; - int caplen = 0; - struct pcap_pkthdr pcap_header; + unsigned short packet_len = 0; + int caplen = 0; + struct pcap_pkthdr pcap_header; - dag_record_t *header = (dag_record_t *)(p->md.dag_mem_base + p->md.dag_mem_bottom); - u_char *dp = ((u_char *)header) + dag_record_size; - unsigned short rlen; +#ifdef HAVE_DAG_STREAMS_API + dag_record_t *header = (dag_record_t *)(p->md.dag_mem_bottom); +#else + dag_record_t *header = (dag_record_t *)(p->md.dag_mem_base + p->md.dag_mem_bottom); +#endif /* HAVE_DAG_STREAMS_API */ + + u_char *dp = ((u_char *)header) + dag_record_size; + unsigned short rlen; + /* + * Has "pcap_breakloop()" been called? + */ + if (p->break_loop) { /* - * Has "pcap_breakloop()" been called? + * Yes - clear the flag that indicates that + * it has, and return -2 to indicate that + * we were told to break out of the loop. */ - if (p->break_loop) { - /* - * Yes - clear the flag that indicates that - * it has, and return -2 to indicate that - * we were told to break out of the loop. - */ - p->break_loop = 0; - return -2; - } + p->break_loop = 0; + return -2; + } - rlen = ntohs(header->rlen); - if (rlen < dag_record_size) - { - strncpy(p->errbuf, "dag_read: record too small", PCAP_ERRBUF_SIZE); - return -1; + rlen = ntohs(header->rlen); + if (rlen < dag_record_size) + { + strncpy(p->errbuf, "dag_read: record too small", PCAP_ERRBUF_SIZE); + return -1; + } + p->md.dag_mem_bottom += rlen; + + switch(header->type) { + case TYPE_AAL5: + case TYPE_ATM: +#ifdef TYPE_MC_ATM + case TYPE_MC_ATM: + if (header->type == TYPE_MC_ATM) { + caplen = packet_len = ATM_CELL_SIZE; + dp+=4; } - p->md.dag_mem_bottom += rlen; - - switch(header->type) { - case TYPE_AAL5: - case TYPE_ATM: - if (header->type == TYPE_AAL5) { - packet_len = ntohs(header->wlen); - caplen = rlen - dag_record_size; - } else { - caplen = packet_len = ATM_CELL_SIZE; - } - if (p->linktype == DLT_SUNATM) { - struct sunatm_hdr *sunatm = (struct sunatm_hdr *)dp; - unsigned long rawatm; - - rawatm = ntohl(*((unsigned long *)dp)); - sunatm->vci = htons((rawatm >> 4) & 0xffff); - sunatm->vpi = (rawatm >> 20) & 0x00ff; - sunatm->flags = ((header->flags.iface & 1) ? 0x80 : 0x00) | - ((sunatm->vpi == 0 && sunatm->vci == htons(5)) ? 6 : - ((sunatm->vpi == 0 && sunatm->vci == htons(16)) ? 5 : - ((dp[ATM_HDR_SIZE] == 0xaa && - dp[ATM_HDR_SIZE+1] == 0xaa && - dp[ATM_HDR_SIZE+2] == 0x03) ? 2 : 1))); - - } else { - packet_len -= ATM_HDR_SIZE; - caplen -= ATM_HDR_SIZE; - dp += ATM_HDR_SIZE; - } - break; - - case TYPE_ETH: - packet_len = ntohs(header->wlen); - packet_len -= (p->md.dag_fcs_bits >> 3); - caplen = rlen - dag_record_size - 2; - if (caplen > packet_len) { - caplen = packet_len; - } - dp += 2; - break; - - case TYPE_HDLC_POS: - packet_len = ntohs(header->wlen); - packet_len -= (p->md.dag_fcs_bits >> 3); +#endif +#ifdef TYPE_MC_AAL5 + case TYPE_MC_AAL5: + if (header->type == TYPE_MC_AAL5) { + packet_len = ntohs(header->wlen); + caplen = rlen - dag_record_size - 4; + dp+=4; + } +#endif + if (header->type == TYPE_AAL5) { + packet_len = ntohs(header->wlen); caplen = rlen - dag_record_size; - if (caplen > packet_len) { - caplen = packet_len; - } - break; + } else if(header->type == TYPE_ATM) { + caplen = packet_len = ATM_CELL_SIZE; } - - if (caplen > p->snapshot) - caplen = p->snapshot; + if (p->linktype == DLT_SUNATM) { + struct sunatm_hdr *sunatm = (struct sunatm_hdr *)dp; + unsigned long rawatm; + + rawatm = ntohl(*((unsigned long *)dp)); + sunatm->vci = htons((rawatm >> 4) & 0xffff); + sunatm->vpi = (rawatm >> 20) & 0x00ff; + sunatm->flags = ((header->flags.iface & 1) ? 0x80 : 0x00) | + ((sunatm->vpi == 0 && sunatm->vci == htons(5)) ? 6 : + ((sunatm->vpi == 0 && sunatm->vci == htons(16)) ? 5 : + ((dp[ATM_HDR_SIZE] == 0xaa && + dp[ATM_HDR_SIZE+1] == 0xaa && + dp[ATM_HDR_SIZE+2] == 0x03) ? 2 : 1))); - /* Count lost packets. */ + } else { + packet_len -= ATM_HDR_SIZE; + caplen -= ATM_HDR_SIZE; + dp += ATM_HDR_SIZE; + } + break; + +#ifdef TYPE_COLOR_ETH + case TYPE_COLOR_ETH: +#endif + case TYPE_ETH: + packet_len = ntohs(header->wlen); + packet_len -= (p->md.dag_fcs_bits >> 3); + caplen = rlen - dag_record_size - 2; + if (caplen > packet_len) { + caplen = packet_len; + } + dp += 2; + break; +#ifdef TYPE_COLOR_HDLC_POS + case TYPE_COLOR_HDLC_POS: +#endif + case TYPE_HDLC_POS: + packet_len = ntohs(header->wlen); + packet_len -= (p->md.dag_fcs_bits >> 3); + caplen = rlen - dag_record_size; + if (caplen > packet_len) { + caplen = packet_len; + } + break; +#ifdef TYPE_MC_HDLC + case TYPE_MC_HDLC: + packet_len = ntohs(header->wlen); + packet_len -= (p->md.dag_fcs_bits >> 3); + caplen = rlen - dag_record_size - 4; + if (caplen > packet_len) { + caplen = packet_len; + } + dp += 4; + break; +#endif + } + + if (caplen > p->snapshot) + caplen = p->snapshot; + + /* Count lost packets. */ + switch(header->type) { +#ifdef TYPE_COLOR_HDLC_POS + /* in this type the color value overwrites the lctr */ + case TYPE_COLOR_HDLC_POS: + break; +#endif +#ifdef TYPE_COLOR_ETH + /* in this type the color value overwrites the lctr */ + case TYPE_COLOR_ETH: + break; +#endif + default: if (header->lctr) { if (p->md.stat.ps_drop > (UINT_MAX - ntohs(header->lctr))) { p->md.stat.ps_drop = UINT_MAX; @@ -311,54 +385,49 @@ dag_read(pcap_t *p, int cnt, pcap_handler callback, u_char *user) p->md.stat.ps_drop += ntohs(header->lctr); } } + } - /* Run the packet filter if there is one. */ - if ((p->fcode.bf_insns == NULL) || bpf_filter(p->fcode.bf_insns, dp, packet_len, caplen)) { + /* Run the packet filter if there is one. */ + if ((p->fcode.bf_insns == NULL) || bpf_filter(p->fcode.bf_insns, dp, packet_len, caplen)) { - /* convert between timestamp formats */ - register unsigned long long ts; + /* convert between timestamp formats */ + register unsigned long long ts; - if (IS_BIGENDIAN()) { - ts = SWAP_TS(header->ts); - } else { - ts = header->ts; - } + if (IS_BIGENDIAN()) { + ts = SWAP_TS(header->ts); + } else { + ts = header->ts; + } - pcap_header.ts.tv_sec = ts >> 32; - ts = (ts & 0xffffffffULL) * 1000000; - ts += 0x80000000; /* rounding */ - pcap_header.ts.tv_usec = ts >> 32; - if (pcap_header.ts.tv_usec >= 1000000) { - pcap_header.ts.tv_usec -= 1000000; - pcap_header.ts.tv_sec++; - } + pcap_header.ts.tv_sec = ts >> 32; + ts = (ts & 0xffffffffULL) * 1000000; + ts += 0x80000000; /* rounding */ + pcap_header.ts.tv_usec = ts >> 32; + if (pcap_header.ts.tv_usec >= 1000000) { + pcap_header.ts.tv_usec -= 1000000; + pcap_header.ts.tv_sec++; + } - /* Fill in our own header data */ - pcap_header.caplen = caplen; - pcap_header.len = packet_len; + /* Fill in our own header data */ + pcap_header.caplen = caplen; + pcap_header.len = packet_len; - /* Count the packet. */ - p->md.stat.ps_recv++; + /* Count the packet. */ + p->md.stat.ps_recv++; - /* Call the user supplied callback function */ - callback(user, &pcap_header, dp); + /* Call the user supplied callback function */ + callback(user, &pcap_header, dp); - /* Only count packets that pass the filter, for consistency with standard Linux behaviour. */ - processed++; - if (processed == cnt) - { - /* Reached the user-specified limit. */ - return cnt; - } + /* Only count packets that pass the filter, for consistency with standard Linux behaviour. */ + processed++; + if (processed == cnt) + { + /* Reached the user-specified limit. */ + return cnt; } } - - if (nonblocking || processed) - { - return processed; - } } - + return processed; } @@ -386,7 +455,13 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu char *s; int n; daginf_t* daginf; - + char * newDev; +#ifdef HAVE_DAG_STREAMS_API + uint32_t mindata; + struct timeval maxwait; + struct timeval poll; +#endif + if (device == NULL) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "device is NULL: %s", pcap_strerror(errno)); return NULL; @@ -403,8 +478,23 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu memset(handle, 0, sizeof(*handle)); + newDev = (char *)malloc(strlen(device) + 16); + +#ifdef HAVE_DAG_STREAMS_API + + /* Parse input name to get dag device and stream number if provided */ + if (dag_parse_name(device, newDev, strlen(device) + 16, &handle->md.dag_stream) < 0) { + snprintf(ebuf, PCAP_ERRBUF_SIZE, "dag_parse_name: %s\n", pcap_strerror(errno)); + goto fail; + } + device = newDev; + + if (handle->md.dag_stream%2) { + snprintf(ebuf, PCAP_ERRBUF_SIZE, "dag_parse_name: tx (even numbered) streams not supported for capture\n"); + goto fail; + } +#else if (strstr(device, "/dev") == NULL) { - char * newDev = (char *)malloc(strlen(device) + 6); newDev[0] = '\0'; strcat(newDev, "/dev/"); strcat(newDev,device); @@ -417,6 +507,7 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu snprintf(ebuf, PCAP_ERRBUF_SIZE, "str_dup: %s\n", pcap_strerror(errno)); goto fail; } +#endif /* HAVE_DAG_STREAMS_API */ /* setup device parameters */ if((handle->fd = dag_open((char *)device)) < 0) { @@ -424,6 +515,48 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu goto fail; } +#ifdef HAVE_DAG_STREAMS_API + /* Open requested stream. Can fail if already locked or on error */ + if (dag_attach_stream(handle->fd, handle->md.dag_stream, 0, 0) < 0) { + snprintf(ebuf, PCAP_ERRBUF_SIZE, "dag_attach_stream: %s\n", pcap_strerror(errno)); + goto fail; + } + + /* Set up default poll parameters for stream + * Can be overridden by pcap_set_nonblock() + */ + if (dag_get_stream_poll(handle->fd, handle->md.dag_stream, + &mindata, &maxwait, &poll) < 0) { + snprintf(ebuf, PCAP_ERRBUF_SIZE, "dag_get_stream_poll: %s\n", pcap_strerror(errno)); + goto fail; + } + + /* Amount of data to collect in Bytes before calling callbacks. + * Important for efficiency, but can introduce latency + * at low packet rates if to_ms not set! + */ + mindata = 65536; + + /* Obey to_ms if supplied. This is a good idea! + * Recommend 10-100ms. Calls will time out even if no data arrived. + */ + maxwait.tv_sec = to_ms/1000; + maxwait.tv_usec = (to_ms%1000) * 1000; + + if (dag_set_stream_poll(handle->fd, handle->md.dag_stream, + mindata, &maxwait, &poll) < 0) { + snprintf(ebuf, PCAP_ERRBUF_SIZE, "dag_set_stream_poll: %s\n", pcap_strerror(errno)); + goto fail; + } + +#else + if((handle->md.dag_mem_base = dag_mmap(handle->fd)) == MAP_FAILED) { + snprintf(ebuf, PCAP_ERRBUF_SIZE,"dag_mmap %s: %s\n", device, pcap_strerror(errno)); + goto fail; + } + +#endif /* HAVE_DAG_STREAMS_API */ + /* set the card snap length to the specified snaplen parameter */ if (snaplen == 0 || snaplen > MAX_DAG_SNAPLEN) { snaplen = MAX_DAG_SNAPLEN; @@ -437,16 +570,18 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu snprintf(ebuf, PCAP_ERRBUF_SIZE,"dag_configure %s: %s\n", device, pcap_strerror(errno)); goto fail; } - - if((handle->md.dag_mem_base = dag_mmap(handle->fd)) == MAP_FAILED) { - snprintf(ebuf, PCAP_ERRBUF_SIZE,"dag_mmap %s: %s\n", device, pcap_strerror(errno)); + +#ifdef HAVE_DAG_STREAMS_API + if(dag_start_stream(handle->fd, handle->md.dag_stream) < 0) { + snprintf(ebuf, PCAP_ERRBUF_SIZE, "dag_start_stream %s: %s\n", device, pcap_strerror(errno)); goto fail; } - +#else if(dag_start(handle->fd) < 0) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "dag_start %s: %s\n", device, pcap_strerror(errno)); goto fail; } +#endif /* HAVE_DAG_STREAMS_API */ /* * Important! You have to ensure bottom is properly @@ -477,7 +612,7 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu } handle->snapshot = snaplen; - /*handle->md.timeout = to_ms; */ + handle->md.dag_timeout = to_ms; handle->linktype = -1; if (dag_get_datalink(handle) < 0) { @@ -493,12 +628,13 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu } /* - * "select()" and "poll()" don't (yet) work on DAG device descriptors. + * "select()" and "poll()" don't work on DAG device descriptors. */ handle->selectable_fd = -1; #ifdef linux handle->md.device = (char *)device; + handle->md.timeout = to_ms; #else free((char *)device); device = NULL; @@ -517,8 +653,8 @@ dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebu return handle; fail: - if (device != NULL) { - free((char *)device); + if (newDev != NULL) { + free((char *)newDev); } if (handle != NULL) { /* @@ -547,97 +683,42 @@ dag_stats(pcap_t *p, struct pcap_stat *ps) { } /* - * Get from "/proc/dag" all interfaces listed there; if they're - * already in the list of interfaces we have, that won't add another - * instance, but if they're not, that'll add them. - * - * We don't bother getting any addresses for them. - * - * We also don't fail if we couldn't open "/proc/dag"; we just leave - * the list of interfaces as is. + * Simply submit all possible dag names as candidates. + * pcap_add_if() internally tests each candidate with pcap_open_live(), + * so any non-existent devices are dropped. + * For 2.5 try all rx stream names as well. */ int dag_platform_finddevs(pcap_if_t **devlistp, char *errbuf) { - FILE *proc_dag_f; - char linebuf[512]; - int linenum; - unsigned char *p; - char name[512]; /* XXX - pick a size */ - char *q; + char name[12]; /* XXX - pick a size */ int ret = 0; + int c; - /* Quick exit if /proc/dag not readable */ - proc_dag_f = fopen("/proc/dag", "r"); - if (proc_dag_f == NULL) - { - int i; - char dev[16] = "dagx"; - - for (i = '0'; ret == 0 && i <= '9'; i++) { - dev[3] = i; - if (pcap_add_if(devlistp, dev, 0, NULL, errbuf) == -1) { - /* - * Failure. - */ - ret = -1; - } - } - - return (ret); - } - - for (linenum = 1; fgets(linebuf, sizeof linebuf, proc_dag_f) != NULL; linenum++) { - - /* - * Skip the first two lines - they're headers. - */ - if (linenum <= 2) - continue; - - p = &linebuf[0]; - - if (*p == '\0' || *p == '\n' || *p != 'D') - continue; /* not a Dag line */ - - /* - * Get the interface name. - */ - q = &name[0]; - while (*p != '\0' && *p != ':') { - if (*p != ' ') - *q++ = tolower(*p++); - else - p++; - } - *q = '\0'; - - /* - * Add an entry for this interface, with no addresses. - */ - p[strlen(p) - 1] = '\0'; /* get rid of \n */ - if (pcap_add_if(devlistp, name, 0, strdup(p + 2), errbuf) == -1) { + /* Try all the DAGs 0-9 */ + for (c = 0; c < 9; c++) { + snprintf(name, 12, "dag%d", c); + if (pcap_add_if(devlistp, name, 0, NULL, errbuf) == -1) { /* * Failure. */ ret = -1; - break; } - } - if (ret != -1) { - /* - * Well, we didn't fail for any other reason; did we - * fail due to an error reading the file? - */ - if (ferror(proc_dag_f)) { - (void)snprintf(errbuf, PCAP_ERRBUF_SIZE, - "Error reading /proc/dag: %s", - pcap_strerror(errno)); - ret = -1; +#ifdef HAVE_DAG_STREAMS_API + { + int stream; + for(stream=0;stream<16;stream+=2) { + snprintf(name, 10, "dag%d:%d", c, stream); + if (pcap_add_if(devlistp, name, 0, NULL, errbuf) == -1) { + /* + * Failure. + */ + ret = -1; + } + } } +#endif /* HAVE_DAG_STREAMS_API */ } - - (void)fclose(proc_dag_f); return (ret); } @@ -686,7 +767,34 @@ dag_setnonblock(pcap_t *p, int nonblock, char *errbuf) */ if (pcap_setnonblock_fd(p, nonblock, errbuf) < 0) return (-1); - +#ifdef HAVE_DAG_STREAMS_API + { + uint32_t mindata; + struct timeval maxwait; + struct timeval poll; + + if (dag_get_stream_poll(p->fd, p->md.dag_stream, + &mindata, &maxwait, &poll) < 0) { + snprintf(errbuf, PCAP_ERRBUF_SIZE, "dag_get_stream_poll: %s\n", pcap_strerror(errno)); + return -1; + } + + /* Amount of data to collect in Bytes before calling callbacks. + * Important for efficiency, but can introduce latency + * at low packet rates if to_ms not set! + */ + if(nonblock) + mindata = 0; + else + mindata = 65536; + + if (dag_set_stream_poll(p->fd, p->md.dag_stream, + mindata, &maxwait, &poll) < 0) { + snprintf(errbuf, PCAP_ERRBUF_SIZE, "dag_set_stream_poll: %s\n", pcap_strerror(errno)); + return -1; + } + } +#endif /* HAVE_DAG_STREAMS_API */ if (nonblock) { p->md.dag_offset_flags |= DAGF_NONBLOCK; } else { @@ -711,15 +819,18 @@ dag_get_datalink(pcap_t *p) switch(daglinktype) { case TYPE_HDLC_POS: + case TYPE_COLOR_HDLC_POS: if (p->dlt_list != NULL) { p->dlt_count = 2; p->dlt_list[0] = DLT_CHDLC; p->dlt_list[1] = DLT_PPP_SERIAL; + p->dlt_list[2] = DLT_FRELAY; } p->linktype = DLT_CHDLC; break; case TYPE_ETH: + case TYPE_COLOR_ETH: /* * This is (presumably) a real Ethernet capture; give it a * link-layer-type list with DLT_EN10MB and DLT_DOCSIS, so @@ -740,6 +851,8 @@ dag_get_datalink(pcap_t *p) case TYPE_AAL5: case TYPE_ATM: + case TYPE_MC_ATM: + case TYPE_MC_AAL5: if (p->dlt_list != NULL) { p->dlt_count = 2; p->dlt_list[0] = DLT_ATM_RFC1483; @@ -748,6 +861,16 @@ dag_get_datalink(pcap_t *p) p->linktype = DLT_ATM_RFC1483; break; + case TYPE_MC_HDLC: + if (p->dlt_list != NULL) { + p->dlt_count = 4; + p->dlt_list[0] = DLT_CHDLC; + p->dlt_list[1] = DLT_PPP_SERIAL; + p->dlt_list[2] = DLT_FRELAY; + p->dlt_list[3] = DLT_MTP2; + } + p->linktype = DLT_CHDLC; + break; case TYPE_LEGACY: p->linktype = DLT_NULL; diff --git a/contrib/libpcap/pcap-dag.h b/contrib/libpcap/pcap-dag.h index 64e4f4643d3e..eff01d666de2 100644 --- a/contrib/libpcap/pcap-dag.h +++ b/contrib/libpcap/pcap-dag.h @@ -7,8 +7,8 @@ * * Author: Richard Littin, Sean Irvine ({richard,sean}@reeltwo.com) * - * @(#) $Header: /tcpdump/master/libpcap/pcap-dag.h,v 1.3 2003/07/25 05:32:03 guy Exp $ (LBL) + * @(#) $Header: /tcpdump/master/libpcap/pcap-dag.h,v 1.3.4.1 2005/07/07 06:56:04 guy Exp $ (LBL) */ pcap_t *dag_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebuf); - +int dag_platform_finddevs(pcap_if_t **devlistp, char *errbuf); diff --git a/contrib/libpcap/pcap-dlpi.c b/contrib/libpcap/pcap-dlpi.c index a9a4dc37526e..ee70b881572a 100644 --- a/contrib/libpcap/pcap-dlpi.c +++ b/contrib/libpcap/pcap-dlpi.c @@ -70,7 +70,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/pcap-dlpi.c,v 1.108.2.5 2005/05/03 18:54:35 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/pcap-dlpi.c,v 1.108.2.6 2005/08/13 23:15:58 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -1039,8 +1039,13 @@ dl_dohpuxbind(int fd, char *ebuf) /* * For any error other than a UNIX EBUSY, give up. */ - if (uerror != EBUSY) + if (uerror != EBUSY) { + /* + * dlbindack() has already filled in ebuf for + * this error. + */ return (-1); + } /* * For EBUSY, try the next SAP value; that means that @@ -1050,9 +1055,14 @@ dl_dohpuxbind(int fd, char *ebuf) */ *ebuf = '\0'; hpsap++; - if (hpsap > 100) + if (hpsap > 100) { + strlcpy(ebuf, + "All SAPs from 22 through 100 are in use", + PCAP_ERRBUF_SIZE); return (-1); + } } + return (0); } #endif @@ -1126,6 +1136,13 @@ recv_ack(int fd, int size, const char *what, char *bufp, char *ebuf, int *uerror struct strbuf ctl; int flags; + /* + * Clear out "*uerror", so it's only set for DL_ERROR_ACK/DL_SYSERR, + * making that the only place where EBUSY is treated specially. + */ + if (uerror != NULL) + *uerror = 0; + ctl.maxlen = MAXDLBUF; ctl.len = 0; ctl.buf = bufp; @@ -1161,8 +1178,6 @@ recv_ack(int fd, int size, const char *what, char *bufp, char *ebuf, int *uerror break; default: - if (uerror != NULL) - *uerror = 0; snprintf(ebuf, PCAP_ERRBUF_SIZE, "recv_ack: %s: %s", what, dlstrerror(dlp->error_ack.dl_errno)); break; @@ -1170,8 +1185,6 @@ recv_ack(int fd, int size, const char *what, char *bufp, char *ebuf, int *uerror return (-1); default: - if (uerror != NULL) - *uerror = 0; snprintf(ebuf, PCAP_ERRBUF_SIZE, "recv_ack: %s: Unexpected primitive ack %s", what, dlprim(dlp->dl_primitive)); @@ -1179,8 +1192,6 @@ recv_ack(int fd, int size, const char *what, char *bufp, char *ebuf, int *uerror } if (ctl.len < size) { - if (uerror != NULL) - *uerror = 0; snprintf(ebuf, PCAP_ERRBUF_SIZE, "recv_ack: %s: Ack too small (%d < %d)", what, ctl.len, size); diff --git a/contrib/libpcap/pcap-int.h b/contrib/libpcap/pcap-int.h index 7d3b76318bc3..dfa9170647a6 100644 --- a/contrib/libpcap/pcap-int.h +++ b/contrib/libpcap/pcap-int.h @@ -30,7 +30,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * @(#) $Header: /tcpdump/master/libpcap/pcap-int.h,v 1.68.2.2 2005/05/03 18:54:36 guy Exp $ (LBL) + * @(#) $Header: /tcpdump/master/libpcap/pcap-int.h,v 1.68.2.6 2005/07/07 06:56:04 guy Exp $ (LBL) */ #ifndef pcap_int_h @@ -91,12 +91,21 @@ struct pcap_md { #endif #ifdef HAVE_DAG_API +#ifdef HAVE_DAG_STREAMS_API + u_char *dag_mem_bottom; /* DAG card current memory bottom pointer */ + u_char *dag_mem_top; /* DAG card current memory top pointer */ +#else void *dag_mem_base; /* DAG card memory base address */ - u_int dag_mem_bottom; /* DAG card current memory bottom pointer */ - u_int dag_mem_top; /* DAG card current memory top pointer */ + u_int dag_mem_bottom; /* DAG card current memory bottom offset */ + u_int dag_mem_top; /* DAG card current memory top offset */ +#endif /* HAVE_DAG_STREAMS_API */ int dag_fcs_bits; /* Number of checksum bits from link layer */ int dag_offset_flags; /* Flags to pass to dag_offset(). */ -#endif + int dag_stream; /* DAG stream number */ + int dag_timeout; /* timeout specified to pcap_open_live. + * Same as in linux above, introduce + * generally? */ +#endif /* HAVE_DAG_API */ }; /* @@ -151,7 +160,7 @@ struct pcap { u_char *pkt; /* We're accepting only packets in this direction/these directions. */ - direction_t direction; + pcap_direction_t direction; /* * Methods. @@ -159,7 +168,7 @@ struct pcap { int (*read_op)(pcap_t *, int cnt, pcap_handler, u_char *); int (*inject_op)(pcap_t *, const void *, size_t); int (*setfilter_op)(pcap_t *, struct bpf_program *); - int (*setdirection_op)(pcap_t *, direction_t); + int (*setdirection_op)(pcap_t *, pcap_direction_t); int (*set_datalink_op)(pcap_t *, int); int (*getnonblock_op)(pcap_t *, char *); int (*setnonblock_op)(pcap_t *, int, char *); diff --git a/contrib/libpcap/pcap-linux.c b/contrib/libpcap/pcap-linux.c index 0cd6ca8ef3f4..b8ed1f34575a 100644 --- a/contrib/libpcap/pcap-linux.c +++ b/contrib/libpcap/pcap-linux.c @@ -27,7 +27,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/pcap-linux.c,v 1.110.2.2 2005/06/20 21:30:18 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/pcap-linux.c,v 1.110.2.6 2005/08/16 04:25:26 guy Exp $ (LBL)"; #endif /* @@ -195,7 +195,7 @@ static int pcap_read_packet(pcap_t *, pcap_handler, u_char *); static int pcap_inject_linux(pcap_t *, const void *, size_t); static int pcap_stats_linux(pcap_t *, struct pcap_stat *); static int pcap_setfilter_linux(pcap_t *, struct bpf_program *); -static int pcap_setdirection_linux(pcap_t *, direction_t); +static int pcap_setdirection_linux(pcap_t *, pcap_direction_t); static void pcap_close_linux(pcap_t *); /* @@ -536,14 +536,14 @@ pcap_read_packet(pcap_t *handle, pcap_handler callback, u_char *userdata) /* * If the user only wants incoming packets, reject it. */ - if (handle->direction == D_IN) + if (handle->direction == PCAP_D_IN) return 0; } else { /* * Incoming packet. * If the user only wants outgoing packets, reject it. */ - if (handle->direction == D_OUT) + if (handle->direction == PCAP_D_OUT) return 0; } } @@ -1014,7 +1014,7 @@ pcap_setfilter_linux(pcap_t *handle, struct bpf_program *filter) * single device? IN, OUT or both? */ static int -pcap_setdirection_linux(pcap_t *handle, direction_t d) +pcap_setdirection_linux(pcap_t *handle, pcap_direction_t d) { #ifdef HAVE_PF_PACKET_SOCKETS if (!handle->md.sock_packet) { @@ -1185,6 +1185,13 @@ static void map_arphrd_to_dlt(pcap_t *handle, int arptype, int cooked_ok) handle->linktype = DLT_PRISM_HEADER; break; +#ifndef ARPHRD_IEEE80211_RADIOTAP /* new */ +#define ARPHRD_IEEE80211_RADIOTAP 803 +#endif + case ARPHRD_IEEE80211_RADIOTAP: + handle->linktype = DLT_IEEE802_11_RADIO; + break; + case ARPHRD_PPP: /* * Some PPP code in the kernel supplies no link-layer diff --git a/contrib/libpcap/pcap-stdinc.h b/contrib/libpcap/pcap-stdinc.h index fa5ea26bb305..12810247e6e0 100644 --- a/contrib/libpcap/pcap-stdinc.h +++ b/contrib/libpcap/pcap-stdinc.h @@ -33,6 +33,9 @@ #define SIZEOF_CHAR 1 #define SIZEOF_SHORT 2 #define SIZEOF_INT 4 +#ifndef _MSC_EXTENSIONS +#define SIZEOF_LONG_LONG 8 +#endif /* * Avoids a compiler warning in case this was already defined diff --git a/contrib/libpcap/pcap-win32.c b/contrib/libpcap/pcap-win32.c index 5b814f0e20cb..1a75d43d51c1 100644 --- a/contrib/libpcap/pcap-win32.c +++ b/contrib/libpcap/pcap-win32.c @@ -32,7 +32,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/pcap-win32.c,v 1.25.2.2 2005/06/10 03:48:56 risso Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/pcap-win32.c,v 1.25.2.3 2005/07/10 17:52:54 risso Exp $ (LBL)"; #endif #include @@ -498,6 +498,9 @@ pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, /* Set the buffer size */ p->bufsize = PcapBufSize; + /* Store the timeout. Used by pcap_setnonblock() */ + p->timeout= to_ms; + /* allocate Packet structure used during the capture */ if((p->Packet = PacketAllocatePacket())==NULL) { diff --git a/contrib/libpcap/pcap.3 b/contrib/libpcap/pcap.3 index 69dde16aba6d..727a53eeea91 100644 --- a/contrib/libpcap/pcap.3 +++ b/contrib/libpcap/pcap.3 @@ -1,4 +1,4 @@ -.\" @(#) $Header: /tcpdump/master/libpcap/pcap.3,v 1.64.2.4 2005/06/03 20:36:56 guy Exp $ +.\" @(#) $Header: /tcpdump/master/libpcap/pcap.3,v 1.64.2.8 2005/09/07 08:29:17 guy Exp $ .\" .\" Copyright (c) 1994, 1996, 1997 .\" The Regents of the University of California. All rights reserved. @@ -80,7 +80,7 @@ int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask) int pcap_setfilter(pcap_t *p, struct bpf_program *fp) void pcap_freecode(struct bpf_program *) -int pcap_setdirection(pcap_t *p, direction_t d) +int pcap_setdirection(pcap_t *p, pcap_direction_t d) .ft .LP .ft B @@ -689,7 +689,11 @@ supplied to as the source link-layer address, if the header contains such an address, might be changed to be the address assigned to the interface on which the packet it sent, if the platform doesn't support sending -completely raw and unchanged packets. +completely raw and unchanged packets. Even worse, some drivers on some +platforms might change the link-layer type field to whatever value +libpcap used when attaching to the device, even on platforms that +.I do +nominally support sending completely raw and unchanged packets. .PP .B pcap_sendpacket() is like @@ -781,23 +785,23 @@ has been made the filter program for a pcap structure by a call to .PP .B pcap_setdirection() is used to specify a direction that packets will be captured. -.I direction_t +.I pcap_direction_t is one of the constants -.BR D_IN , -.B D_OUT +.BR PCAP_D_IN , +.B PCAP_D_OUT or -.BR D_INOUT . -.B D_IN +.BR PCAP_D_INOUT . +.B PCAP_D_IN will only capture packets received by the device, -.B D_OUT +.B PCAP_D_OUT will only capture packets sent by the device and -.B D_INOUT +.B PCAP_D_INOUT will capture packets received by or sent by the device. -.B D_INOUT +.B PCAP_D_INOUT is the default setting if this function is not called. This isn't necessarily supported on all platforms; some platforms might return an error, and some other platforms might not support -.BR D_OUT . +.BR PCAP_D_OUT . This operation is not supported if a ``savefile'' is being read. .B \-1 is returned on failure, diff --git a/contrib/libpcap/pcap.c b/contrib/libpcap/pcap.c index e647dc5bff66..c89cbc115d8a 100644 --- a/contrib/libpcap/pcap.c +++ b/contrib/libpcap/pcap.c @@ -33,7 +33,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/pcap.c,v 1.88.2.3 2005/05/27 23:33:00 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/pcap.c,v 1.88.2.8 2005/08/13 22:29:46 hannes Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -373,6 +373,11 @@ static struct dlt_choice dlt_choices[] = { DLT_CHOICE(DLT_JUNIPER_ES, "Juniper Encryption Services PIC"), DLT_CHOICE(DLT_JUNIPER_MONITOR, "Juniper Passive Monitor PIC"), DLT_CHOICE(DLT_JUNIPER_SERVICES, "Juniper Advanced Services PIC"), + DLT_CHOICE(DLT_JUNIPER_MFR, "Juniper FRF.16 Frame Relay"), + DLT_CHOICE(DLT_JUNIPER_ETHER, "Juniper Ethernet"), + DLT_CHOICE(DLT_JUNIPER_PPP, "Juniper PPP"), + DLT_CHOICE(DLT_JUNIPER_FRELAY, "Juniper Frame Relay"), + DLT_CHOICE(DLT_JUNIPER_CHDLC, "Juniper C-HDLC"), DLT_CHOICE_SENTINEL }; @@ -696,7 +701,7 @@ pcap_setfilter(pcap_t *p, struct bpf_program *fp) * might not be supported. */ int -pcap_setdirection(pcap_t *p, direction_t d) +pcap_setdirection(pcap_t *p, pcap_direction_t d) { if (p->setdirection_op == NULL) { snprintf(p->errbuf, PCAP_ERRBUF_SIZE, diff --git a/contrib/libpcap/pcap.h b/contrib/libpcap/pcap.h index c8240ad558f6..535c7da3ebd2 100644 --- a/contrib/libpcap/pcap.h +++ b/contrib/libpcap/pcap.h @@ -31,7 +31,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * @(#) $Header: /tcpdump/master/libpcap/pcap.h,v 1.52.2.2 2005/06/03 20:36:56 guy Exp $ (LBL) + * @(#) $Header: /tcpdump/master/libpcap/pcap.h,v 1.52.2.5 2005/07/07 02:04:36 guy Exp $ (LBL) */ #ifndef lib_pcap_h @@ -47,9 +47,7 @@ #include #endif /* WIN32/MSDOS/UN*X */ -#ifndef PCAP_DONT_INCLUDE_PCAP_BPF_H -#include -#endif +#include #include @@ -121,10 +119,10 @@ struct pcap_file_header { }; typedef enum { - D_INOUT = 0, - D_IN, - D_OUT -} direction_t; + PCAP_D_INOUT = 0, + PCAP_D_IN, + PCAP_D_OUT +} pcap_direction_t; /* * Each packet in the dump file is prepended with this generic header. @@ -224,7 +222,7 @@ int pcap_next_ex(pcap_t *, struct pcap_pkthdr **, const u_char **); void pcap_breakloop(pcap_t *); int pcap_stats(pcap_t *, struct pcap_stat *); int pcap_setfilter(pcap_t *, struct bpf_program *); -int pcap_setdirection(pcap_t *, direction_t); +int pcap_setdirection(pcap_t *, pcap_direction_t); int pcap_getnonblock(pcap_t *, char *); int pcap_setnonblock(pcap_t *, int, char *); void pcap_perror(pcap_t *, char *); diff --git a/contrib/libpcap/savefile.c b/contrib/libpcap/savefile.c index ec1088d01320..52302c9141d5 100644 --- a/contrib/libpcap/savefile.c +++ b/contrib/libpcap/savefile.c @@ -30,7 +30,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/savefile.c,v 1.126.2.8 2005/06/03 20:36:57 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/savefile.c,v 1.126.2.13 2005/08/29 21:05:45 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -71,6 +71,12 @@ static const char rcsid[] _U_ = */ #define NAVTEL_TCPDUMP_MAGIC 0xa12b3c4d +/* + * Normal libpcap format, except for seconds/nanoseconds timestamps, + * as per a request by Ulf Lamping + */ +#define NSEC_TCPDUMP_MAGIC 0xa1b23c4d + /* * We use the "receiver-makes-right" approach to byte order, * because time is at a premium when we are writing the file. @@ -412,6 +418,18 @@ static const char rcsid[] _U_ = */ #define LINKTYPE_LINUX_LAPD 177 +/* + * Juniper-private data link type, as per request from + * Hannes Gredler . + * The Link Types are used for prepending meta-information + * like interface index, interface name + * before standard Ethernet, PPP, Frelay & C-HDLC Frames + */ +#define LINKTYPE_JUNIPER_ETHER 178 +#define LINKTYPE_JUNIPER_PPP 179 +#define LINKTYPE_JUNIPER_FRELAY 180 +#define LINKTYPE_JUNIPER_CHDLC 181 + static struct linktype_map { int dlt; int linktype; @@ -611,6 +629,13 @@ static struct linktype_map { /* viSDN LAPD */ { DLT_LINUX_LAPD, LINKTYPE_LINUX_LAPD }, + /* Juniper meta-information before Ether, PPP, Frame Relay, C-HDLC Frames */ + { DLT_JUNIPER_ETHER, LINKTYPE_JUNIPER_ETHER }, + { DLT_JUNIPER_PPP, LINKTYPE_JUNIPER_PPP }, + { DLT_JUNIPER_FRELAY, LINKTYPE_JUNIPER_FRELAY }, + { DLT_JUNIPER_CHDLC, LINKTYPE_JUNIPER_CHDLC }, + + { -1, -1 } }; @@ -722,7 +747,7 @@ sf_inject(pcap_t *p, const void *buf _U_, size_t size _U_) * single device? IN, OUT or both? */ static int -sf_setdirection(pcap_t *p, direction_t d) +sf_setdirection(pcap_t *p, pcap_direction_t d) { snprintf(p->errbuf, sizeof(p->errbuf), "Setting direction is not supported on savefiles"); diff --git a/contrib/libpcap/scanner.l b/contrib/libpcap/scanner.l index ab2b07945ffd..765031649b7e 100644 --- a/contrib/libpcap/scanner.l +++ b/contrib/libpcap/scanner.l @@ -22,7 +22,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/libpcap/scanner.l,v 1.99.2.3 2005/06/20 21:30:19 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/libpcap/scanner.l,v 1.99.2.4 2005/09/05 09:08:07 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -72,7 +72,6 @@ static char *in_buffer; #define getc(fp) (*in_buffer == 0 ? EOF : *in_buffer++) #endif -#define yylval pcap_lval extern YYSTYPE yylval; %} @@ -263,6 +262,8 @@ outbound return OUTBOUND; vlan return VLAN; mpls return MPLS; +pppoed return PPPOED; +pppoes return PPPOES; lane return LANE; llc return LLC;