npf.txt

来自「用来监视网络通信数据的源代码和应用程序,方便网络程序底层开发.」· 文本 代码 · 共 132 行

/** @ingroup internals
 */


/** @defgroup NPF NPF driver internals manual 
 *  @{
@}
 
\htmlonly

&nbsp;<p>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.&nbsp;</p>
<p>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.</p>
<p>The following paragraphs will describe the interaction of NPF with the
OS and its basic structure.</p>
<h2>NPF and NDIS</h2>
<p>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.</p>
<p>NDIS supports three types of network drivers:</p>
<ol>
  <li><strong>Network interface card or NIC drivers</strong>. 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.
    <ul>
      <li>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.<br>
        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.
      <li>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.&nbsp;</li>
    </ul>
  <li><strong>Intermediate drivers</strong>. 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.
  <li><b>Transport drivers or protocol drivers</b>. 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.</li>
</ol>
<p>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.</p>
<p>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.&nbsp;</p>
<p>Next figure shows the position of NPF inside the NDIS stack:</p>
\endhtmlonly
\image html ndis.gif "Figure 1: NPF inside NDIS"
\htmlonly
<p>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.</p>
<p>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.</p>

<h2>NPF structure basics</h2>

<p>Next figure shows the structure of WinPcap, with particular reference to the
NPF driver.</p>

<p>&nbsp; \endhtmlonly 
\image html npf.gif "Figure 2: NPF device driver" 
\htmlonly

<p>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.</p>
<h4>Packet Capture</h4>
<p>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.&nbsp;
</p>
<p>The capture process relies on two main components:</p>
<ul>
  <li>
    <p>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 <b>BSD Packet Filter</b> (BPF), a
    virtual processor able to execute filtering programs expressed in a
    pseudo-assembler and created at user level. The
    the application takes a user-defined filter (e.g. 損ick up all UDP packets