WinPcap  4.1.3
Modules
Here is a list of all modules:
[detail level 123]
 WinPcap internals This portion of the manual describes the internal structure and interfaces of WinPcap, starting from the lowest-level module. It is targeted at people that must extend or modify this software, or to the ones interested in how it works. Therefore, developers who just want to use WinPcap in their software don't need to read it.

WinPcap structure

Quoted from the home page of winpcap:

WinPcap is an architecture for packet capture and network analysis for the Win32 platforms. It includes a kernel-level packet filter, a low-level dynamic link library (packet.dll), and a high-level and system-independent library (wpcap.dll).

Why we use the term "architecture" rather than "library"? Because packet capture is a low level mechanism that requires a strict interaction with the network adapter and with the operating system, in particular with its networking implementation, so a simple library is not sufficient.

The following figure shows the various components of WinPcap:

Main components of WinPcap.

First, a capture system needs to bypass the operating systems's protocol stack in order to access the raw data transiting on the network. This requires a portion running inside the kernel of OS, interacting directly with the network interface drivers. This portion is very system dependent, and in our solution it is realized as a device driver, called Netgroup Packet Filter (NPF); we provide different versions of the driver for Windows 95, Windows 98, Windows ME, Windows NT 4, Windows 2000 and Windows XP. These drivers offer both basic features like packet capture and injection, as well as more advanced ones like a programmable filtering system and a monitoring engine. The first one can be used to restrict a capture session to a subset of the network traffic (e.g. it is possible to capture only the ftp traffic generated by a particular host), the second one provides a powerful but simple to use mechanism to obtain statistics on the traffic (e.g. it is possible to obtain the network load or the amount of data exchanged between two hosts).

Second, the capture system must export an interface that user-level applications will use to take advantage of the features provided by the kernel driver. WinPcap provides two different libraries: packet.dll and wpcap.dll

The first one offers a low-level API that can be used to directly access the functions of the driver, with a programming interface independent from the Microsoft OS. 

The second one exports a more powerful set of high level capture primitives that are compatible with libpcap, the well known Unix capture library. These functions enable packet capture in a manner that is independent of the underlying network hardware and operating system.

Throughout this documentation we will refer to the Packet Driver API or packet.dll as the first set of functions, whereas wpcap, wpcap.dll or libpcap will refer to the to the second one.

 NPF driver internals manual

This section documents the internals of the Netgroup Packet Filter (NPF), the kernel portion of WinPcap. Normal users are probably interested in how to use WinPcap and not in its internal structure. Therefore the information present in this module is destined mainly to WinPcap developers and maintainers, or to the people interested in how the driver works. In particular, a good knowledge of OSes, networking and Win32 kernel programming and device drivers development is required to profitably read this section. 

NPF is the WinPcap component that does the hard work, processing the packets that transit on the network and exporting capture, injection and analysis capabilities to user-level.

The following paragraphs will describe the interaction of NPF with the OS and its basic structure.

NPF and NDIS

NDIS (Network Driver Interface Specification) is a standard that defines the communication between a network adapter (or, better, the driver that manages it) and the protocol drivers (that implement for example TCP/IP). Main NDIS purpose is to act as a wrapper that allows protocol drivers to send and receive packets onto a network (LAN or WAN) without caring either the particular adapter or the particular Win32 operating system.

NDIS supports three types of network drivers:

  1. Network interface card or NIC drivers. NIC drivers directly manage network interface cards, referred to as NICs. The NIC drivers interface directly to the hardware at their lower edge and at their upper edge present an interface to allow upper layers to send packets on the network, to handle interrupts, to reset the NIC, to halt the NIC and to query and set the operational characteristics of the driver. NIC drivers can be either miniports or legacy full NIC drivers.
    • Miniport drivers implement only the hardware-specific operations necessary to manage a NIC, including sending and receiving data on the NIC. Operations common to all lowest level NIC drivers, such as synchronization, is provided by NDIS. Miniports do not call operating system routines directly; their interface to the operating system is NDIS.
      A miniport does not keep track of bindings. It merely passes packets up to NDIS and NDIS makes sure that these packets are passed to the correct protocols.
    • Full NIC drivers have been written to perform both hardware-specific operations and all the synchronization and queuing operations usually done by NDIS. Full NIC drivers, for instance, maintain their own binding information for indicating received data. 
  2. Intermediate drivers. Intermediate drivers interface between an upper-level driver such as a protocol driver and a miniport. To the upper-level driver, an intermediate driver looks like a miniport. To a miniport, the intermediate driver looks like a protocol driver. An intermediate protocol driver can layer on top of another intermediate driver although such layering could have a negative effect on system performance. A typical reason for developing an intermediate driver is to perform media translation between an existing legacy protocol driver and a miniport that manages a NIC for a new media type unknown to the protocol driver. For instance, an intermediate driver could translate from LAN protocol to ATM protocol. An intermediate driver cannot communicate with user-mode applications, but only with other NDIS drivers.
  3. Transport drivers or protocol drivers. A protocol driver implements a network protocol stack such as IPX/SPX or TCP/IP, offering its services over one or more network interface cards. A protocol driver services application-layer clients at its upper edge and connects to one or more NIC driver(s) or intermediate NDIS driver(s) at its lower edge.

NPF is implemented as a protocol driver. This is not the best possible choice from the performance point of view, but allows reasonable independence from the MAC layer and as well as complete access to the raw traffic.

Notice that the various Win32 operating systems have different versions of NDIS: NPF is NDIS 5 compliant under Windows 2000 and its derivations (like Windows XP), NDIS 3 compliant on the other Win32 platforms. 

Next figure shows the position of NPF inside the NDIS stack:

Figure 1: NPF inside NDIS.

The interaction with the OS is normally asynchronous. This means that the driver provides a set of callback functions that are invoked by the system when some operation is required to NPF. NPF exports callback functions for all the I/O operations of the applications: open, close, read, write, ioctl, etc.

The interaction with NDIS is asynchronous as well: events like the arrival of a new packet are notified to NPF through a callback function (Packet_tap() in this case). Furthermore, the interaction with NDIS and the NIC driver takes always place by means of non blocking functions: when NPF invokes a NDIS function, the call returns immediately; when the processing ends, NDIS invokes a specific NPF callback to inform that the function has finished. The driver exports a callback for any low-level operation, like sending packets, setting or requesting parameters on the NIC, etc.

