"vasnprintf()", as we're not using any of them, and we're not declaring
them in "interface.h" (keep them around for now in case we decide we
need them; they may be useful if we ever want to "sprintf" a string and
want the string to grow dynamically to hold what we're putting into it).
than AFSOPAQUEMAX, a NUL could be written out of bounds of the
storage for the ACL. This is almost definitely unexploitable,
since no network-supplied data is written (only a NUL).
Remove the entry with the older version of Alfredo Andres' e-mail
address, and with Love Hörnquist-Åstrand's first name but not last name.
Put in Sebastian Krahmer's e-mail address.
the code for Linux kernel filtering hands the kernel a modified copy of
the filter that refers to the link-layer headers, for DLT_LINUX_SLL,
with the negative offsets in question.
version of "snprintf()" unless the platform on which we're running lacks
"snprintf()" or "vsnprintf()" - if it lacks one of the "asprintf" family
of routines, we don't drag it in, as we don't use those routines.
version of "snprintf()" unless the platform on which we're running lacks
"snprintf()" or "vsnprintf()" - if it lacks one of the "asprintf" family
of routines, we don't drag it in, as we don't use those routines.
through `...'", and therefore "...you should pass `int' not `short int'
to `va_arg'".
GCC "2.96" apparently fails to compile code that passes "short int" to
"va_arg()", and Red Hat Linux 7.0 uses GCC "2.96", so we fix this, as
per Pekka Savola's note.
checksum, fetch it by casting the pointer to "const u_int8_t *" rather
than "const char *" - casting it to "const char *" causes it to be
sign-extended, perhaps causing 16 1 bits to be added in at the top and,
at least on big-endian platforms (where "htons()" does nothing, meaning
it won't trim off the extra 16 bits) with signed "char"s (e.g., SPARC),
causing the checksum to be computed incorrectly and causing it to
incorrectly be reported as bad.
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.
In various link-layer packet printers, if we don't handle the next layer
up of packet type, and are printing the link-layer header, use the
correct pointer to that header (i.e., if we've stepped "p" past the
link-layer header, don't use "p", use a pointer to the beginning of the
packet), and use the correct length (i.e., if we've subtracted the
length of the link-layer header, add it back in, so that we always print
the full packet length).
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.
tip of the Hatlo hat to Pascal Hennequin <pascal.hennequin@int-evry.fr>
for catching this one.
Also, the control field in an S or I frame is little-endian; treat it as
such, fixing various #defines in "llc.h" to match.
dissectors that expected calls to "llc_print()" to set it. (Thanks and
a tip of the hat to Olaf Kirch <okir@caldera.de> for noticing this.)
Make "ether_encap_print()" and "llc_print()" take a pointer to an
extracted-Ethertype variable as an argument, have "llc_print()" pass it
to "ether_encap_print()", and have "ether_encap_print()" set what it
points to rather than setting a static "extracted_ethertype" variable.
Get rid of said static "extracted_ethertype" variable in favor of one
local to "ether_if_print()", just as other link-layer dissectors have
local "extracted_ethertype" variables.
may not be *our* byte order if we're reading a capture file from another
machine; we currently handle that by checking whether it looks like an
integer < 65536 or not and, if it's not, byte-swap it.
This also lets us handle OpenBSD DLT_LOOP as well - it's like DLT_NULL
except that the AF_ value is in *network* byte order.
(Old-style Linux loopback captures were also DLT_NULL, but the header
had an Ethernet type in it; there have also been captures where the
header was a PPP header. For now, we just continue to assume that all
DLT_NULL packets are IP, and check the IP version field to decide
whether it's IPv4, IPv6, or something else.
We may want to consider adopting Ethereal's heuristics, which would at
least mean we wouldn't be reporting bogus packet types for old-style
Linux loopback captures and those weird PPP - ISDN4BSD? - captures,
although the version of libpcap that goes with this version of tcpdump
doesn't produce bogus DLT_NULL captures for Linux loopback devices.)
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.)
Update the documentation to reflect improved Appletalk support.
