pcap.3

用来监视网络通信数据的源代码和应用程序,方便网络程序底层开发.

.I cnt
packets may be processed. A
.I cnt
of \-1 processes all the packets received in one buffer when reading a
live capture, or all the packets in the file when reading a
``savefile''.
.I callback
specifies a routine to be called with three arguments:
a
.I u_char
pointer which is passed in from
.BR pcap_dispatch() ,
a
.I const struct pcap_pkthdr
pointer to a structure with the following members:
.RS
.TP
.B ts
a
.I struct timeval
containing the time when the packet was captured
.TP
.B caplen
a
.I bpf_u_int32
giving the number of bytes of the packet that are available from the
capture
.TP
.B len
a
.I bpf_u_int32
giving the length of the packet, in bytes (which might be more than the
number of bytes available from the capture, if the length of the packet
is larger than the maximum number of bytes to capture)
.RE
.PP
and a
.I const u_char
pointer to the first
.B caplen
(as given in the
.I struct pcap_pkthdr
a pointer to which is passed to the callback routine)
bytes of data from the packet (which won't necessarily be the entire
packet; to capture the entire packet, you will have to provide a value
for
.I snaplen
in your call to
.B pcap_open_live()
that is sufficiently large to get all of the packet's data - a value of
65535 should be sufficient on most if not all networks).
.PP
The number of packets read is returned.
0 is returned if no packets were read from a live capture (if, for
example, they were discarded because they didn't pass the packet filter,
or if, on platforms that support a read timeout that starts before any
packets arrive, the timeout expires before any packets arrive, or if the
file descriptor for the capture device is in non-blocking mode and no
packets were available to be read) or if no more packets are available
in a ``savefile.'' A return of \-1 indicates
an error in which case
.B pcap_perror()
or
.B pcap_geterr()
may be used to display the error text.
A return of \-2 indicates that the loop terminated due to a call to
.B pcap_breakloop()
before any packets were processed.
.ft B
If your application uses pcap_breakloop(),
make sure that you explicitly check for \-1 and \-2, rather than just
checking for a return value < 0.
.ft R
.PP
.BR NOTE :
when reading a live capture,
.B pcap_dispatch()
will not necessarily return when the read times out; on some platforms,
the read timeout isn't supported, and, on other platforms, the timer
doesn't start until at least one packet arrives.  This means that the
read timeout should
.B NOT
be used in, for example, an interactive application, to allow the packet
capture loop to ``poll'' for user input periodically, as there's no
guarantee that
.B pcap_dispatch()
will return after the timeout expires.
.PP
.B pcap_loop()
is similar to
.B pcap_dispatch()
except it keeps reading packets until
.I cnt
packets are processed or an error occurs.
It does
.B not
return when live read timeouts occur.
Rather, specifying a non-zero read timeout to
.B pcap_open_live()
and then calling
.B pcap_dispatch()
allows the reception and processing of any packets that arrive when the
timeout occurs.
A negative
.I cnt
causes
.B pcap_loop()
to loop forever (or at least until an error occurs).  \-1 is returned on
an error; 0 is returned if
.I cnt
is exhausted; \-2 is returned if the loop terminated due to a call to
.B pcap_breakloop()
before any packets were processed.
.ft B
If your application uses pcap_breakloop(),
make sure that you explicitly check for \-1 and \-2, rather than just
checking for a return value < 0.
.ft R
.PP
.B pcap_next()
reads the next packet (by calling
.B pcap_dispatch()
with a
.I cnt
of 1) and returns a
.I u_char
pointer to the data in that packet.  (The
.I pcap_pkthdr
struct for that packet is not supplied.)
.B NULL
is returned if an error occured, or if no packets were read from a live
capture (if, for example, they were discarded because they didn't pass
the packet filter, or if, on platforms that support a read timeout that
starts before any packets arrive, the timeout expires before any packets
arrive, or if the file descriptor for the capture device is in
non-blocking mode and no packets were available to be read), or if no
more packets are available in a ``savefile.''  Unfortunately, there is
no way to determine whether an error occured or not.
.PP
.B pcap_next_ex()
reads the next packet and returns a success/failure indication:
.RS
.TP
1
the packet was read without problems
.TP
0
packets are being read from a live capture, and the timeout expired
.TP
\-1
an error occurred while reading the packet
.TP
\-2
packets are being read from a ``savefile'', and there are no more
packets to read from the savefile.
.RE
.PP
If the packet was read without problems, the pointer pointed to by the
.I pkt_header
argument is set to point to the
.I pcap_pkthdr
struct for the packet, and the
pointer pointed to by the
.I pkt_data
argument is set to point to the data in the packet.
.PP
.B pcap_breakloop()
sets a flag that will force
.B pcap_dispatch()
or
.B pcap_loop()
to return rather than looping; they will return the number of packets
that have been processed so far, or \-2 if no packets have been
processed so far.
.PP
This routine is safe to use inside a signal handler on UNIX or a console
control handler on Windows, as it merely sets a flag that is checked
within the loop.
.PP
The flag is checked in loops reading packets from the OS - a signal by
itself will not necessarily terminate those loops - as well as in loops
processing a set of packets returned by the OS.
.ft B
Note that if you are catching signals on UNIX systems that support
restarting system calls after a signal, and calling pcap_breakloop()
in the signal handler, you must specify, when catching those signals,
that system calls should NOT be restarted by that signal.  Otherwise,
if the signal interrupted a call reading packets in a live capture,
when your signal handler returns after calling pcap_breakloop(), the
call will be restarted, and the loop will not terminate until more
packets arrive and the call completes.
.PP
Note also that, in a multi-threaded application, if one thread is
blocked in
.BR pcap_dispatch() ,
.BR pcap_loop() ,
.BR pcap_next() ,
or
.BR pcap_next_ex() ,
a call to
.B pcap_breakloop()
in a different thread will not unblock that thread; you will need to use
whatever mechanism the OS provides for breaking a thread out of blocking
calls in order to unblock the thread, such as thread cancellation in
systems that support POSIX threads.
.ft R
.PP
Note that
.B pcap_next()
will, on some platforms, loop reading packets from the OS; that loop
will not necessarily be terminated by a signal, so
.B pcap_breakloop()
should be used to terminate packet processing even if
.B pcap_next()
is being used.
.PP
.B pcap_breakloop()
does not guarantee that no further packets will be processed by
.B pcap_dispatch()
or
.B pcap_loop()
after it is called; at most one more packet might be processed.
.PP
If \-2 is returned from
.B pcap_dispatch()
or
.BR pcap_loop() ,
the flag is cleared, so a subsequent call will resume reading packets. 
If a positive number is returned, the flag is not cleared, so a
subsequent call will return \-2 and clear the flag.
.PP
.B pcap_dump()
outputs a packet to the ``savefile'' opened with
.BR pcap_dump_open() .
Note that its calling arguments are suitable for use with
.B pcap_dispatch()
or
.BR pcap_loop() .
If called directly, the 
.I user
parameter is of type 
.I pcap_dumper_t
as returned by
.BR pcap_dump_open() .
.PP
.B pcap_compile()
is used to compile the string
.I str
into a filter program.
.I program
is a pointer to a
.I bpf_program
struct and is filled in by
.BR pcap_compile() .
.I optimize
controls whether optimization on the resulting code is performed.
.I netmask
specifies the IPv4 netmask of the network on which packets are being
captured; it is used only when checking for IPv4 broadcast addresses in
the filter program.  If the netmask of the network on which packets are
being captured isn't known to the program, or if packets are being
captured on the Linux "any" pseudo-interface that can capture on more
than one network, a value of 0 can be supplied; tests for IPv4 broadcast
addreses won't be done correctly, but all other tests in the filter
program will be OK.  A return of \-1 indicates an error in which case
.BR pcap_geterr()
may be used to display the error text.
.PP
.B pcap_compile_nopcap()
is similar to
.B pcap_compile()
except that instead of passing a pcap structure, one passes the
snaplen and linktype explicitly.  It is intended to be used for
compiling filters for direct BPF usage, without necessarily having
called
.BR pcap_open() .
A return of \-1 indicates an error; the error text is unavailable.
.RB ( pcap_compile_nopcap()
is a wrapper around
.BR pcap_open_dead() ,
.BR pcap_compile() ,
and
.BR pcap_close() ;
the latter three routines can be used directly in order to get the error
text for a compilation error.)
.B
.PP
.B pcap_setfilter()
is used to specify a filter program.
.I fp
is a pointer to a
.I bpf_program
struct, usually the result of a call to
.BR pcap_compile() .
.B \-1
is returned on failure, in which case
.BR pcap_geterr()
may be used to display the error text;
.B 0
is returned on success.
.PP
.B pcap_freecode()
is used to free up allocated memory pointed to by a
.I bpf_program
struct generated by
.B pcap_compile()
when that BPF program is no longer needed, for example after it
has been made the filter program for a pcap structure by a call to
.BR pcap_setfilter() .
.PP
.B pcap_datalink()
returns the link layer type; link layer types it can return include:
.PP
.RS 5
.TP 5
.B DLT_NULL
BSD loopback encapsulation; the link layer header is a 4-byte field, in
.I host
byte order, containing a PF_ value from
.B socket.h
for the network-layer protocol of the packet.
.IP
Note that ``host byte order'' is the byte order of the machine on which
the packets are captured, and the PF_ values are for the OS of the
machine on which the packets are captured; if a live capture is being
done, ``host byte order'' is the byte order of the machine capturing the
packets, and the PF_ values are those of the OS of the machine capturing
the packets, but if a ``savefile'' is being read, the byte order and PF_
values are
.I not
necessarily those of the machine reading the capture file.
.TP 5
.B DLT_EN10MB
Ethernet (10Mb, 100Mb, 1000Mb, and up)
.TP 5
.B DLT_IEEE802
IEEE 802.5 Token Ring
.TP 5
.B DLT_ARCNET
ARCNET
.TP 5
.B DLT_SLIP
SLIP; the link layer header contains, in order:
.RS 10
.LP
a 1-byte flag, which is 0 for packets received by the machine and 1 for
packets sent by the machine;
.LP
a 1-byte field, the upper 4 bits of which indicate the type of packet,
as per RFC 1144:
.RS 5
.TP 5
0x40
an unmodified IP datagram (TYPE_IP);
.TP 5
0x70
an uncompressed-TCP IP datagram (UNCOMPRESSED_TCP), with that byte being
the first byte of the raw IP header on the wire, containing the
connection number in the protocol field;
.TP 5
0x80
a compressed-TCP IP datagram (COMPRESSED_TCP), with that byte being the
first byte of the compressed TCP/IP datagram header;
.RE
.LP
for UNCOMPRESSED_TCP, the rest of the modified IP header, and for
COMPRESSED_TCP, the compressed TCP/IP datagram header;
.RE
.RS 5
.LP
for a total of 16 bytes; the uncompressed IP datagram follows the header.
.RE
.TP 5
.B DLT_PPP
PPP; if the first 2 bytes are 0xff and 0x03, it's PPP in HDLC-like
framing, with the PPP header following those two bytes, otherwise it's
PPP without framing, and the packet begins with the PPP header.
.TP 5
.B DLT_FDDI
FDDI
.TP 5
.B DLT_ATM_RFC1483
RFC 1483 LLC/SNAP-encapsulated ATM; the packet begins with an IEEE 802.2
LLC header.
.TP 5
.B DLT_RAW
raw IP; the packet begins with an IP header.
.TP 5
.B DLT_PPP_SERIAL
PPP in HDLC-like framing, as per RFC 1662, or Cisco PPP with HDLC
framing, as per section 4.3.1 of RFC 1547; the first byte will be 0xFF
for PPP in HDLC-like framing, and will be 0x0F or 0x8F for Cisco PPP
with HDLC framing.
.TP 5
.B DLT_PPP_ETHER
PPPoE; the packet begins with a PPPoE header, as per RFC 2516.
.TP 5
.B DLT_C_HDLC
Cisco PPP with HDLC framing, as per section 4.3.1 of RFC 1547.