NPF structure basics

Next figure shows the structure of WinPcap, with particular reference to the NPF driver.

Figure 2: NPF device driver.

NPF is able to perform a number of different operations: capture, monitoring, dump to disk, packet injection. The following paragraphs will describe shortly each of these operations.

Packet Capture

The most important operation of NPF is packet capture. During a capture, the driver sniffs the packets using a network interface and delivers them intact to the user-level applications. 

The capture process relies on two main components:

  • A packet filter that decides if an incoming packet has to be accepted and copied to the listening application. Most applications using NPF reject far more packets than those accepted, therefore a versatile and efficient packet filter is critical for good over-all performance. A packet filter is a function with boolean output that is applied to a packet. If the value of the function is true the capture driver copies the packet to the application; if it is false the packet is discarded. NPF packet filter is a bit more complex, because it determines not only if the packet should be kept, but also the amount of bytes to keep. The filtering system adopted by NPF derives from the BSD Packet Filter (BPF), a virtual processor able to execute filtering programs expressed in a pseudo-assembler and created at user level. The application takes a user-defined filter (e.g. “pick up all UDP packets”) and, using wpcap.dll, compiles them into a BPF program (e.g. “if the packet is IP and the protocol type field is equal to 17, then return true”). Then, the application uses the BIOCSETF IOCTL to inject the filter in the kernel. At this point, the program is executed for every incoming packet, and only the conformant packets are accepted. Unlike traditional solutions, NPF does not interpret the filters, but it executes them. For performance reasons, before using the filter NPF feeds it to a JIT compiler that translates it into a native 80x86 function. When a packet is captured, NPF calls this native function instead of invoking the filter interpreter, and this makes the process very fast. The concept behind this optimization is very similar to the one of Java jitters.

  • A circular buffer to store the packets and avoid loss. A packet is stored in the buffer with a header that maintains information like the timestamp and the size of the packet. Moreover, an alignment padding is inserted between the packets in order to speed-up the access to their data by the applications. Groups of  packets can be copied with a single operation from the NPF buffer to the applications. This improves performances because it minimizes the number of reads. If the buffer is full when a new packet arrives, the packet is discarded and hence it's lost. Both kernel and user buffer can be changed at runtime for maximum versatility: packet.dll and wpcap.dll provide functions for this purpose.

The size of the user buffer is very important because it determines the maximum amount of data that can be copied from kernel space to user space within a single system call. On the other hand, it can be noticed that also the minimum amount of data that can be copied in a single call is extremely important. In presence of a large value for this variable, the kernel waits for the arrival of several packets before copying the data to the user. This guarantees a low number of system calls, i.e. low processor usage, which is a good setting for applications like sniffers. On the other side, a small value means that the kernel will copy the packets as soon as the application is ready to receive them. This is excellent for real time applications (like, for example, ARP redirectors or bridges) that need the better responsiveness from the kernel. From this point of view, NPF has a configurable behavior, that allows users to choose between best efficiency or best responsiveness (or any intermediate situation). 

The wpcap library includes a couple of system calls that can be used both to set the timeout after which a read expires and the minimum amount of data that can be transferred to the application. By default, the read timeout is 1 second, and the minimum amount of data copied between the kernel and the application is 16K.

Packet injection

NPF allows to write raw packets to the network. To send data, a user-level application performs a WriteFile() system call on the NPF device file. The data is sent to the network as is, without encapsulating it in any protocol, therefore the application will have to build the various headers for each packet. The application usually does not need to generate the FCS because it is calculated by the network adapter hardware and it is attached automatically at the end of a packet before sending it to the network.

In normal situations, the sending rate of the packets to the network is not very high because of the need of a system call for each packet. For this reason, the possibility to send a single packet more than once with a single write system call has been added. The user-level application can set, with an IOCTL call (code pBIOCSWRITEREP), the number of times a single packet will be repeated: for example, if this value is set to 1000, every raw packet written by the application on the driver's device file will be sent 1000 times. This feature can be used to generate high speed traffic for testing purposes: the overload of context switches is no longer present, so performance is remarkably better. 

Network monitoring

WinPcap offers a kernel-level programmable monitoring module, able to calculate simple statistics on the network traffic. The idea behind this module is shown in Figure 2: the statistics can be gathered without the need to copy the packets to the application, that simply receives and displays the results obtained from the monitoring engine. This allows to avoid great part of the capture overhead in terms of memory and CPU clocks.

The monitoring engine is made of a classifier followed by a counter. The packets are classified using the filtering engine of NPF, that provides a configurable way to select a subset of the traffic. The data that pass the filter go to the counter, that keeps some variables like the number of packets and the amount of bytes accepted by the filter and updates them with the data of the incoming packets. These variables are passed to the user-level application at regular intervals whose period can be configured by the user. No buffers are allocated at kernel and user level.

Dump to disk

The dump to disk capability can be used to save the network data to disk directly from kernel mode.

Figure 3: packet capture versus kernel-level dump.

In traditional systems, the path covered by the packets that are saved to disk is the one followed by the black arrows in Figure 3: every packet is copied several times, and normally 4 buffers are allocated: the one of the capture driver, the one in the application that keeps the captured data, the one of the stdio functions (or similar) that are used by the application to write on file, and finally the one of the file system.

When the kernel-level traffic logging feature of NPF is enabled, the capture driver addresses the file system directly, hence the path covered by the packets is the one of the red dotted arrow: only two buffers and a single copy are necessary, the number of system call is drastically reduced, therefore the performance is considerably better.

Current implementation dumps the to disk in the widely used libpcap format. It gives also the possibility to filter the traffic before the dump process in order to select the packet that will go to the disk.

Further reading

The structure of NPF and its filtering engine derive directly from the one of the BSD Packet Filter (BPF), so if you are interested the subject you can read the following papers:

- S. McCanne and V. Jacobson, The BSD Packet Filter: A New Architecture for User-level Packet Capture. Proceedings of the 1993 Winter USENIX Technical Conference (San Diego, CA, Jan. 1993), USENIX. 

