support PF_PACKET sockets, and, in particular, don't define in
<linux/if_packet.h> any of the stuff needed by the code to handle
PF_PACKET sockets. Define HAVE_PF_PACKET_SOCKETS if either
1) we have <netpacket/packet.h>
or
2) PF_PACKET is defined *and* PACKET_HOST is defined by
<linux/if_packet.h>
and use HAVE_PF_PACKET_SOCKETS, not PF_PACKET, be what we use in #ifdefs
to conditionally compile in support for PF_PACKET sockets.
Not all platforms define ARPHRD_SIT, either; #define it if it's not
already defined.
<net/if_arp.h>, and the stuff we want is in <net/if_arp.h>, so include
that rather than <netinet/if_ether.h>.
At least some libc5 systems don't have <netpacket/packet.h>, but have a
<sys/socket.h> that includes <linux/socket.h>, and the latter defines
SO_ATTACH_FILTER if the kernel is a 2.2 or later kernel, so there exist
systems that have SO_ATTACH_FILTER defined but don't have
<netpacket/packet.h>. Work around that by:
checking whether we have PF_PACKET sockets by checking whether
PF_PACKET is defined, not whether we have <netpacket/packet.h>
(but we still check whether we have <netpacket/packet.h> before
including it);
if PF_PACKET is defined but we don't have <netpacket/packet.h>,
include <linux/if_packet.h> to get the relevant definitions.
Ethernet, so, at least on Ethernet, when checking for IPX frames, check
for all of them, including Ethernet_II and Ethernet_SNAP.
Add an "llc.h" file with LLC SAP values, taken from tcpdump's "llc.h"
file, and use those, rather than defining them ourselves in "gencode.c".
for "Novell 802.3" frames, which are 802.3 frames (i.e., the type/length
field is a length field, i.e. it's <= ETHERMTU) with 0xFFFF as the first
2 bytes. We don't yet check for ETHERTYPE_IPX as well.
When checking for OSI packets on Linux cooked captures, check for 802.2
frames by testing the packet type for LINUX_SLL_P_802_2 rather than by
checking whether the type field is <= ETHERMTU (it's always a type field
in DLT_LINUX_SLL captures).
Set "off_linktype" to the correct value for the offset of the Ethernet
type field in the fake header for Linux cooked captures, so that the
correct code is generated for tests of that field.
Ring, and RFC 1483-style ATM, as well as on Ethernet.
Support checking for LLC SAP protocols other than OSI protocols on
Ethernet - for now, we check only the DSAP on those, rather than
checking both the DSAP and SSAP as we do for OSI, as I think, in some
cases, the SSAP isn't the same as the DSAP.
When generating protocol type checks on link-layer types with no type
field, where packets are always IP (SLIP, BSD/OS SLIP, raw IP), generate
a "test" that always succeeds if the protocol being checked for is IP or
IPv6 and a "test" that always fails otherwise. (We originally did
"gen_true()" if the protocol is IP, and bogusly generated code to check
the field at an offset of -1 otherwise; a subsequent change caused us
always to do "gen_true()", but that doesn't properly handle attempts to
check for other protocols - those attempts should generate code that
always fails, meaning that if you try to look for ARP packets in such a
capture the BPF compiler will return "expression rejects all packets" as
an error - and still generated extra code not all of which was removed
by the optimizer. The current code generates no *more* BPF code.)
Add "stp", which checks for the LLC SAP for the Spanning Tree Protocol.
Linux; Linux isn't the only platform whose kernel doesn't support a
read timeout, and even some that *do* don't start the timer until at
least one packet has arrived (Solaris, for example), so no portable
application can depend on "pcap_dispatch()", say, blocking for no longer
than the timeout - they must do a "select()" themselves. For
applications that do the "select()" themselves, or that don't need the
timeout for polling (tcpdump, for example), doing a "select()" in
libpcap just adds another system call to the code path.
reality ("pcap_dispatch()", on a live capture, never reads more than one
bufferful of packets).
Break the description of "pcap_dispatch()" into multiple paragraphs.
Move the description of "pcap_loop()" right after the descriptionof
"pcap_dispatch()", and note that "pcap_dump()" can be used as the
callback function for either of them.
that "pcap_dispatch()" will always return within that many milliseconds;
some platforms don't support a read timeout, meaning the read timeout
argument is ignored, and, on other platforms (SunOS 5.x and possibly
SunOS 4.x and 3.x), the timer starts when the first packet arrives, so
the timeout doesn't expire until at least one packet arrives.
at the end of the link-layer header; put it there.
Put in a comment indicating that the layout of the link-layer header
shouldn't be changed; if a new header is necessary, a new DLL_ type
should be introduced for it.
them in "print-sll.c" - as a cooked-mode capture may be reading from
non-Ethernet, non-802.x devices, it may well see some
ETH_P_/LINUX_SLL_P_ types that don't mean "this is an 802.2 LLC frame".
We currently assume that the ETH_P_ values won't change in the kernel,
so we don't have to explicitly map them.
we just treat the frame as an LLC frame (if we care about Novell
IPX-over-raw-802.3 frames, we'd have to handle them by checking for
0xFFFF as the first word - but we'd also have to do that when dissecting
Ethernet frames).
future Linux kernel changes the PACKET_ values out from under us, the
values recorded in the packet header in DLT_LINUX_SLL captures does
*not* change.
Don't map ETH_P_802_2 to the packet length, map it and ETH_P_802_3 to
standardized LINUX_SLL_P_ values, so that even if a future Linux kernel
changes the ETH_P_ values out from under us, the values recorded in the
packet header in DLT_LINUX_SLL captures does *not* change, and so that
you don't have to be running on Linux to be able to handle DLT_LINUX_SLL
captures.
live captures with a "cooked" (SOCK_DGRAM) rather than a "raw"
(SOCK_RAW) PF_PACKET socket; it includes a bunch of the fields from the
"struct sockaddr_ll" you get in a "recvfrom()", including the Ethernet
protocol field.
This requires us to rewrite the BPF program if we're stuffing it into
the kernel; as long as we're doing *ex post facto* rewriting, we might
as well also do the "ret <snaplen>" -> "ret 65535" fixup there as well,
rather than in the code generator.
"patches@tcpdump.org" by Jonathan Wilkins
<jwilkins@madscience.dyndns.org>, we don't declare "ether_hostton()" on
FreeBSD - it's declared in <net/ethernet.h> in 3.0 and later, and is
declared with the first argument as "const char *" in 4.0 and later so
that if we declare it with the first argument as "char *" we get errors.
(If we declare it with "const char *", you get errors on FreeBSD 3.x and
other systems that *don't* declare it with "const char *".)
XXX - should it go, instead, into "lbl/os-XXX.h" files, for those OS
versions that don't declare it, and not be declared at all here?
means that we should "htonl()" it before using it in BPF expressions
*but*, if we're reading a capture file from a machine with the opposite
byte order from ours, we should byte-swap it before "htonl()"ing it.
Handle OpenBSD DLT_LOOP as well - it's like DLT_NULL except that the AF_
value is in *network* byte order.
Don't support checking for inbound or outbound packets except on those
data link types that supply an inbound/outbound qualifier (DLT_SLIP and
DLT_PPP) - this came from OpenBSD's libpcap, delta 1.12 to "gencode.c".
remember which pcap_t's were opened (with SOCK_PACKET) in promiscuous
mode on interfaces not already in promiscuous mode, turn promiscuous
mode off when closing such a pcap_t, and arrange that, when the program
exits, all pcap_t's of that sort not already closed have their
interfaces taken out of promiscuous mode. (It's not sufficient to do
this on exit - applications may close a pcap_t without exiting, e.g.
Ethereal.)
This won't always work right (if somebody else requests promiscuous mode
after it's opened by libpcap, we'll turn promiscuous mode off when we
close the pcap_t, and if the program doesn't exit cleanly, it won't
clean up the interfaces), but neither of those problems are fixable -
the only way to get things to work correctly is to use PF_PACKET
sockets, which requires a 2.2 or later kernel.
On a 2.0[.x] kernel, when doing a "recvfrom()" on a SOCK_PACKET socket
to read a captured packet, don't pass a byte count value based on the
snapshot length - "recvfrom()" won't return the actual packet length if
you do that. (2.2 and later kernels will return the actual packet
length if MSG_TRUNC is passed in.)
guy