the file descriptor flags; there's no guarantee that it will actually
*affect* the file descriptor flags (consider a memory-mapped capture
mechanism such as the Linux 2.4 mechanism, where all "non-blocking mode"
means is "don't do a 'select()' or 'poll()' if there aren't any new
packets in the memory-mapped buffer") or, in fact, that there are file
descriptor flags to affect (consider WinPcap).
Don't subtract "tp_drops" from "tp_packets" - "ps_recv", on BSD,
at least, includes packets dropped due to lack of buffer space,
so it should do so on Linux as well.
The "len" argument to "getsockopt()" is a value-result
parameter, initially containing the size of the buffer being
supplied; set it before the call.
Catch "getsockopt()" errors and, if it's an error other than
EOPNOTSUPP, return an error.
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
guy