29.1 Introduction
Providing access to the datalink layer for an
application is a powerful feature that is available with most
current operating systems. This provides the following
capabilities:
-
The ability to watch the packets received by the
datalink layer, allowing programs such as tcpdump to be
run on normal computer systems (as opposed to dedicated hardware
devices to watch packets). When combined with the capability of the
network interface to go into a promiscuous mode, this allows an application
to watch all the packets on the local cable, not just the packets
destined for the host on which the program is running.
This ability is less useful in switched
networks, which have become quite common. This is because the
switch only passes traffic to a port if it is addressed to the
device or devices attached to that port (unicast, multicast, or
broadcast). To monitor traffic carried on other ports of the
switch, the switch port must be configured to receive other
traffic, often called monitor mode
or port mirroring. Note that many
devices that you might not expect to be switches actually are, for
example, a dual-speed 10/100Mbps hub is usually a two-port switch:
one port for the 100Mbps systems and the other for the 10Mbps
systems.
-
The ability to run certain programs as normal
applications instead of as part of the kernel. For example, most
Unix versions of an RARP server are normal applications that read
RARP requests from the datalink (RARP requests are not IP
datagrams) and then write the reply back to the datalink.
The three common methods to access the datalink
layer under Unix are the BSD Packet Filter (BPF), the SVR4 Datalink
Provider Interface (DLPI), and the Linux SOCK_PACKET
interface. We present an overview of these three, but then describe
libpcap, the publicly available packet capture library.
This library works with all three and using this library makes our
programs independent of the actual datalink access provided by the
OS. We describe this library by developing a program that sends DNS
queries to a name server (we build our own UDP datagrams and write
them to a raw socket) and reading the reply using libpcap
to determine if the name server enables UDP checksums.
|