- A. Begel, S. McCanne, S.L.Graham, BPF+: Exploiting Global Data-flow Optimization in a Generalized Packet Filter Architecture, Proceedings of ACM SIGCOMM '99, pages 123-134, Conference on Applications, technologies, architectures, and protocols for computer communications, August 30 - September 3, 1999, Cambridge, USA

Note

The code documented in this manual is the one of the Windows NTx version of NPF. The Windows 9x code is very similar, but it is less efficient and lacks advanced features like kernel-mode dump.

 NPF structures and definitions
 NPF functions
 NPF Just-in-time compiler definitions
 How to compile WinPcap

This section explains how to compile WinPcap, both the kernel level and the user-level portion, on the various Win32 platforms. The source code can be found on the WinPcap website.

Compiling the driver

Two main NPF source trees are available for compilation:  Windows NTx and Windows 9x. Note that, since the NPF Driver is platform-dependent, it is STRONGLY suggested to compile it for the OS where it will be used, in order to link the correct DDK libraries. For example, if you compile the driver with the Windows NT 4 DDK, it will not work properly on Windows 2000 and vice versa.

Compiling the driver for Windows NT4

Software requirements:

  • Microsoft Driver Developer Kit (DDK) for Windows NT4
  • A recent version of the Microsoft Platform Software Development Kit (SDK) that is compatible with Visual Studio 6 (the latest compatible one is Platform SDK February 2003). This version of the PSDK is available on the Microsoft web site at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm. It can be ordered online at http://www.qmedia.ca/launch/psdk.htm, and it's also available to Microsoft MSDN subscribers on the Subscribers Downloads web site.
  • Microsoft Visual C++ 6.0 with Service Pack 5 or 6 (both the service packs are available online on the Microsoft web site).

If your system satisfies these requirements, follow these steps:

  1. From the Windows NT Start menu, select the folder Programs and then Development Kits, then Windows NT4 DDK. From here select the voice Checked Build Environment if you want to build a debug version, or Free Build Environment if you want to build a release version.
  2. A command prompt will be opened. Move to the directory PacketNTx inside the WinPcap source folder and type the command

    CompileDriver

    This script will generate the driver (npf.sys). The binary will be put in one of these folders
    • Free Build Environment: winpcap\PacketNTx\driver\bin\NT4\i386\free
    • Checked Build Environment: winpcap\PacketNTx\driver\bin\NT4\i386\checked

Warning: sometimes, during the compilation of the driver, a lot of 'last line incomplete' errors are generated. Ignore these errors and let the compilation process continue, they are due to bugs in some DDK versions.

Compiling the driver for Windows 2000/XP/2003/Vista/2008/Win7/2008R2 (x86 and x64)

Software requirements:

  • Microsoft Windows Driver Kit (WDK) 6001.18002. As of release 4.1, WinPcap is compiled with WDK 6001.18002.

NOTE: it should be possible to use older DDKs to compile WinPcap, but you might need to manually modify the compilation scripts in order to disable PREfast (PREfast is a static code analysis tool shipped with recent versions of the DDK/WDK).

If your system satisfies these requirements, follow these steps:

  1. From the Windows Start menu, select the folder Programs and then Windows Driver K, then WDK 6001.18002, then Build Environments.
    • x86 driver: Choose Windows 2000 and then Windows 2000 x86 Free Build Environment if you want to build a release version or Windows 2000 x86 Checked Build Environment if you want to build a debug version.
    • x64 driver: Choose Windows Server 2003 and then Windows Server 2003 x64 Free Build Environment if you want to build a release version or Windows Server 2003 x64 Checked Build Environment if you want to build a debug version.
  2. A command prompt will be opened. Move to the directory PacketNTx inside the WinPcap source folder and type the command

    CompileDriver

    This script will generate the driver (npf.sys). The binary will be put in one of these folders
    • x86 driver (both Free and Checked Build): winpcap\PacketNTx\driver\bin\i386
    • x64 driver (both Free and Checked Build): winpcap\PacketNTx\driver\bin\amd64

Compiling the driver on Windows 9x

NOTE: this Windows platform is no longer supported by WinPcap. However, the sources for these operating systems are still available in the sources package.

To compile the driver for Windows 9x you will need:

  • Driver Developer Kit (DDK) for Windows 95/98/ME
  • A recent version of the Microsoft Platform Software Development Kit (SDK) that is compatible with Visual Studio 6 (the latest compatible one is Platform SDK February 2003). This version of the PSDK is available on the Microsoft web site at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm. It can be ordered online at http://www.qmedia.ca/launch/psdk.htm, and it's also available to Microsoft MSDN subscribers on the Subscribers Downloads web site.
  • Microsoft Visual C++ 6.0 with Service Pack 5 or 6 (both the service packs are available online on the Microsoft web site).

The steps to follow are:

  1. Open a DOS shell
  2. Go to the VisualC++ BIN directory (for example C:\DEVSTUDIO\VC\BIN) and execute the command

    Vcvars32
  3. Go to the SDK directory (for example C:\MSSDK) and execute the command

    Setenv sdk_path

    where sdk_path is the directory of SDK (for example Setenv C:\MSSDK)
  4. Go to the DDK directory (for example C:\DDK) and execute the command

    Ddkenv 32 net
  5. Move to the directory whit the driver's source code and type the command

    nmake rtl

    to obtain a release version, or

    nmake

    to obtain a debug version.
    The release version of packet.vxd will be placed in the retail directory, the debug version in the debug directory.

Warning: On some systems the NMAKE utility is not able to launch ADRC2VXD, this means that the driver binary is generated correctly, but without the copyright information. We don't know the cause of this problem.

Compiling packet.dll

The source tree for this DLL is located in PacketNTx\dll\.

NOTE: the 9x family of Windows operating systems is no longer supported by WinPcap. However, the sources for these operating systems are still available in the sources package.

Software requirements:

  • Microsoft Visual Studio 2005 SP1. It's theoretically possible to compile the x86 version with Visual Studio 6, but the project files are no longer maintained.
  • The AirPcap developer's pack from http://www.cacetech.com/products/airpcap.html. The AirPcap developer's pack needs to be unzipped in a folder in the same folder where the WinPcap sources have been unzipped.

