▼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:
- 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.
- 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.
- 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:
- 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.
- 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:
- 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.
- 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:
- Open a DOS shell
- Go to the VisualC++ BIN directory (for example C:\DEVSTUDIO\VC\BIN) and
execute the command
Vcvars32
- 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)
- Go to the DDK directory (for example C:\DDK) and execute the command
Ddkenv 32 net
- 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 WinPcap | This 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 list | Typically, 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 devices | Lesson 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 packets | Now 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 callback | The 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 traffic | One 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 packets | Now 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 files | In 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 Packets | Although 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 traffic | This 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 | |