The Internals of Libpcap: A Case Study
Essay by review • February 9, 2011 • Case Study • 4,158 Words (17 Pages) • 3,007 Views
THE INTERNALS OF LIBPCAP: A CASE STUDY
BY: VIVEK GUPTA,
STUDENT, MS(IT), DA-IICT, GANDHINAGAR.
PHONE: +919426330172
EMAIL: VIVEK_GUPTA@DA-IICT.ORG
KEYWORDS:
1. BSD: Berkeley Software Design.
2. TCP: Transmission Control Protocol
3. IP: Internet Protocol.
4. BPF: BSD Packet Filter.
5. DLPI: Data Link Provider Interface.
6. libpcap: Packet Capture Library.
7. JNI: Java Native Interface.
8. NIT: Network Interface Tap.
9. CSPF: CMU/Stanford Packet filter.
INTRODUCTION:
Packet capture is a fundamental mechanism in network management. It is used to support a wide range of network operational tasks, such as fault detection, protocol analysis, and security assessment. Libpcap is one of the most common and basic libraries available for the purpose of packet capture. Inspite of the fact that the library has existed for a considerably long time there is no document which explains the underlying concept about the working of this library. In this paper, I would be presenting the system level working of libpcap, i.e., concept as well as coding. The paper is intended to providing the reader with concepts, which will enhance his or her understanding about the packet capture library. The reader should be able to design and code library of the similar kind. This working is explained with reference to a network-monitoring tool. I have tried to explain the core concept as well as its application within the library in the paper.
Packet Capture in simple words means "to grab packets". In order to grab packets we need to access the primary facility provided by the operating system so that there is access to packets in their raw form. To make a network monitoring application we need to capture all the packets over the network. The packet capture library allows us to intercept any packet that is seen by the network interface. We need to put the interface on that network into a "promiscuous" mode, so that we can capture all packets on the network segment on which it is running. Once the packet is captured it is handed off to the operating system, which must determine what type of packet it is. The operating system then strips off the Ethernet header of the packet and looks at the upper layers. By using the libpcap library, it is possible to write our own network monitoring tools. Libpcap provides us with a portable framework for low-level network monitoring. The general layout of a Packet Capture Library based monitoring tool is as follows: [1]
1. Setting the device: We begin by determining which interface we want to sniff on. In Linux this may be something like eth0, in BSD it may be xl1, etc. We can either define this device in a string, or we can ask pcap to provide us with the name of an interface that will do the job.
2. Initialization of pcap: At this step we tell pcap what device we are sniffing on. This part consists of initialization of the capture interface, which includes setting the interface in promiscuous mode.
3. Filtering traffic: In the event, when a user wants to sniff for specific traffic (e.g.: only TCP/IP packets or only packets going to port 23) we must create a rule set, "compile" it, and apply it. This is an optional step.
4. Actual Sniffing: Finally, pcap is made to enter its primary execution loop. In this state, pcap waits until it has received the desired packets. Every time it gets a new packet in, it calls another function that is already defined. The function that it calls can be customized.
5. Wrapping up: After the sniffing needs are satisfied, the session is closed.
In this paper, I will be presenting the internal working of libpcap library with respect to these steps. The next section titled "Background" gives us a brief idea about the history of the libpcap library. In the following section titled "Internals of libpcap" I will be covering the concept and associated coding for the library. This has been explained with respect to the steps stated above. Lastly I would be concluding by describing my experience with the libpcap library and java implementation of the libpcap library.
BACKGROUND:
Libpcap is a system-independent interface for user-level packet capture. Libpcap provides a portable framework for low-level network monitoring. The three common methods to access the data link layer under UNIX are BSD Packet Filter (BPF), SVR4 Data Link Provider Interface (DLPI) and SOCKET_PACKET type sockets interface. The libpcap works on all three interfaces and by using the libpcap library programs can be made independent of the actual data link access provided by the operating system [2]. The libpcap interface supports a filtering mechanism based on the architecture in the BSD packet filter. BPF is described in the 1993 Winter Usenix paper "The BSD Packet Filter: A New Architecture for User-level Packet Capture". The authors of this paper Steven McCanne and Van Jacobson have comprehensively explained the concept behind BPF. They have mentioned about the architectural improvements that they have made to the previously existing designs used in UNIX. These changes were made to use the facility available with the modern PCs. They have also made comparative study with similar packet filters like SunOS NIT. The authors also claimed that BPF offers substantial performance improvement over existing packet capture facilities 10 to 150 times faster than Sun's NIT and 1.5 to 20 times faster than CSPF on the same hardware and traffic mix [3].
Libpcap provides user-level subroutines that interface with the BPF to allow users access for reading unprocessed network traffic. Although most packet capture interfaces support in-kernel filtering, libpcap utilizes in-kernel filtering only for the BPF interface. On systems that don't have BPF, all packets are read into user-space and the BPF filters are evaluated in the libpcap library, incurring added overhead. The original authors of the library are Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. The library is now maintained by the Tcpdump group
...
...