To compile the PACKET.DLL, load the project packet.sln contained in the directory PacketNTx\dll\project in Visual Studio 2005. There are several project configurations, each of them available for the x86 (Win32) and x64 platforms:

  • Release: standard release configuration
  • Debug: standard debug configuration
  • Release NT4: release configuration able to run on NT4. It does not include Wan and IP helper API support.
  • Debug NT4: debug configuration able to run on NT4. It does not include Wan and IP helper API support.
  • Release No NetMon: release configuration able to run on Vista. It does not include Wan support (with the NetMon API).
  • Debug No NetMon: debug configuration able to run on Vista. It does not include Wan support (with the NetMon API).
  • Release LOG_TO_FILE: standard release configuration with tracing to file enabled.
  • Release NT4 LOG_TO_FILE: release configuration able to run on NT4 with tracing to file enabled. It does not include Wan and IP helper API support.
  • Release No NetMon LOG_TO_FILE: release configuration able to run on Vista with tracing to file enabled. It does not include Wan support (with the NetMon API).

Choose the desired configuration and build the project to obtain the binary files.

Compiling wpcap.dll

wpcap.dll can be compiled for any Win32 platform and the generated dll is system independent.

System Requirements:

  • Microsoft Visual Studio 2005 SP1. It's theoretically possible to compile the x86 version with Visual Studio 6, but the project files are no longer maintained.
  • The AirPcap developer's pack from http://www.cacetech.com/products/airpcap.htm. The AirPcap developer's pack needs to be unzipped in a folder in the same folder where the WinPcap sources have been unzipped.There are eight build project configurations:

To compile the wpcap.dll, load the project wpcap.sln contained in the directory wpcap\PRJ in Visual Studio 2005. There are several project configurations, each of them available for the x86 (Win32) and x64 platforms:

  • Release: standard release configuration
  • Debug: standard debug configuration
  • Release No AirPcap: release configuration without support for AirPcap adapters.
  • Debug No AirPcap: debug configuration without support for AirPcap adapters.

Choose the desired configuration and build the project to obtain the binary files.

Note: wpcap.dll contains the source code of libpcap from www.tcpdump.org, with some modifications for remote capture. You will be able to include and build a different libpcap version simply copying it in the directory winpcap\wpcap\prj of the WinPcap source code distribution, but you must use the "Debug" or "Release" build configurations.
 

 Packet.dll – Packet Driver API Packet.dll is a dynamic link library that offers a set of low level functions to:
  • install, start and stop the NPF device driver
  • Receive packets from the NPF driver
  • send packets to the NPF driver
  • obtain the list of the available network adapters
  • retrieve various information about an adapter, like the description and the list of addresses and netmasks
  • query and set various low-level parameters of an adapter

There are two versions of packet.dll: the first one runs under Windows 95/98/ME, the second one is for  Windows NT/2000/XP.

Packet.dll was created to provide a layer to access the low level functionalities of WinPcap in a system independent way. This library handles all the system-dependent details (like managing the devices, interacting with the OS to manage the adapters, looking for the information in the registry and so on), and exports an API that is uniform across all Windows OSes. In this way, applications or libraries based on it can run without being recompiled under any Windows operating system.

However, not all of the packet.dll API is totally portable: some advanced features, like kernel-mode dump, are present only in the WinNTx version of WinPcap, while packet.dll for Win9x does not provide them. On the other side, the NTx version is a superset of the 9x one, in other words all the function present in the Win9x version are present in WinNTx too.

The other important feature of this library is its ability to handle NPF driver. Packet.dll transparently installs and starts the driver when an application attempts to access an adapter. This avoids the manual installation of the driver through the control panel.

Important note, read carefully!

The source code of Packet.dll is freely available and completely documented. However, packet.dll should be considered an internal API, because its purpose inside WinPcap is to be a building block for the real public API: wpcap.dll.

As a consequence, since the normal and suggested way for an application to use WinPcap is through wpcap.dll, we don't guarantee that the packet.dll API will not be changed in future releases of winpcap, and we don't provide support for this API. For the same reason, this manual doesn't contain any more the Doxygen-generated documentation of Packet.dll: the user will have to run Doxygen on his own to create it, or read the comments in the source code.

 WinPcap user's manual

This section contains the user manual of wpcap.dll, the dynamic library that contains the public WinPcap API. wpcap.dll exports a set of system-independent functions for packet capture and network analysis. These functions can be used to:

  • obtain the list of the available network adapters
  • retrieve various information about an adapter, like the description and the list of addresses
  • sniff the packets using one of the network interface cards of the PC
  • send packets to the network
  • efficiently save packets to disk and load them with an interface similar to the one of live capture
  • create packet filters using a high level language and apply them to the captured packets

wpcap.dll is compatible with libpcap, the well known packet capture library for Unix. This compatibility means that one can develop portable network tools that will run on the Win32 OS family and on all of the major Unix flavors.

Several portions of the manual present in this section derive directly from the man pages of tcpdump and libpcap, maintained by the tcpdump.org developers. Therefore, if you are looking for updated docs, you can consult the web site www.tcpdump.org.

Note

