reserved for future use; they're being used.
Move other currently-being-used LINKTYPE_ values above the "reserved for
future use" comment, to make it clear which types are reserved and which
are already in use.
Note that 100 through 103 shouldn't be used for new DLT_ types.
"pcap_setfilter()" if we're not using a kernel filter, in case a
previous call to "pcap_setfilter()" had succeeded in adding a kernel
filter, as if we're doing userland filtering we need to get rid of all
kernel filters that might discard packets that'd pass the userland
filter.
packets queued up on the socket when we set a kernel filter on the
socket, so that if there are any queue-up packets that wouldn't have
passed the new filter, we don't see them. (Some other packet capture
mechanisms do this automatically; this prevents tcpdump, for example,
from showing or saving, when run with a filter, some packets that
wouldn't have passed the filter.)
XXX - do we have to do this on any other platforms?
Choose whether to compile in the code to modify filter programs for use
in the kernel, and to flush queued-up packet and set a kernel filter, on
whether SO_ATTACH_FILTER is defined (i.e., on whether we have kernel
filter support in our build environment), rather than on whether
HAVE_PF_PACKET_SOCKETS is defined (i.e., on whether we have PF_PACKET
support in our build environment), as we choose whether to *use* that
code based on whether SO_ATTACH_FILTER is defined.
the pointer to the beginning of the link-layer header; never use just
"handle->buffer", as, if "handle->offset" is non-zero (as is the case
with many link-layer types, including Ethernet), "handle->buffer"
doesn't point to the beginning of the link-layer header.
compiled on a system that doesn't have it, it'll use it on systems that
do have it.
On systems with MSG_TRUNC support (i.e., 2.2 and later kernels), there's
no need to read in the entire packet in order to find out how large it
is, so just allocate a buffer big enough for a snapshot length's worth
of data, and just read that much data.
There's no need for a "readlen" member of the "pcap_md" structure, as
the byte count to "recvfrom()" is just the "bufsize" member of the
"pcap_t" structure.
that we don't have almost-duplicate code in "live_open_old()" and
"live_open_new()". This fixes a bug wherein "live_open_new()" wasn't
making the buffer size the maximum of "enough to hold packets of the MTU
obtained from the socket" and "the snapshot length" (for some reason,
"recvfrom()" was copying more data than the MTU obtained from the
socket).
- Bad ethernet addresses no longer have to end with a colon
- Host names no longer have to be at least two characters long
- Bad tokens no longer have to end with an "i"
SOL_PACKET/PACKET_STATISTICS "getsockopt()" call, on Linux kernels that
support it, to get packet statistics, so that we can report the number
of dropped packets, and always use <linux/if_packet.h> to get
definitions for PF_PACKET sockets, so that we don't depend on glibc's
header files having been updated to support all the latest shiniest
kernel features (many systems with 2.4[.x] kernels don't have a
<netpacket/packet.h> that defines "struct tpacket_stats", for example,
so we wouldn't have been able to support that kernel feature on those
systems).
devices appear to reject attempts to bind to 1537, perhaps because Token
Ring devices use SAPs rather than Ethertypes and 1537 isn't a valid SAP
value.
Try to supply a string rather than a numerical value for various DLPI
errors, and to supply a string rather than a numerical value for
unexpected DLPI primitives.
Cast the argument to <ctype.h> macros to "unsigned char", to eliminate
GCC warnings and to keep the macros from referring outside an array when
handed bytes with the 8th bit set.
statement checking the link-layer type.
Give an error if we see a link-layer type we don't handle, rather than
assuming Ethernet - there's no guarantee that the framing is Ethernet
framing.
If we succeeded in opening the packetfilter device, but had an error
later, close the device before returning from "pcap_open_live()".
<Miklos.Szeredi@eth.ericsson.se> - "pcap_ether_aton()" allocates memory
for the MAC address, but we don't free it when we're done with it.
Code inspection revealed that there's a similar problem with
"pcap_ether_hostton()"; fix that as well.
"dl_hp_ppa_info_t" are arrays of "u_char" (or "u_int8_t"), presumably to
get around the problems of signed characters; this causes complaints
from HP's C compiler if we pass them as an argument to "strcmp()", so
cast them to "const char *".
Update the note on libpcap being "not very well suited for interactive
programs" to note that at least some of what it says is necessary is
already supported.
routine, and use it both on HP-UX and other DLPI systems; this means
that, in case there is ever a network device on HP-UX with a number in
the device type name, we'll properly extract the unit number (i.e.,
we'll extract the last number from the name, not the first number) - I
don't think that'll ever happen, but putting it into a common routine is
cleaner in any case.
to DLT_C_HDLC.
Arrange that if "map_arphrd_to_dlt()" supplies DLT_LINUX_SLL as the
link-layer DLT_ value, we capture in cooked mode.
Return DLT_LINUX_SLL for ARPHRD_PPP, as some PPP code in the kernel
supplies no link-layer header whatsoever to PF_PACKET sockets, other PPP
code supplies PPP link-layer headers ("syncppp.c"), and PPP-over-ISDN
appears to supply random link-layer headers (there's code in Ethereal,
for example, to cope with PPP-over-ISDN captures with which the Ethereal
developers have had to cope, heuristically trying to determine which of
the oddball link-layer headers particular packets have).
guy