the current state of non-blocking mode; this allows us to implement, for
example, memory-mapped capture devices, where "pcap_read()" uses
"select()" or "poll()" to wait for packets to arrive, and hide that
implementation detail from applications using this API
("pcap_setnonblock()" would set or clear a non-blocking mode flag in the
"pcap_t", and the "select()" or "poll()" would not be done if the
"pcap_t" is in non-blocking mode).
information plus 802.11 header (as per Tim Newsham's stuff) and for some
flavor of Aironet 802.11 link-layer header (as per Doug Ambrisko's
FreeBSD patches).
that there may be compile-time or run-time problems with the
workarounds, suggest that people send in a detailed report and fall back
on DLPI if they have those problems, and suggest that if they construct
fixes for the problems they send them to patches@tcpdump.org.
Fix the white space.
field, and make a PCAP_IF_LOOPBACK flag be the first flag bit in that
field, specifying whether the interface is a loopback interface; this
allows us to add more flags without changing the layout of the
structure.
didn't handle; fix the code to do so.
Remove the word "Warning" from the warning - tcpdump will add it when it
prints the warning, as will Ethereal and Tethereal.
"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.