Some functions are marked deprecated or discouraged. The meanings of these labels are:

  • discouraged: the use of another function with similar purpose is suggested, however this one is still valid.
  • deprecated: the function is present only for portability and backward compatibility. It should be avoided, and it is strongly suggested to use another equivalent function instead.

 Definitions
 Exported functions
 WinPcap tutorial: a step by step guide to using WinPcapThis section shows how to use the features of the WinPcap API. It is organized as a tutorial, subdivided into a set of lessons that will introduce the reader, in a step-by-step fashion, to program development using WinPcap, from the basic functions (obtaining the adapter list, starting a capture, etc.) to the most advanced ones (handling send queues and gathering statistics about network traffic)
 Obtaining the device listTypically, the first thing that a WinPcap-based application does is get a list of attached network adapters. Both libpcap and WinPcap provide the pcap_findalldevs_ex() function for this purpose: this function returns a linked list of pcap_if structures, each of which contains comprehensive information about an attached adapter. In particular, the fields name and description contain the name and a human readable description, respectively, of the corresponding device
 Obtaining advanced information about installed devicesLesson 1 (Obtaining the device list) demonstrated how to get basic information (i.e. device name and description) about available adapters. Actually, WinPcap provides also other advanced information. In particular, every pcap_if structure returned by pcap_findalldevs_ex() contains also a list of pcap_addr structures, with:
 Opening an adapter and capturing the packetsNow that we've seen how to obtain an adapter to play with, let's start the real job, opening an adapter and capturing some traffic. In this lesson we'll write a program that prints some information about each packet flowing through the adapter
 Capturing the packets without the callbackThe example program in this lesson behaves exactly like the previous program (Opening an adapter and capturing the packets), but it uses pcap_next_ex() instead of pcap_loop()
 Filtering the trafficOne of the most powerful features offered by WinPcap (and by libpcap as well) is the filtering engine. It provides a very efficient way to receive subsets of the network traffic, and is (usually) integrated with the capture mechanism provided by WinPcap. The functions used to filter packets are pcap_compile() and pcap_setfilter()
 Interpreting the packetsNow that we are able to capture and filter network traffic, we want to put our knowledge to work with a simple "real world" application
 Handling offline dump filesIn this lession we are going to learn how to handle packet capture to a file (dump to file). WinPcap offers a wide range of functions to save the network traffic to a file and to read the content of dumps – this lesson will teach how to use all of these functions. We'll see also how to use the kernel dump feature of WinPcap to obtain high-performance dumps (NOTE: At the moment, due to some problems with the new kernel buffer, this feature has been disabled)
 Sending PacketsAlthough the name WinPcap indicates clearly that the purpose of the library is packet capture, other useful features for raw networking are provided. Among them, the user can find a complete set of functions to send packets
 Gathering Statistics on the network trafficThis lesson shows another advanced feature of WinPcap: the ability to collect statistics about network traffic. The statistical engine makes use of the kernel-level packet filter to efficiently classify the incoming packet. You can take a look at the NPF driver internals manual if you want to know more details
 Filtering expression syntax
Note: this document has been drawn from the tcpdump man page. The original version can be found at  www.tcpdump.org.
 
wpcap filters are based on a declarative predicate syntax. A filter is an ASCII string containing a filtering expression. pcap_compile() takes the expression and translates it in a program for the kernel-level packet filter.

The expression selects which packets will be dumped. If no expression is given, all packets on the net will be accepted by the kernel-level filtering engine. Otherwise, only packets for which expression is `true' will be accepted.

The expression consists of one or more primitives. Primitives usually consist of an id (name or number) preceded by one or more qualifiers. There are three different kinds of qualifier:

type
qualifiers say what kind of thing the id name or number refers to. Possible types are host, net and port. E.g., `host foo', `net 128.3', `port 20'. If there is no type qualifier, host is assumed.
dir
qualifiers specify a particular transfer direction to and/or from id. Possible directions are src, dst, src or dst and src and dst. E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. If there is no dir qualifier, src or dst is assumed. For `null' link layers (i.e. point to point protocols such as slip) the inbound and outbound qualifiers can be used to specify a desired direction.
proto
qualifiers restrict the match to a particular protocol. Possible protos are: ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp and udp. E.g., `ether src foo', `arp net 128.3', `tcp port 21'. If there is no proto qualifier, all protocols consistent with the type are assumed. E.g., `src foo' means `(ip or arp or rarp) src foo' (except the latter is not legal syntax), `net bar' means `(ip or arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.

[`fddi' is actually an alias for `ether'; the parser treats them identically as meaning ``the data link level used on the specified network interface.'' FDDI headers contain Ethernet-like source and destination addresses, and often contain Ethernet-like packet types, so you can filter on these FDDI fields just as with the analogous Ethernet fields. FDDI headers also contain other fields, but you cannot name them explicitly in a filter expression.

Similarly, `tr' is an alias for `ether'; the previous paragraph's statements about FDDI headers also apply to Token Ring headers.]

