even if we're in non-blocking mode, to pick up any error indications -
in that case, use a timeout of 0, so poll() doesn't block.
Don't test individual exceptional-condition bits in the poll() return
unless one of them is set, so we just do one test in the typical (no
exceptional condition) case.
went down" on at least some OSes, return a message indicating that.
When reading from a Linux PF_PACKET socket, if we get ENETDOWN, which
means "The device went down", return a message indicating that.
When doing a poll() on a PF_PACKET socket, check for various "something
happened on this, but it's not readable" conditions.
If PCAP_WARNING_PROMISC_NOTSUP, PCAP_ERROR_NO_SUCH_DEVICE, or
PCAP_ERROR_PERM_DENIED is returned, pcap_geterr() or
pcap_perror() may be called with p as an argument to fetch or
display an message giving additional details about the problem
that might be useful for debugging the problem if it's
unexpected.
but we weren't always setting the error string in question. Do so.
In pcap_open_live(), if the open fails with PCAP_ERROR, include the
device name in the error string, and if it fails with
PCAP_ERROR_NO_SUCH_DEVICE or PCAP_ERROR_PERM_DENIED, include the device
name and both error messages in the error string.
Allocate a buffer into which to copy a packet, and have the
callback for pcap_next() and pcap_next_ex() copy to that buffer
and return a pointer to that buffer; we can't return the packet
data pointer passed to the callback, as, once the callback
returns, that buffer can be overwritten, even before you read
the next packet.
Don't tweak filter programs passed into the kernel to return
65535 on success - we don't have to, as we're not reading
packets with recvfrom(), and we don't want to, as, if we return
the actual snapshot length, the kernel will copy less data to
the ring buffer.
Truncate the packet snapshot length to the specified length, as
we might not have a filter to do that.
- Fixed bug where create_ring would fail for particular snaplen and
buffer size combinations
- Changed ring allocation to retry with 5% less buffer size instead of
50%
region and the size of the region; use that pointer rather than the bp
or buffer member (that means we don't have to worry about
pcap_cleanup_live_common() attempting to free that buffer). Use the
saved size when unmapping the memory-mapped region.
Use that for Linux USB memory-mapped access as well - and unmap the
memory-mapped region when we close the pcap_t, because we *do* have to
unmap it.
mac80211 devices will, regardless of whether they support the Wireless
Extensions - wmaster devices will let you turn monitor mode on but don't
appear to support the Wireless Extensions.
Support turning on monitor mode with libnl even if we don't have support
for the Wireless Extensions, just in case the Wireless Extensions go
away at some point in the future if every 802.11 device has a mac80211
driver.
finishes processing the packet; in some cases, such as pcap_next() and
pcap_next_ex(), the packet data is expected to be available after the
callback returns, and only discarded when the next packet is read.
<net/if.h>, in the hope that
1) doing so won't cause some problem somewhere
and
2) it'll have multiple-include protection
(this whole "glibc is a separate project from the kernel, so we'll
duplicate header files" thing has its downsides).
kernel in general), <linux/wireless.h> includes <net/if.h> and you get
multiple-definition errors if you include <net/if.h> before it. Only
include <net/if.h> if you don't have <linux/wireless.h>.
than "the kernel doesn't support memory-mapped access to PF_PACKET
sockets", treat that as an error. If it fails for that reason, don't
leave gunk behind in the pcap_t's error buffer.
Clean up the error messages a bit (the result of strerror() suffices; we
don't need the numeric value of errno, nor do we need the file
descriptor number of the socket on which we're working).
before using that member.
Don't define variables if we aren't going to use them.
If we have an unknown tpacket version (this "can't happen"), return an
error.
pcap-linux: fix invalid rcvbuf size
Libpcap issues a SO_RCVBUF when the buffer size if unspecified (zero).
The intention is to set it when its *not* zero.
Similar to PACKET_AUXDATA for non-mmaped sockets, the VLAN TCI is
present in a new member of struct tpacket2_hdr. Use it to reconstruct
the VLAN header when necessary.
The tpacket_hdr is not clean for 64 bit kernel/32 bit userspace and
is not extendable because the struct sockaddr_ll following it is
expected at a fixed offset.
Linux 2.6.27-rc supports a new tpacket frame header that removes these
two limitations. Convert the mmap ring support to support both formats
and probe for availability of the new version.
VLAN packets sent over devices supporting VLAN tagging/stripping in
hardware don't have a VLAN header when they are received on packet
sockets. The VLAN TCI is available through the PACKET_AUXDATA cmsg,
reconstruct the entire header when necessary.
isn't up, so applications can report that differently from a generic
error (the latter could mean there's a bug somewhere in libpcap).
When capturing on a device without mmap on Linux, ignore ENETDOWN, so
that we can continue to capture traffic if the interface goes down and
comes back up again; comments in the kernel indicate that we'll just
block waiting for packets if we try to receive from a socket that
delivered ENETDOWN, and, if we're using a memory-mapped buffer, we won't
even get notified of "network down" events.