> Based on the READMEs from last weeks LIBPCAP package,
> I have a few questions.
>
> 1. What does it mean for libpcap to run in "user-level" mode?
On most modern processors used in general-purpose computers, the CPU can
run in at least two modes - a mode in which attempts to execute various
privileged instructions, or to access protected memory, will cause a
trap, and a mode in which the privileged instructions may be executed
and at least some protected memory is not protected.
The former mode is often called "user mode", and the latter mode is
often called "kernel mode" (although other names may be used, e.g. on
IBM mainframes they're often called "problem state" and, if I remember
correctly, "supervisor state").
The core of an OS typically runs in "kernel mode", with various other
parts of the OS ("user-mode" libraries, servers, etc.), and
applications, running in "user mode", making it harder for them to crash
the system or to get access to privileges they shouldn't have.
Networking stacks typically run in kernel mode or, perhaps, in special
privileged server processes (yes, there are exceptions, e.g. exokernel
systems); the services that a user mode application gets from the
kernel-mode code are, for example, the ability to open a TCP connection
or wait for a TCP connection to come in and accept it, and the ability
to send data on a TCP connection and receive data from the TCP
connection.
However, some applications, such as tcpdump, need "lower-level" access
to the network - they might, for example, need to be able to receive all
packets that the machine receives, and receive them as link-layer
packets.
Many OSes provide a mechanism to allow applications - or, at least,
applications running under accounts with sufficient privilege - to do
so. libpcap is a library that abstracts the various mechanisms provided
by various OSes, supplying a system-independent interface that hides the
differences between, say, BSD BPF devices and Linux PF_PACKET sockets
and DLPI devices and....
> 2. At what OSI or TCP/IP layer does it run?
It runs at the link layer, allowing you to capture (but *not* transmit)
link-layer packets. Note that the packets would *also* be handed to the
OS's networking stack, if appropriate; a program using libpcap is like
somebody tapping into a phone conversation, listening passively, not
like a participant in the phone conversation.
> 3. What is the layer that you are using at the "link-layer"?
We use whatever layer is the link layer of the device on which you're
capturing packets.
> 4. If I have a Linux kernel of 2.2.14.0 and would like to use tcpdump
> extensively, do I need to or should I turn on the CONFIG_FILTER flag and
> recompile the the kernel.
It's not strictly necessary; however, if you don't turn on
CONFIG_FILTER, and you run tcpdump (or Ethereal, or any other program
that uses libpcap and supports capture filters) to capture packets, and
specify a "capture filter" so that only certain packets will be seen by
tcpdump, then the OS will supply *all* packets to libpcap, copying them
from the kernel's address space to the program's address space, and
libpcap will select which packets to hand to the application. If,
however, you *do* turn on CONFIG_FILTER, libpcap will be able to tell
the *kernel* to select which packets are interesting, and the kernel
won't spend CPU time copying uninteresting packets into the program's
address space.
So you don't need to turn CONFIG_FILTER on, but you should.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