In addition to the above, there are some special `primitive' keywords that don't follow the pattern: gateway, broadcast, less, greater and arithmetic expressions. All of these are described below.

More complex filter expressions are built up by using the words and, or and not to combine primitives. E.g., `host foo and not port ftp and not port ftp-data'. To save typing, identical qualifier lists can be omitted. E.g., `tcp dst port ftp or ftp-data or domain' is exactly the same as `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.

Allowable primitives are:

dst host host
True if the IPv4/v6 destination field of the packet is host, which may be either an address or a name.
src host host
True if the IPv4/v6 source field of the packet is host.
host host
True if either the IPv4/v6 source or destination of the packet is host. Any of the above host expressions can be prepended with the keywords, ip, arp, rarp, or ip6 as in:
ip host host
which is equivalent to:
ether proto \ip and host host
If host is a name with multiple IP addresses, each address will be checked for a match.
ether dst ehost
True if the ethernet destination address is ehost. Ehost may be either a name from /etc/ethers or a number (see ethers(3N) for numeric format).
ether src ehost
True if the ethernet source address is ehost.
ether host ehost
True if either the ethernet source or destination address is ehost.
gateway host
True if the packet used host as a gateway. I.e., the ethernet source or destination address was host but neither the IP source nor the IP destination was host. Host must be a name and must be found both by the machine's host-name-to-IP-address resolution mechanisms (host name file, DNS, NIS, etc.) and by the machine's host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.). (An equivalent expression is
ether host ehost and not host host
which can be used with either names or numbers for host / ehost.) This syntax does not work in IPv6-enabled configuration at this moment.
dst net net
True if the IPv4/v6 destination address of the packet has a network number of net. Net may be either a name from /etc/networks or a network number (see networks(4) for details).
src net net
True if the IPv4/v6 source address of the packet has a network number of net.
net net
True if either the IPv4/v6 source or destination address of the packet has a network number of net.
net net mask netmask
True if the IP address matches net with the specific netmask. May be qualified with src or dst. Note that this syntax is not valid for IPv6 net.
net net/len
True if the IPv4/v6 address matches net with a netmask len bits wide. May be qualified with src or dst.
dst port port
True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a destination port value of port. The port can be a number or a name used in /etc/services (see tcp(4P) and udp(4P)). If a name is used, both the port number and protocol are checked. If a number or ambiguous name is used, only the port number is checked (e.g., dst port 513 will print both tcp/login traffic and udp/who traffic, and port domain will print both tcp/domain and udp/domain traffic).
src port port
True if the packet has a source port value of port.
port port
True if either the source or destination port of the packet is port. Any of the above port expressions can be prepended with the keywords, tcp or udp, as in:
tcp src port port
which matches only tcp packets whose source port is port.
less length
True if the packet has a length less than or equal to length. This is equivalent to:
len <= length.
greater length
True if the packet has a length greater than or equal to length. This is equivalent to:
len >= length.
ip proto protocol
True if the packet is an IP packet (see ip(4P)) of protocol type protocol. Protocol can be a number or one of the names icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, or tcp. Note that the identifiers tcp, udp, and icmp are also keywords and must be escaped via backslash (\), which is \\ in the C-shell. Note that this primitive does not chase the protocol header chain.
ip6 proto protocol
True if the packet is an IPv6 packet of protocol type protocol. Note that this primitive does not chase the protocol header chain.
ip6 protochain protocol
True if the packet is IPv6 packet, and contains protocol header with type protocol in its protocol header chain. For example,
ip6 protochain 6
matches any IPv6 packet with TCP protocol header in the protocol header chain. The packet may contain, for example, authentication header, routing header, or hop-by-hop option header, between IPv6 header and TCP header. The BPF code emitted by this primitive is complex and cannot be optimized by BPF optimizer code in tcpdump, so this can be somewhat slow.
ip protochain protocol
Equivalent to ip6 protochain protocol, but this is for IPv4.
ether broadcast
True if the packet is an ethernet broadcast packet. The ether keyword is optional.
ip broadcast
True if the packet is an IP broadcast packet. It checks for both the all-zeroes and all-ones broadcast conventions, and looks up the local subnet mask.
ether multicast
True if the packet is an ethernet multicast packet. The ether keyword is optional. This is shorthand for `ether[0] & 1 != 0'.
ip multicast
True if the packet is an IP multicast packet.
ip6 multicast
True if the packet is an IPv6 multicast packet.
ether proto protocol
True if the packet is of ether type protocol. Protocol can be a number or one of the names ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp, ipx, or netbeui. Note these identifiers are also keywords and must be escaped via backslash (\).
[In the case of FDDI (e.g., `fddi protocol arp') and Token Ring (e.g., `tr protocol arp'), for most of those protocols, the protocol identification comes from the 802.2 Logical Link Control (LLC) header, which is usually layered on top of the FDDI or Token Ring header.
When filtering for most protocol identifiers on FDDI or Token Ring, tcpdump checks only the protocol ID field of an LLC header in so-called SNAP format with an Organizational Unit Identifier (OUI) of 0x000000, for encapsulated Ethernet; it doesn't check whether the packet is in SNAP format with an OUI of 0x000000.
The exceptions are iso, for which it checks the DSAP (Destination Service Access Point) and SSAP (Source Service Access Point) fields of the LLC header, stp and netbeui, where it checks the DSAP of the LLC header, and atalk, where it checks for a SNAP-format packet with an OUI of 0x080007 and the Appletalk etype.
In the case of Ethernet, tcpdump checks the Ethernet type field for most of those protocols; the exceptions are iso, sap, and netbeui, for which it checks for an 802.3 frame and then checks the LLC header as it does for FDDI and Token Ring, atalk, where it checks both for the Appletalk etype in an Ethernet frame and for a SNAP-format packet as it does for FDDI and Token Ring, aarp, where it checks for the Appletalk ARP etype in either an Ethernet frame or an 802.2 SNAP frame with an OUI of 0x000000, and ipx, where it checks for the IPX etype in an Ethernet frame, the IPX DSAP in the LLC header, the 802.3 with no LLC header encapsulation of IPX, and the IPX etype in a SNAP frame.]
decnet src host
True if the DECNET source address is host, which may be an address of the form ``10.123'', or a DECNET host name. [DECNET host name support is only available on Ultrix systems that are configured to run DECNET.]
decnet dst host
True if the DECNET destination address is host.
decnet host host
True if either the DECNET source or destination address is host.
ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
Abbreviations for:
ether proto p
where p is one of the above protocols.
lat, moprc, mopdl
Abbreviations for:
ether proto p
where p is one of the above protocols. Note that tcpdump does not currently know how to parse these protocols.
vlan [vlan_id]
True if the packet is an IEEE 802.1Q VLAN packet. If [vlan_id] is specified, only true is the packet has the specified vlan_id. Note that the first vlan keyword encountered in expression changes the decoding offsets for the remainder of expression on the assumption that the packet is a VLAN packet.
tcp, udp, icmp
Abbreviations for:
ip proto p or ip6 proto p
where p is one of the above protocols.
iso proto protocol
True if the packet is an OSI packet of protocol type protocol. Protocol can be a number or one of the names clnp, esis, or isis.
clnp, esis, isis
Abbreviations for:
iso proto p
where p is one of the above protocols. Note that tcpdump does an incomplete job of parsing these protocols.
expr relop expr
True if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an arithmetic expression composed of integer constants (expressed in standard C syntax), the normal binary operators [+, -, *, /, &, |], a length operator, and special packet data accessors. To access data inside the packet, use the following syntax:
proto [ expr : size ]
Proto is one of ether, fddi, tr, ip, arp, rarp, tcp, udp, icmp or ip6, and indicates the protocol layer for the index operation. Note that tcp, udp and other upper-layer protocol types only apply to IPv4, not IPv6 (this will be fixed in the future). The byte offset, relative to the indicated protocol layer, is given by expr. Size is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one. The length operator, indicated by the keyword len, gives the length of the packet.

For example, `ether[0] & 1 != 0' catches all multicast traffic. The expression `ip[0] & 0xf != 5' catches all IP packets with options. The expression `ip[6:2] & 0x1fff = 0' catches only unfragmented datagrams and frag zero of fragmented datagrams. This check is implicitly applied to the tcp and udp index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an intervening fragment.

Some offsets and field values may be expressed as names rather than as numeric values. The following protocol header field offsets are available: icmptype (ICMP type field), icmpcode (ICMP code field), and tcpflags (TCP flags field).

The following ICMP type field values are available: icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply.

The following TCP flags field values are available: tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-push, tcp-ack, tcp-urg.

Primitives may be combined using:

A parenthesized group of primitives and operators (parentheses are special to the Shell and must be escaped).
Negation (`!' or `not').
Concatenation (`&&' or `and').
Alternation (`||' or `or').

Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit and tokens, not juxtaposition, are now required for concatenation.

If an identifier is given without a keyword, the most recent keyword is assumed. For example,

not host vs and ace
is short for
not host vs and host ace
which should not be confused with
not ( host vs or ace )

Expression arguments can be passed to tcpdump as either a single argument or as multiple arguments, whichever is more convenient. Generally, if the expression contains Shell metacharacters, it is easier to pass it as a single, quoted argument. Multiple arguments are concatenated with spaces before being parsed.

 Using WinPcap in your programs

Creating an application that uses wpcap.dll

To create an application that uses wpcap.dll with Microsoft Visual C++, follow these steps:

  • Include the file pcap.h at the beginning of every source file that uses the functions exported by library.
  • If your program uses Win32 specific functions of WinPcap, remember to include WPCAP among the preprocessor definitions.
  • If your program uses the remote capture capabilities of WinPcap, add HAVE_REMOTE among the preprocessor definitions. Do not include remote-ext.h directly in your source files.
  • Set the options of the linker to include the wpcap.lib library file specific for your target (x86 or x64). wpcap.lib for x86 can be found in the \lib folder of the WinPcap developer's pack, wpcap.lib for x64 can be found in the \lib\x64 folder.
  • Set the options of the linker to include the winsock library file ws2_32.lib. This file is distributed with the C compiler and contains the socket functions for Windows. It is needed by some functions used by the samples in the tutorial.

How to properly set Microsoft Visual Studio

Visual Studio 6

  • To add a preprocessor definition, you must select Settings from the Project menu, then select C/C++ from the tab control, and under the category General, you must add the definition under the Preprocessor Definitions text box.
  • To add a new library to the project with Microsoft Visual C++, you must select Settings from the Project menu, then select Link from the tab control, and then add the name of the new library in the Object/library modules editbox.
  • To add a new path where Microsoft Visual C++ will look for the libraries, you must select Options from the Tools menu, then Directories from the tab control, Library files from the Show directories for combobox, and the add the path in the Directories box.
  • To add a new path where Microsoft Visual C++ will look for include files, you must select Options from the Tools menu, then Directories from the tab control, Include files from the Show directories for combobox, and the add the path in the Directories box.

Visual Studio 2005 (needed to compile x64 applications)

  • To add a preprocessor definition, you must select Properties from the Project menu, then select C/C++ from the list control on the left, and under the category Preprocessor, you must add the definition under the Preprocessor Definitions text box.
  • To add a new library to the project, you must select Properties from the Project menu, then select Linker from the list control on the left, and under the category Input add the name of the new library in the Additional Dependencies text box.
  • To add a new path where Microsoft Visual Studio will look for the libraries, you must select Options from the Tools menu, then Project and Solutions from the list control on the left, VC++ Directories, then choose Library Files in the Show directories for combobox, and the add the path in the box below.
  • To add a new path where Microsoft Visual Studio will look for the include files, you must select Options from the Tools menu, then Project and Solutions from the list control on the left, VC++ Directories, then choose Include Files in the Show directories for combobox, and the add the path in the box below.

 

Sample programs

A couple of sample programs are provided to show the usage of the WinPcap API. The source of the examples, along with all the files needed to compile and run them, can be found in the Developer's Pack.  For didactic purpose we provide here a browsable version of the code: it is possible to click on the variables and functions to jump the documentation of each of them. For a more complete set of samples, try WinPcap Tutorial Section.

 Remote Capture Using WinPcap Remote Capture

WinPcap comes with Remote Capture capabilities. This is an highly experimental feature that allows to interact to a remote machine and capture packets that are being transmitted on the remote network.

This requires a remote daemon (called rpcapd) which performs the capture and sends data back and a local client that sends the appropriate commands and receives the captured data.

WinPcap extends the standard WinPcap code in such a way that all WinPcap-based tools can expoit remote capture capabilities. For instance, the capabillity to interact with a remote daemon are added to the client software without any explicit modification to it. Vice versa, the remote daemon must be explicitely installed (and configured) on the remote machine.

Remote Capture Running Modes

The Remote Capture Protocol (RPCAP) can work in two modes:

  • Passive Mode (default): the client (e.g. a network sniffer) connects to the remote daemon, it sends them the appropriate commands, and it starts the capture.
  • Active Mode: the remote daemon try to establish a connection toward the client (e.g. the network sniffer); then, the client sends the appropriate commands to the daemon and it starts the capture. This name is due to the fact thet the daemon becomes active instead of waiting for new connections.

The Active Mode is useful in case the remote daemon is behind a firewall and it cannot receive connections from the external world. In this case, the daemon can be configured to establish the connection to a given host, which will have been configured in order to wait for that connection. After establishing the connection, the protocol continues its job in almost the same way in both Active and Passive Mode.

Analyzer (http://analyzer.polito.it/30alpha/) has a set of commands (in the Capture menu) that allows you to accept a remote connection and then start the capture on the remote device. Currently, Analyzer is the only tool that is able to work in active mode, since it requires some modifications to the application code.

Configuring the Remote Daemon (rpcapd)

The Remote Daemon is a standard Win32 executable running either in console mode or as a service. The executable can be found in the WinPcap folder and it has the following syntax:

        rpcapd [-b <address>] [-p <port>] [-6] [-l <host_list>] [-a <host,port>] 
               [-n] [-v] [-d] [-s <file>] [-f <file>]

The daemon can be compiled and it is actually working on Linux as well.

Here there is a brief description of the allowed commands:

Switch Description
-b <address>
It sets the address the daemon has to bind to (either numeric or literal). Default: it binds to all local IPv4 and IPv6 addresses.
-p <port>
It sets the port the daemon has to bind to. Default: it binds to port 2002.
-4
It binds only to IPv4 addresses. Default: both IPv4 and IPv6 waiting sockets are used.
-l <host_list_file>
It specifies a file that keeps the list of the hosts which are allowed to connect to this daemon (if more than one, the file keeps them one per line). We suggest to use literal names (instead of numeric ones) in order to avoid problems with different address families (IPv4 and IPv6).
-n
It permits NULL authentication (usually used with '-l', that guarantees that only the allowed hosts can connect to the daemon). Default: the username/password authentication mechanism is required.
-a <host, port>
It forces the daemon to run in active mode and to connect to 'host' on port 'port'. This does not exclude that the daemon is still able to accept passive connections.
-v
It forces the daemon to run in active mode only (default: the daemon always accepts active connections, even if the '-a' switch is specified).
-d
Forces the daemon to run in background, i.e. as a daemon (UNIX only) or as a service (Win32 only). Warning (Win32): this switch is provided automatically when WinPcap installs this daemon into the Win32 services (control panel - administrative tools - services).
-s <file>
It saves the current configuration to file.
-f <file>
It loads the current configuration from file; all the switches specified from the command line are ignored and the file settings are used instead.
-h
It prints an help screen.

Installing the remote daemon

The remote daemon is installed automatically when installing WinPcap. The installation process places the rpcapd file into the WinPcap folder. This file can be executed either from the command line, or as a service. For instance, the installation process updates the list of available services list and it creates a new item (Remote Packet Capture Protocol v.0 (experimental) ). To avoid security problems, the service is inactive and it has to be started manually (control panel - administrative tools - services - start).

The service has a set of "standard" parameters, i.e. it it launched with the "-d" flag (in orde to make it running as a service) and the "-f rpcapd.ini" flag. The user can create a file called rpcapd.ini in the same folder of the executable, and put the configuration commands in there. In order for the service to execute the commands, you have to stop and restart it again (i.e. the initialization file is parsed only at the beginning). Viceversa, the UNIX version of rpcapd is able to read the configuration file when sending a kill -HUP signal to it. In that case, all the existing connections remain in place, while the new connections will be created according to the new parameters.

In case the user does not want to create the configuration file manually, it can launch rpcapd with the requested parameters plus the "-s filename" one. The daemon will parse all the parameters and save them into the specified configuration file.

Starting the remote daemon as a standard executable

The rpcapd executable can be launched directly, i.e. it can run in the foreground as well (not as a daemon/service). The procedure is quite simple: you have to invoke the executable from the command line with all the requested parameters but the "-d" flag. The capture server will start in the foreground.

Starting a capture on a remote machine

If you are using a tool that is already aware of the remote capture (like Analyzer), everything is simple. The capture wizard will help you to locate the appropriate interface on the remote machine.

If your preferred tool is not aware of the remote capture, you can still use the remote capture. In this case you have to read the next Section.

Be carefully: the capture server (rpcapd) must be up and running on the remote machine.

New string specifiers for interface selection

If your preferred tool is not aware of the remote capture, the only thing you must do is to insert, as interface specifier, the indication of the remote machine you want to contact. The following forms are allowed:

Adapter String Description
file://filename
It opens a local file.
rpcap://host.foo.bar/adaptername
It opens a remote adapter; the host is specified by means of the literal name, without port number (i.e. it uses the RPCAP default port).
rpcap://host.foo.bar:1234/adaptername
It is the same as before, but it uses a different port number.
rpcap://10.11.12.13/adaptername
It opens a remote adapter, but the host is specified by means of an IPv4 numeric address, without port number (i.e. it uses the RPCAP default port).
rpcap://10.11.12.13:1234/adaptername
It is the same as before, but it uses a different port number.
rpcap://[10.11.12.13]:1234/adaptername
It is the same as before, but the numeric address is specified within square brackets (like IPv6 addresses).
rpcap://[1:2:3::4]/adaptername
It opens a remote adapter, but the host is specified by means of an IPv6 numeric address, without port number (i.e. it uses the RPCAP default port). In case of IPv6 addresses you MUST use the square brackets.
rpcap://[1:2:3::4]:1234/adaptername
It is the same as before, but it uses a different port number.
rpcap://adaptername
It opens a local adapter, without using the RPCAP protocol.
adaptername
It opens a local adapter; it is kept for compability, but it is strongly discouraged.
(NULL)
It opens the first local adapter; it is kept for compability, but it is strongly discouraged.

The following formats are not allowed:

Adapter String Description
rpcap://
It cannot be used to open the first local adapter.
rpcap://hostname/
It cannot be used to open the first remote adapter.

Installing the Remote Capture Daemon in UNIX

The WinPcap source archive can be compiled in UNIX as well. Currently, remote capture has been tested on Linux and BSD. What you have to do is:

  • download the WinPcap sources
  • unpack the sources
    • we suggest to use the unzip -a command in order to convert DOS files to UNIX ones
  • move to the libpcap folder
  • type:
    • ./configure
    • Warning: in case the previous step reports an error, please regenerate the configure file using automake (version 2.50 or higher required)
    • make
  • move to the rpcapd folder
  • type make

The remote capture capabilities are turned on by default on Linux and FreeBSD. In case you do not want remote capture capabilities in libpcap, you can type

    ./configure --disable-remote

at the "configure" step. All the possible flags are listed when typing ./configure --help.

What you obtained right now, is:

  • a library file (libpcap.a), which can be linked to other applications (like tcpdump) in order to enable the remote capture for them.
  • an executable (rpcapd) that is the remote daemon

Warning: in order to run the rpcapd daemon, the program must either

  • run as root (or)
  • run as user, but it must be owned by root and must be SUID root (chmod u+s rpcapd)

Known bugs

FreeBSD: the first time you call the pcap_stat(), the function takes several seconds to return. Therefore, programs like Analyzer seem to hang up for 20-30 seconds at the beginning of the capture (if this is done with BSD as a remote probe). We're investigating to solve this issue.

For any question, please refer to the WinPcap help page.

 Exported Structures and Definitions
 Strings related to the new source syntax
 Identifiers related to the new source syntax
 Flags defined in the pcap_open() function
 Sampling methods defined in the pcap_setsampling() function
 Authentication methods supported by the RPCAP protocol
 Exported Functions
 Internal Functions
 Internal Structures and Definitions

documentation. Copyright (c) 2002-2005 Politecnico di Torino. Copyright (c) 2005-2010 CACE Technologies. Copyright (c) 2010-2013 Riverbed Technology. All rights reserved.