| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
If there's a direction indicator in the packets we get, we should allow
the direction to be set and should check it if it's "incoming only" or
"outgoing only". Otherwise, we shouldn't allow the direction to be set.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Starting from version 5.1 BlueZ no longer exports the mgmt.h header
or any other header that declares the structure of packets passed
over HCI sockets set to use the HCI monitor channel.
Declare the structure locally and give it the same name as in the
Linux kernel 3.4+.
|
| |
|
|
|
|
|
|
|
| |
The warnings were:
./pcap-bt-monitor-linux.c:51:1: warning: no previous prototype for 'bt_monitor_findalldevs' [-Wmissing-prototypes]
./pcap-bt-monitor-linux.c: In function 'bt_monitor_read':
./pcap-bt-monitor-linux.c:74:9: warning: unused variable 'in' [-Wunused-variable]
./pcap-bt-monitor-linux.c: At top level:
./pcap-bt-monitor-linux.c:219:1: warning: no previous prototype for 'bt_monitor_create' [-Wmissing-prototypes]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support the Linux Bluetooth Monitor mechanism if:
we support Linux Bluetooth;
struct sockaddr_hci includes an hci_channel field;
HCI_CHANNEL_MONITOR is defined by the Bluetooth headers;
as there are some 3.x kernel versions in which struct sockaddr_hci
includes an hci_channel field but in which HCI_CHANNEL_MONITOR is not
defined.
|
|
|
Interface "bluetooth_monitor" is used to monitoring all Bluetooth
adapters together on Linux platform.
|
