"getifaddrs()"), after processing the list returned by SIOCGIFCONF, scan
"/proc/net/dev" for interface names, and add to the list of interfaces
entries for those interfaces, with no associated addresses (if the
interfaces were already added, with addresses, from the list returned by
SIOCGIFCONF, they won't get added again).
Clean up the error handling a bit.
whether we have "freeifaddrs()" (we don't check whether we have
"getifaddrs()", and if we have "getifaddrs()" but not "freeifaddrs()",
we're stuck with leaking memory).
Give the "any" device an instance number of INT_MAX, so it shows up
after all other non-loopback devices.
"getifaddrs()" sometimes appears to supply a destination address even
for non-point-to-point interfaces (it did so on a FreeBSD 4.1 system);
don't use the broadcast address it supplies if an interface isn't a
broadcast interface, and don't use the destination address it supplies
if an interface isn't a point-to-point interface.
If we had an error constructing the list of interfaces, don't attempt to
add the "any" device to the list.
aclocal.m4:
revision 1.73
date: 2001/09/14 08:08:15; author: torsten; state: Exp; lines: +2 -2
The Itanium does not like unaligned memory accesses (the Linux kernel
warns about them and probably performance suffers). Therefore I added
the cpu to the list of systems where unaligned access should be avoided.
See also http://bugs.debian.org/112152
Add a new "pcap_findalldevs()" routine to get a list of all
interfaces that can be opened with "pcap_open_live()", and a
"pcap_freealldevs()" routine to free the list.
Make "pcap_lookupdev()" use it, which also arranges that it will
not return a device that cannot be opened by "pcap_open_live()".
Allow the "any" device to be opened, on Linux, with "promisc"
non-zero; ignore the request for promiscuity, and return a
warning message indicating that promiscuous mode isn't supported
on the "any" device.
Document "pcap_findalldevs()" and "pcap_lookupdev()", and clean up some
items in the libpcap man page.
packets before the network-layer header; we already deal with that in
tcpdump, and we could probably try to deal with that in the code
generator, but it's less of a pain to just punt to DLT_LINUX_SLL.
This allows correct compilation of multiple expressions
containing the "vlan" keyword in the same program.
Reported by: Jon Dugan <jdugan@ncsa.uiuc.edu>, on the bro@lbl.gov list
warns about them and probably performance suffers). Therefore I added
the cpu to the list of systems where unaligned access should be avoided.
See also http://bugs.debian.org/112152
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