Both of them are indications that there's no such interface, so the file
probably corresponds to something other than a device.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
This patch adds support for our NICs when run in a specialized capture mode.
It is diffed against the current master.
The Myricom Sniffer10G software uses Myri-10G programmable Network Interface
Cards (NICs), a firmware extension, a specialized driver and a user-level
library (libsnf) to enable sustained capture of 10-Gigabit Ethernet traffic.
Small-packet coalescing and an efficient zero-copy path to host memory allow
Sniffer10G to capture streams at line rate for all Ethernet packet sizes.
Optionally, libpcap can be used concurrently by multiple processes on a single
NIC port to partition the incoming traffic across processes. While the Linux
kernel enables this through multiple receive queues, the difference is that the
myri_snf driver cooperates with libsnf to set up multiple queues that are each
independently accessible through user-space.
More information here: http://www.myri.com/scs/SNF/doc
Signed-off-by: Guy Harris <guy@alum.mit.edu>
If we fail to open it, we just drive on, so it's not a fatal error; yes,
it'll slow us down a little, but it's probably not much, and most Linux
kernels probably have it in any case.
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>.
Guy Harris