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.)
"pcap_compile()" and "pcap_compile_nopcap()" return -1 on
failure;
if "pcap_compile()" or "pcap_setfilter()" fails, you can get the
error string with "pcap_geterr()";
if "pcap_compile_nopcap()" fails, you can't get the error
string, but, as it's just a wrapper around "pcap_open_dead()",
"pcap_compile()", and "pcap_close()", you can use those routines
yourself if you want the error string;
you have to use, or copy, the string you get back from
"pcap_geterr()" before closing the "pcap_t" you hand to
"pcap_geterr()", as the string you got back from "pcap_geterr()"
doesn't remain valid after the "pcap_t" whence you got it is
closed.
"ether host XX:XX:XX:XX:XX:XX", but the device on which you're capturing
isn't a device with Ethernet-style link-layer addresses, report
"ethernet addresses supported only on ethernet, FDDI or token ring", not
"ethernet address used in non-ether expression", as the error.
"pcap_compile()", rather than a routine that duplicates a lot of code in
"pcap_compile()", so that we don't run the risk of having
"pcap_compile_nopcap()" fail to take actions that "pcap_compile()"
takes.
ARPHRD_IEEE802, as the hardware type for Token Ring interfaces. Map
both of them to DLT_IEEE802 (as that has become the DLT_ type for Token
Ring, the fact that it just says "802", not "802_5" or whatever,
nonwithstanding), and, if ARPHRD_IEEE802_TR isn't defined, define it
with the value it has in 2.4 (so that the resulting libpcap will work on
a 2.4 system regardless of whether the system on which it was built
defined ARPHRD_IEEE802_TR).
Fix a hairy optimizer bug that causes the expression:
'ip and ((icmp and dst host 1.1.1.1 and not host 2.2.2.2) or (host 1.1.1.1 and src host 3.3.3.3))'
to compile incorrectly. Details about to be mailed to LBL.
as DLT_ values are defined with decimal values in "net/bpf.h".
Cast the last argument to "gen_cmp()" to "bpf_int32", not "long", as
it's a "bpf_int32".
#5228, to correctly check for Appletalk for EtherTalk phase II - they
use 802.3 with LLC SNAP packets, rather than D/I/X Ethernet packets.
His patch made "atalk" check for Appletalk ARP as well as other
Appletalk packets; I've instead added a separate "aarp" packet type,
leaving "atalk" checking only for ETHERTYPE_ATALK, so you can check for
ETHERTYPE_ATALK, ETHERTYPE_AARP, or both.
counting any extra jumps required by a flowgraph node (the conditional
jump instructions have an 8-bit offset; if the target is more than 256
instructions away, we generate a nearby "jump always" to the target, and
jump to that instead).
filter, always attach a copy, as "pcap-linux.c" does; that way, after a
program uses "pcap_setfilter()", it can safely use "pcap_freecode()" to
free up the BPF instructions allocated by "pcap_compile()". Also,
always free it up when the "pcap_t" is closed.
Get rid of the "pcap_t *" argument to "pcap_freecode()", as it's not
necessary.
Document "pcap_freecode()", for the benefit of programs that might
repeatedly compile filter programs and attach them, so that they can
free them up after attaching them and avoid leaking memory for them.
interface index of the interface for the packet is the interface index
of the loopback interface and, if it is, check if the packet is an
outgoing packet; if so, ignore it, as we'll also be seeing that packet
as a received packet.
If we don't handle the arphrd type of an interface, and fall back on
cooked mode, report the arphrd type, so we know what type we should
consider supporting (if that type can't be supported well, e.g. if you
don't get any link-layer header, as happens with PPP, we'd be silent).
"pcap_compile()", not just if we return with an error, so that we don't
leak memory by allocating a Flex buffer for the expression to be parsed
but not freeing it.
filter.
It appears that "recvfrom()", in 2.2 and later kernels, doesn't check
whether the starting buffer address plus the byte count goes into an
unmapped region of the address space - it (or code it calls) presumably
only checks the locations into which it's actually copying data - so
there doesn't appear to be, on systems with 2.2 and later kernels, any
need to ensure that the buffer size is at least large as the snapshot
length. We therefore only do so if we're using the old
PF_INET/SOCK_PACKET mechanism; if we're using PF_PACKET, we're on a
2.2 or later kernel, so we don't do it there.
guy