| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* amount
* anymore
* authentication
* availability
* bracket
* captured
* casted
* communications
* compliant
* configurable
* cumulate
* deinitialize
* descriptors
* didn't
* disassembler
* disassociate
* distributions
* divvy
* doing
* entries
* everything
* explicitly
* explosion
* expression
* extracting
* failed
* family
* find
* github
* global
* implementations
* incorrectly
* intel
* interlocked
* justifying
* know
* launched
* libraries
* malloced
* mask
* maximum
* network
* nonexistent
* number
* occurred
* optimizer
* overflow
* overwrite lower
* packet
* packetfilter
* packets
* parse hosts
* payload
* phase
* programmers
* promiscuous
* protocol
* receiving
* redefinition
* sampling
* savefile
* schwartz
* should
* snapshot
* something
* specifies
* straightforward
* stream
* subdir
* support
* surrogate
* suse
* system is
* test with
* than
* those
* unmaintained
* valid
* way
* western
* wireshark
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
|
| |
This avoids potential and, in one case (SIMH), actual collisions with
names in other libraries or in applications using libpcap.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change should avoid these cppcheck warnings:
pcap-hurd.c:77:18: warning: 'p->buffer' is of type 'void *'. When using
void pointers in calculations, the behaviour is undefined.
[arithOperationsOnVoidPointer]
pkt = p->buffer + offsetof(struct net_rcv_msg, packet)
^
pcap-hurd.c:78:8: warning: 'p->buffer+offsetof(struct net_rcv_msg,packet)'
is of type 'void *'. When using void pointers in calculations, the
behaviour is undefined. [arithOperationsOnVoidPointer]
+ sizeof(struct packet_header) - ETH_HLEN;
^
pcap-hurd.c:79:25: warning: 'p->buffer' is of type 'void *'. When using
void pointers in calculations, the behaviour is undefined.
[arithOperationsOnVoidPointer]
memmove(pkt, p->buffer + offsetof(struct net_rcv_msg, header),
^
Remove some '(u_char *)' casts accordingly.
|
| |
|
|
|
|
| |
This issue was reported by Andrea Odetti in GH #1083.
|
|
|
|
|
|
|
|
|
| |
Fix non-blocking mode with bt-linux and bt-monitor-linux. Previously
when fd was set to non-blocking mode and pcap_dispatch() was called
from application, it returned -1 with errno EAGAIN breaking the api
contract.
Fix is to handle errnos EAGAIN and EWOULDBLOCK so that 0 is returned.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sizeof operator and alignof macro can be given a type "name" that's
anonymous, e.g. sizeof(struct { int a; char *b; }). Have
pcap_create_common() and pcap_open_offline_common() take, as arguments,
the total size of a structure containing both the pcap_t and the private
data as members, and the offset of the private data in that structure,
and define macros that calculate those given, as an argument, the data
type of the private data.
This avoids making assumptions about the alignment of those two items
within the structure; that *might* fix GitHub issue #940 if the issue is
that the ARM compiler being used does 16-byte alignment of the private
structure, rather than the 8-byte alignment we were wiring in.
|
|
|
|
|
| |
That way, we don't have to do the check in the individual setdirection
op routines.
|
|
|
|
|
|
|
|
| |
Say "...on this device" for errors; it may be the OS's capture mechanism
that doesn't support setting the direction, but there may be other
devices on the system that *do* support it.
Check the validity of the direction argument in more places.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Require Visual Studio 2015 or later; fail if we don't have it, and
remove checks for older versions.
That means we have C99-compliant snprintf() and vsnprintf(); require
them when configuring for UN*X, and then use them directly, rather than
having wrappers for systems lacking them.
If we're using MSVC, skip the tests for options to request C99
compatibility - either we have VS 2015, which is sufficient, or we
don't, in which case we fail.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If net/bpf.h declares bpf_filter() one way and libpcap defines it
another way, even pcap-bpf.c needs a declaration that matches how
libpcap defines it, not how net/bpf.h (mistakenly) declares it.
("Mistakenly" because it should *not* be declaring the kernel's version
of bpf_filter() unless it's being used in a *kernel* build; other *BSDs,
and macOS, declare it only in kernel builds by testing for a #define
such as KERNEL or KERNEL_PRIVATE, but NetBSD doesn't - it *should*, but
it doesn't.)
So we rename the internal-to-pcap filtering routine as pcap_filter(),
which is not exported from libpcap, and have bpf_filter() be a wrapper
around pcap_filter() that is exported.
Use pcap_filter(), rather than bpf_filter(), for all filtering inside
libpcap (except for filtering that uses bpf_filter_with_aux_data(),
which we rename pcap_filter_with_aux_data()).
Do the same for bpf_validate(), which is *also* declared in net/bpf.h,
even for non-kernel builds, in NetBSD.
As we're not exporting pcap_filter_with_aux_data(), don't even *declare*
it in a public header; don't declare struct bpf_aux_data in a public
header, either. That way we can change it without worrying about
breaking APIs or ABIs; we may do that if, for example, we want to
support the "inbound" and "outbound" filters when reading pcapng files,
adding a direction indicator to that structure.
Declare bpf_filter() in pcap/bpf.h even on NetBSD and QNX; pcap-bpf.c
doesn't include pcap/bpf.h (it sets a #define to force pcap/pcap.h not
to include it), so we won't get any collisions if net/bpf.h (which it
does include) declares it. The only collisions will occur in programs
that include *both* pcap/pcap.h or pcap/bpf.h *and* net/bpf.h, and that
will occur only if net/bpf.h declares bpf_filter() even when building
userland code, and the correct fix for *that* is to fix net/bpf.h not to
declare them in non-kernel builds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add_dev() does not imply a particular string length for the name and the
description, so it is OK just to increase the buffer size to make the
description fit. While at it, use sizeof() for snprintf() and unsigned
props for the unsigned structure members from <bluetooth/hci.h>.
./pcap-bt-linux.c: In function ‘bt_findalldevs’:
./pcap-bt-linux.c:115:58: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 5 [-Wformat-truncation=]
pcap_snprintf(dev_descr, 30, "Bluetooth adapter number %d", i);
^~
./pcap-bt-linux.c:115:32: note: directive argument in the range [0, 2147483646]
pcap_snprintf(dev_descr, 30, "Bluetooth adapter number %d", i);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We add:
PCAP_IF_WIRELESS, which indicates whether the interface is "wireless" or
not.
PCAP_IF_CONNECTION_STATUS, which is a bitmask for a two-bit field that
can have one of the values:
PCAP_IF_CONNECTION_STATUS_UNKNOWN if the status of whether the interface
is "connected" or "disconnected" is unknown;
PCAP_IF_CONNECTION_STATUS_CONNECTED if the interface is "connected";
PCAP_IF_CONNECTION_STATUS_DISCONNECTED if the interface is
"disconnected";
PCAP_IF_CONNECTION_STATUS_NOT_APPLICABLE if the notion of "connected" or
"disconnected" doesn't apply to this interface.
Take that into account when sorting interfaces in the interface list,
penalizing "disconnected" interfaces, as you won't see traffic on them
if they're not wireless and you'd have to be in some form of "monitor
mode" to see traffic on them if they're wireless.
This should address GitHub issue #700.
|
| |
|
|
|
|
|
|
|
|
|
| |
Rather than rolling our own autoconf macros to test for the existence of
data types and structure members, use AC_CHECK_TYPES and
AC_CHECK_MEMBERS.
That cleans the configure script code up a bit, and makes it a bit more
like the CMakeLists.txt file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That routine will use strerror_s() or strerror_r() if available, in a
fashion that's thread-safe. Otherwise, it falls back on
pcap_strerror().
Use it in both libpcap and rpcapd.
Given that we check for errors in strerror_r(), hopefully this will
squelch warnings with newer version of GCC and GNU libc; whilst the
macOS (and other BSD-flavored?) strerror_r() always fills in a message,
that's not required by the Single UNIX Specification, as far as I can
tell, so we apparently really *do* need to check for errors.
|
|
|
|
|
|
|
|
| |
This can prevent bizarre failures if, for example, you've done a
configuration in the top-level source directory, leaving behind one
config.h file, and then do an out-of-tree build in another directory,
with different configuration options. This way, we always pick up the
same config.h, in the build directory.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, initialize the snapshot length to 0, meaning "not specified", so
that the default snapshot length, if not specified, is also
module-dependent.
That way, D-Bus has a maximum and default of 128MB, as that's the
maximum message size, but other capture devices have the current
MAXIMUM_SNAPLEN, so we can handle full-size D-Bus messages without
advertising an overly-large snapshot length for other devices,
potentially causing libpcap and programs using it or reading libpcap
files to allocate overly-large buffers for other capture devices.
|
|
|
|
|
|
|
| |
It's not part of the API, but it's an internal structure used by the
findalldevs code. Currently, it just has a pointer to the beginning of
the list, but it could change in order to speed up the process of adding
to the list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Have a routine that unconditionally adds a device to the list of
devices, without bothering to check whether there's already a device
with that name, and a separate routine that does the check and, if it
doesn't find the device, calls the routine to add ti. That avoids
scanning the entire list in cases where we know the search will fail.
The only reasons for doing the check are that we're on a platform where
we find the list of interfaces by a call that returns a list of
*addresses*, with an interface name attached to each address, and
1) for each address, we need to make sure we don't already have
the interface, create it if we don't, and add the address to
the now-guaranteed-to-exist entry for the interface;
2) we might have to make a *separate* call to enumerate
interfaces, to find interfaces with *no* addresses, and that
call also enumerates the ones that *do* have addresses, and
we don't want to create a duplicate entry for them.
Change some findalldevs helper routines to have "dev" rather than "if"
in the name, as not all devices are regular network interfaces.
For the DAG findalldevs routine, make sure it always provides an error
message if it fails.
We don't need add_addr_to_iflist() or get_if_description() on Windows,
so don't define them on Windows.
Update comments to reflect reality.
|
| |
|
|
|
|
|
|
|
| |
For local captures, it's jut the device. If we add remote capture
support, we'll be handed a URL, and will split the URL into multiple
components, and will store the various components in the opt structure,
with the path of the URL being opt.device.
|
|
|
|
|
|
|
|
|
|
|
| |
On UN*Xes with snprintf(), we just #define pcap_snprintf to snprintf.
On UN*Xes without snprintf(), we provide our own, but call it
pcap_snprintf().
On Windows, we have a routine that wraps _snprintf(), with C99 semantics
(ensuring null termination if the string won't fit), called
pcap_snprintf(), and use that.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Yes, in some sense, it's an array of bytes - on modern processors, *all*
data is ultimately an array of bytes - but different modules will use it
in different ways, not all of which will be an undifferentiated array of
bytes.
This squelches a complaint from the Clang static analyzer.
Clean up some code while we're at it.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
when they are added to top of the list of devices
|
|
|
|
|
| |
"private" is a C++ keyword; rename the "private" member of a pcap_t to
"priv" to avoid that, as per Gisle Vanem's suggestion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Put the private data right after the pcap_t structure, with a pointer to
it in the pcap_t.
The initial goal is to allow new pcap modules to be added without having
to hack pcap-int.h.
In the longer term, we may want to freeze the pcap_t structure, except
possibly for adding new method pointers at the end, and provide an ABI
for adding modules.
We also put the stuff used by the read path at the beginning of the
pcap_t structure, to try to keep it on the same set of cache lines.
|
|\
| |
| |
| |
| | |
Conflicts:
pcap-bt-linux.c
|
| |
| |
| |
| | |
There is a missing field to fill to get Bluetooth to work.
|
|/
|
|
|
|
|
|
|
|
|
| |
In the 2.6.32.4 kernel, struct sockaddr_hci has no hci_channel member.
In the 3.0.4 kernel, struct sockaddr_hci has an hci_channel member, and
it has to get set in order for binds of AF_BLUETOOTH/BTPROTO_HCI sockets
to work.
Cope with this API breakage by checking whether struct sockaddr_hci has
an hci_channel member and, if it does, set it to HCI_CHANNEL_RAW.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Have a table of routines to do pcap_create() for devices that aren't
regular network interfaces. Try each of those in succession until one
says "it's mine" (whether it succeeds or fails); if none do, do a
pcap_create() for a regular interface.
Have those routines do more stringent tests of the name - don't just
accept any name that has a particular substring anywhere in it. That
reduces the likelihood of a false match (as happened with the CANbus
module when somebody renamed their Ethernet interface "canopy").
Have the table also include routines for pcap_findalldevs().
|
|
|
|
|
|
|
|
|
| |
This makes the check for a negative value valid.
Thanks to Michal Sekletar for catching this.
While we're at it, don't use the numerical value of errno in error
messages.
|
|
|
|
|
|
|
|
|
| |
The "set the buffer size" code check for a zero, rather than a non-zero,
opt.buffer_size when deciding whether to explicitly set the buffer size.
Fix a typo in a comment.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
|
|
|
|
|
|
|
|
|
|
| |
Do the standard userland filtering on USB and Bluetooth captures, rather
than returning "success" when the filter is installed without doing
anything with the filter.
Also, squelch some "dereferencing type-punned pointer will break
strict-aliasing rules" warnings in pcap-bt-linux.c, by using memcpy
rather than pointer-casting.
|
| |
|
|
|
|
| |
different modules can lead to confusion).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used to clean up after a failed pcap_activate() call. Convert the
existing close_op routines to cleanup_op routines, and use them to clean
up; rename pcap_close_common() to pcap_cleanup_live_common(), and use it
directly if there's no platform-dependent cleanup needed. That means we
don't have to write the same cleanup code twice (and possibly forget
stuff in the version done on a failed pcap_activate() call).
Have the cleanup routines do whatever is necessary to indicate that
cleanup has been done, and not do any particular cleaning up if it's
already been done (i.e., don't free something if the pointer to it is
null and null out the pointer once it's been freed, don't close an FD if
it's -1 and set it to -1 once it's been closed, etc.).
For device types/platforms where we don't support monitor mode, check
for it and return PCAP_ERROR_RFMON_NOTSUP - but do so after we've
checked whether we can open the device, so we return "no such device" or
"permission denied" rather than "that device doesn't support monitor
mode" if we can't open the device in the first place.
Fix a comment.
|
|
|
|
|
|
|
| |
captures, set the socket buffer size to the value specified by
pcap_set_buffer_size() if a value was set.
Clean up if memory buffer allocation fails on Linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handle" routine, an 'activate a pcap_t handle" routine, and some "set
the properties of the pcap_t handle" routines, so that, for example, the
buffer size can be set on a BPF device before the device is bound to an
interface.
Add additional routines to set monitor mode, and make at least an
initial attempt at supporting that on Linux, *BSD, and Mac OS X 10.4 and
10.5. (Very much "initial" for Linux, which is a twisty little maze of
wireless drivers, many different.)
Have a "timeout" member of the pcap_md structure on all platforms, use
that on Windows instead of the "timeout" member of the pcap_t structure,
and get rid of the "timeout" member of that structure.
|
|
|
|
|
| |
all versions of glibc support it, and it handles both 32-bit and 64-bit
size_t.
|