| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
| | |
| | |
| | | |
If tp version is not valid, then we don't enter in the switch condition and we access to an uninitialized variable (req.tp_frame_size).
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"tcpdump -i any" refused to start and it turned out "tcpdump -D" didn't
mention "any" any more too.
Before commit 149f83b pcap_create_interface() would claim every
interface to support 3 timestamp types. After the change
iface_ethtool_get_ts_info() would normally check each timestamp type for
each interface with ethtool-specific ioctl and the old behaviour would
be the case only when the ioctl was unavailable. This way the "any"
pseudo-interface would fail the check when the ioctl was available and
pcap_create_interface() would not process it.
Now the common code for setting the defaults is in
iface_set_default_ts_types() and iface_ethtool_get_ts_info() properly
handles the "any" special case, has another error correctly handled and
an error message fixed.
|
| | | |
| | |
| | |
| | |
| | | |
Add a missing parenthesis and use socklen_t for the getsockopt()
argument to address a pointer type warning.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Instead, do it in pcap-linux.c, and have it set a flag in the pcap_t
structure to indicate to the code in gencode.c that it needs to generate
special VLAN-handling code.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Call it bpf_filter_with_aux_data(), to better indicate what it does.
Also expand some comments and clean up white space a bit.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
libpcap will generate BPF filter code which uses BPF extensions if target
platform supports them. Currently supported BPF extensions are vlan_tci and
vlan_pr.
Also to properly handle such filters when filtering in userspace libpcap now
employs bpf_filter1.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
That way, if it fails, we don't set the timeout in the private data
structure to indicate that we're in non-blocking mode.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
With libpcap mmap'ed read on LInux, which would be the very
common case, even if we set pcap_setnonblock for that handle,
pcap_sendpacket will block.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Most of these are "should not fail" cases, but let's at least report
their failures as fatal errors.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When destroying a ring buffer, there's not much we can do if the call to
destroy the ring buffer fails, so we just ignore the return value of
setsockopt(); cast it to void, to explicitly indicate that we're
ignoring it, in the hopes that Coverity will no longer complain that
we're ignoring it. Add a comment noting this.
Do the same with the return value of munmap(), as we're ignoring it for
the same reason (even though Coverity, for some unknown reason, didn't
complain about it).
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
That way, code that looks at those flags will make the "any" device look
like regular devices; as long as there's at least one network interface
up and running, or could be up and running at some point in the future,
the "any" device can be considered up and running, so that's
appropriate.
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
Make it 131072, instead; the MTU on the Linux loopback interface, in at
least some versions of the kernel, is 65536, and that doesn't count the
fake Ethernet header, so we need a value bigger than 65536. We don't
want a value that's *too* large, so that it causes attempts to allocate
huge amounts of memory, however.
Make it a #define while we're at it.
|
| | |
| |
| |
| |
| |
| | |
This makes the code a bit clearer, as you don't have to worry about the
status variable accidentally being set to an inappropriate value,
overriding a warning that's been put there.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the user specified a timeout value of 0, and we don't have any
packets to return from pcap_read_linux_mmap_v3(), go back and wait for
packets. Yes, this means waiting indefinitely, but that's what the
documentation used to say, and what we're making it say again; if this
is a problem, *don't use a timeout value of 0*.
This should fix GitHub libpcap issue #350.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
If not, the device presumably doesn't exist, as the Linux kernel
shouldn't support creating such a device; make sure we don't just use a
truncated version of the name in ioctls.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This one replaces a strcpy(); that one was also found by Coverity.
(I suppose we should check whether strlcpy() prematurely null-terminates
the string, and report a "no such device" error - or, in the create
routine, check to make sure the device name fits within all of the
relevant ioctl data structures and, if not, return a "device doesn't
exist" error.)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
That ensures null-termination of strings; Coverity complained about
that.
That also obviates the need to manually null-terminate strings, so get
rid of some now-unnecessary null-termination.
|
| | |
| |
| |
| |
| |
| |
| | |
Thanks to Coverity for finding the first one. The second one wasn't as
obviously a leak, so Coverity didn't find it; don't save the socket FD
in the pcap_t structure until we've succeeded in activating the pcap_t,
so that leaks such as that will be more obvious to Coverity.
|
| |/
|
|
| |
(Did anybody ever send this fix upstream to us?)
|
| |
|
|
|
|
|
|
|
|
| |
For various annoying reasons having to do with DHCP software, some
versions of Android give the mobile-phone-network interface an ARPHRD_
value of ARPHRD_ETHER, even though the packet supplied by that interface
have no link-layer header, and begin with an IP header, so that the
ARPHRD_ value should be ARPHRD_NONE.
Detect those devices by checking the device name, and use DLT_RAW for them.
|
| |
|
|
|
|
| |
The code to scan /sys/class/net and the code to scan /proc/net/dev had
common code to, when they found an interface, add it to the interface
list; pull that code into a common routine.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
On some platforms, you can capture on those interfaces, which might be
useful if you want to start a capture before the interface is up, so
that the capture starts capturing as soon as it's up.
Those interfaces will not appear in the interface list on platforms
where you can't open them for capturing, and they'll now be sorted after
the interfaces that *are* up, so there's not much harm in including
them.
|
| |
|
|
|
|
| |
This change removes CVS keywords that express that the file belongs to
libpcap repository. All such keywords represented the revision and
timestamp by the end of 2008 or even older.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We count the number of free blocks in the ring buffer, and calculate the
number of blocks in the ring buffer containing packets. With TPACKET_V1
and TPACKET_V2, there's one packet per block, but, with TPACKET_V3,
there can be more than one packet per block, so we need to count blocks,
not packets, to decide when we no longer need to filter packets in
userland.
Don't overload the "filtering in kernel" flag to hold the count of
blocks; instead, have a "filter in userland" flag, indicating that we
have to filter packets in userland (whether that's because the filter
wasn't accepted by the kernel or because we need to deal with packets
that passed an earlier kernel filter but wouldn't have passed the new
kernel filter) and a count of blocks to filter in userland.
After counting the number of free blocks, if we find any, decrement that
count by 1, just in case some packet that had passed the old filter got
added to the ring after we counted the free blocks. (For TPACKET_V1 and
TPACKET_V2, that would mark the block as no longer free, so the window
in which that could happen is narrower than for TPACKET_V3, where the
block might not be full and the timeout might not have expired, so it
could take some time before that block is handed to userland.)
Should fix GitHub issue #331.
(While we're at it, use the term "block" consistently for a fixed-length
item in the ring.)
|
| |
|
|
| |
That's what's done in other places in the file.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In read routines, a packet count <= 0 means "keep supplying packets
until you run out of packets in the buffer", and it means "keep supply
packets until the loop is broken out of or you get an error" in
pcap_loop().
Use the macro in all tests for that, so the right test is always done
(i.e., a count of 0 means "unlimited", not "supply zero packets"); this
fixes some cases where we weren't doing the right test (and hopefully
encourages programmers to use it and get the test right in new modules).
|
| |
|
|
|
| |
A count of -1 *or* 0 should mean "loop forever", so only a count > 0
means to use the count to limit the number of packets to process.
|
| | |
|
| |
|
|
| |
See https://github.com/the-tcpdump-group/libpcap/issues/335 for details.
|
| |
|
|
|
|
|
|
| |
Before patch:
tcpdump: listening on nlmon0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
After patch:
tcpdump: listening on nlmon0, link-type 253, capture size 65535 bytes
|
| |
|
|
|
|
|
|
|
|
| |
libpcap would fail to initialize on Linux when compiled against kernel
headers with TPACKET_V3 support but running on kernel without:
"can't get TPACKET_V3 header len on packet socket: Invalid argument"
Fix init_tpacket() to respect EINVAL because that is what the kernel
returns for unsupported TPACKET versions.
|
| |
|
|
|
|
|
| |
I'm not certain setting handlep->cooked in map_arphrd_to_dlt() will
work. We should look at making that work.
Add comments to indicate what we're doing.
|
| |\
| |
| |
| |
| |
| | |
This merge is necessary because this isn't SVN and "commit" and "push to
official repository" are separate operations, so, when you do a push, it
apparently needs a commit to merge your changes with other changes.
|
| | | |
|
| |/
|
|
|
|
|
|
| |
That's how we handle it elsewhere; if that can be cleaned up, especially
if we can avoid opening a raw socket in the cooked-mode case, that would
be nice.
Note this in comments.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With Linux 3.11, we have the possibility to debug local netlink traffic
[1] i.e. the workflow looks like this:
Setup:
modprobe nlmon
ip link add type nlmon
ip link set nlmon0 up
Capture:
tcpdump -i nlmon0 ...
Teardown:
ip link set nlmon0 down
ip link del dev nlmon0
rmmod nlmon
For pcap interoperability, introduce a common link type for netlink
captures.
|
| |
|
|
|
|
| |
The "frame" size is used to carve the mapped region into buffers that
contain variable-sized packets; pick a "frame" (buffer) size big enough
to hold a reasonably large packet.
|
| |
|
|
|
| |
Indicate why it's OK to use a tpacket_stats_v3, even for TPACKET_V1 and
TPACKET_V2 (and that we could probably just use a tpacket_stats).
|
| |
|
|
|
|
| |
We use its value, but, if we only partially processed the current block
of packets in the previous call, current_packet will be non-null, and we
wouldn't have *fetched* its value.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Do all the crap we have to do in order to try to pick a slot size that's
not too big only for TPACKET_V1 and TPACKET_V2. The kernel does sanity
checking of the slot size and slot count even for TPACKET_V3, so we have
to pick *some* value; just pick a slot size of 65536.
Also note that using a struct tpacket_req3 for the setsockopt request is
OK even for TPACKET_V1 and TPACKET_V2.
|
