WinDump is the Win32 porting of one of the most used UNIX network capture and analysis programs: TCPDump. It allows the user to capture and view the packets that are transmitted onto the network and that are received by it interface. It can run on Windows 95/98 and on Windows NT. WinDump is written to work primarily with Ethernet networks, but can be used without problems on the networks with a packet length smaller than Ethernet one (for example we tested it successfully on PPP connections). This limitation is mainly due to the underlying layers, i.e. libpcap and the packet driver, whose behavior is not completely network-independent and has been tuned mainly for Ethernet networks.
Goal was to make a clean porting, maintaining the structure of the original version where possible, taking care at same time of the capture performance and the cleanliness of the code. WinDump uses the packet capture library (libpcap) for the capture process, a library written originally for UNIX that implements a set of high level capture functions. This library has been porting on Windows and it uses the NDIS packet capture driver, a device driver that interacts with NDIS to capture the packets from the network. This driver is system dependent so there are two versions: packet.vxd for Windows 95 and packet.sys for Windows NT. The pcap library and the packet capture driver can be a very powerful base to write network capture and monitor application for the Windows environment. They are also very useful to make the porting for Windows of the applications already written for UNIX. Furthermore, the project has a didactic usefulness: in fact, the source code of the entire project is freely available under the GNU General Public License and can be used to learn how a capture application works.
To capture the packets passing on a network, an application like WinDump needs to interact in a direct way with the network hardware. For this reason, in order to run a program that captures packets, the operating system must offer a set of capture primitives to communicate and receive data directly from the network adapter. The task of these primitives is essentially to capture the packets from the network hiding to the application the interaction with the network adapter, and to transfer them to the calling programs. This is heavily system dependent, so it is quite different in the various operating systems. The packet capture section of the kernel should be quick and efficient because it must be able to capture packets on high-speed LANs with (maybe) heavy traffic, limiting losses of packets. It should also be general and flexible in order to be used by different types of applications (analyzers, network monitors, network test applications...).
The capture application receives the packets from the system, interprets and processes them, and outputs them to the user in a comprehensible and productive way. It should be easy to use, system independent, modular and expandable, so to support the higher number of protocols and to make it possible to easily add a new protocol. These features are indispensable because of the high number of network protocols currently available and the speed they changes, so completeness and expandability are important in a capture program.
WinDump.exe is only the upper part of a packet capture stack, made of a module that runs at the kernel level and one that runs at user level. These modules have different purposes and are independent and isolated one from another. The first runs at ring 0 on Intel based machines, while the second runs at ring 3 like a normal Windows program. The kernel part is Windows specific, and the Windows 95 version of it is quite different from the Windows NT one. The user-level part is very similar to the UNIX implementation, and it is identical under Win95 and WinNT. The high-level structure of WinDump is shown in figure 1.1.
figure 1.1: structure of the WinDump capture stack
We will now describe the two modules, their behavior and the architectural choices under them.
The WinDump program is the higher part of the capture stack and manages the interaction between the user and the system. It gets the users inputs (for example, which packets must be captured and in which way they must be showed to the user) from the command line and outputs the results on the screen. The WinDump executable running on a Windows platform is identical to the TcpDump executable running on a UNIX workstation from the user viewpoint. This means that the two programs have almost the same input parameters and the same output format.
TcpDump on UNIX makes use of a library for the packet capture process, called pcap library or libpcap, a system-independent interface for user-level packet capture. Libpcap provides a set of functions that an application can use to capture packets from a network, in a high-level way independent from the hardware and the operating system. It is important to note that libpcap is a general-purpose capture library, and in the UNIX world is used not only by TcpDump, but also by other network tools and applications. TcpDump does not interact directly with hardware, but uses the functions exported by libpcap to capture the packets and to communicate with the network adapter. In this way it is essentially system-independent and can easily be ported to any system on which the libpcap library works. For this reason the WinDump project includes a full porting of the libpcap library toward the Win32 platform. Furthermore, the pcap library is not limited to be used with WinDump, and we think that it can be very useful to people that want to convert network monitors and analyzers from the UNIX world, and it can be also a powerful base to create new network tools for the Win32 environment. Therefore, we tried to maintain the structure of the original version in our implementation. We modified only the section of libpcap that communicates with the kernel, implementing the interaction with the NDIS packet capture driver. A important characteristic of libpcap for Win32 is that there is only a version that works both on Windows 95 and on Windows NT. This can be obtained putting a dll, called packet.dll, between libpcap and the capture driver, so that the calls to the driver are the same in the two Windows environments. In this way, if a network tool uses libpcap, it works on Windows 95 and Windows NT without any modifications.
The porting of TcpDump, once a working implementation of libpcap for Win32 was ready, was quite trivial. Only few differences were introduced in WinDump, adding a pair of new switches:
FULVIO Una cosa imporaqnte (non so se la dici successivamente) e' capire esattamente dove si situa lipbpcap. Le libpcap sono nel driver? Sono nell'applicazione? Non e' assolutamente chiaro che (se capisco bene) le libpcap sono inglobate praticamente nell'applicazione, ossia in windump all'atto della compilazione. Quindi non e' chiaro che rapporto esiste tra le libpcap e il packet driver.
The basic role of the kernel part is to take the packets from the network and to transfer them to the application level. We implemented it as a kernel driver (packet.sys) under Windows NT and as a Virtual Device Driver (packet.vxd) under Windows 95. Applications can have access to the capture driver in the same way like a normal file, reading the data that comes from the network from it. The capture driver can be used by any Win32 application that needs to capture packets. The interaction with the packet capture driver usually passes through the packet.dll dynamic link library, which makes easier to write programs that use the driver. Packet.dll is a dynamic link library that interfaces the NDIS packet capture driver with the applications that use it. The DLL implements a set of functions that make simpler the communication with the driver, avoiding the use of things such system calls or IOCTLs to use it.
The packet capture driver interacts directly with NDIS. NDIS is a part of the network code of Win32, and is responsible of the management of the various network adapters and of the communication between the adapters and the software portions that implement the protocols. According to the NDIS terminology, a driver that drives a network adapter is called network driver, and a driver that implement a protocol (like NetBEUI or TCP-IP) is called protocol driver. The packet capture driver needs to communicate both with the network drivers (to get data from them) and with the user-level application (to give them the packets), so it works as a protocol driver.
Figure 1.2 shows the position of the packet capture driver in the Win32 architecture.
figure 1.2: Win32 and the Packet capture driver
A basic network capture driver can be quite simple. It needs only to read the packets from the network and copy them to the application. However, in order to obtain acceptable performances, substantial improvements have to be done to this basic structure. The most important are:
These features are implemented according to the design of the BSD Packet Filter (BPF), a kernel architecture for packet capture proposed by Steven McCanne and Van Jacobson that is the base of the TcpDump (FULVIO QUi fai un po' insalata tra tcpdump, lipbcap,.... Il bpf e' alla base di Lipbcap, non tcpdump) capture stack on UNIX. BPF has two main components: the network tap and the packet filter. The network tap collects copies of packets from the network device drivers and delivers them to listening applications. The filter decides if a packet should be accepted and copied to the listening application. The filter is implemented as a register machine that interprets filtering programs created by the applications. Our capture driver can collect and deliver the packets like the network tap, and implements a filtering register machine compatible with the BPF one. These features are quite important because they allow us to make a kernel capture system compatible with libpcap and TcpDump, thus making the porting of them simple and clean. (FULVIO: l'avrai gia' detto almeno 3-4 volte...)
It must be noted that not all the UNIX versions have filtering capabilities in the kernel, but the pcap library can compensate this lack. It is in fact able to filter the packets in a BPF compatible way at user level if used in a system without the BPF filter machine in the kernel. This solution has however limited performances, mainly for two reasons:
FULVIO Il fatto che non tutti gli UNIX non abbiano il BPF nel kernel non vuol dire (credo) che non abbiamo il buffering. O no?
Therefore, the implementation of the filtering process in the WinDump project is done at the kernel level, i.e. in the driver. (FULVIO QUi c'e' nuovamente quella confusione di prima. Che vuol dire "nel driver"? Packet o libpcap?).