| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Some code already was doing that (for example, pcap-bpf.c if fetching
the DLT list with an ioctl), and, if you can't allocate a DLT_ list,
which is usually pretty small, you may have other memory allocation
problems later, so letting the program open an interface (and not get a
correct list of all link-layer types supported) may not be worth it.
|
| |
|
|
|
| |
This avoids potential and, in one case (SIMH), actual collisions with
names in other libraries or in applications using libpcap.
|
| |
|
|
| |
[skip ci]
|
| |
|
|
|
|
|
|
|
|
| |
Fix this cppcheck warning:
pcap-tc.c:1127:3: warning: %u in format string (no. 1) requires
'unsigned int' but the argument type is 'signed int'.
[invalidPrintfArgType_uint]
snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "Mode %u not supported by TurboCap
devices. TurboCap only supports capture.", mode);
^
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
This allows us to update the support for newer APIs in the future - and
in the present, with pcap_set_datalink() - and would allow Npcap to
remove its AirPcap support.
Add another test program, while we're at it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
That's how to do it for modules that do filtering in the module itself;
there's no need for a wrapper.
|
| |
|
|
| |
Should fix GitHub issue #764.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
install_bpf_program() already fills in the errbuf; there's no need to
set it in the caller of install_bpf_program().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
HAVE_REMOTE implies that there's some feature in our build environment
that we have, but this is a flag that controls what the user specified
at configuration time.
|
| | |
|
| |
|
|
| |
Make it clearer why we have a set_datalink_op that just says "OK".
|
| |
|
|
|
|
|
| |
Clean up the error messages (and indentation) a bit.
Catch attempts to get non-blocking mode before we're activated, just as
we do after it's activate.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We just set a flag and attempt to set non-blocking mode after
activating.
If a module can't support non-blocking mode, it should set the set
non-blocking operator in the create routine, so a pre-activation call
will fail the same way a post-activation call fails.
While we're at it:
Have the get non-blocking and set non-blocking modes not take an error
buffer as an argument; they have the error buffer in the pcap_t to set.
pcap_getnonblock() and pcap_setnonblock() just copy the error from there
to the argument passed in.
Make sure we set the cleanup op pointer when appropriate.
|
| | |
|
| |
|
|
|
| |
ps_capt, ps_sent, and ps_netdrop are only available on Windows if
HAVE_REMOTE is defined; don't set them otherwise.
|
| |
|
|
|
|
|
|
|
| |
* CAN bus over USB on Linux
* DAG
* D-Bus
* Septel
* SNF
* TurboCap
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The last argument to pcap_oid_get_request() and pcap_oid_set_request()
is a pointer to the length, not the length itself, so call it lenp
rather than len. Update comments to speak of "*lenp" rather than "len"
being the length.
|
| |
|
|
|
|
|
|
| |
An OID get request may return less data than requested; pass a pointer
to the length to pcap_oid_get_request(), so that it can supply the
amount of data actually supplied. It also appears that a set request
may copy less data than supplied, so do the same for
pcap_oid_set_request().
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
The raw data should just be an array of u_char.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Have them take the OID, the buffer, and the length as arguments, and,
for pcap-win32.c, have the routines for those calls allocate a
PACKET_OID_DATA, fill it in as appropriate, and copy the data back.
Yeah, it's more work and another memory allocation, but it's still a
cleaner API and avoids some compiler warnings.
|
| | |
|
| |
|
|
|
|
| |
Consistently avoid unnecessary parentheses in return statements.
(If somebody prefers them, feel free to consistently use them.)
|
| |
|
|
|
| |
That was there through sloppy copy-and-pasting; there's nothing NDIS
OID-related there.
|
| |
|
|
|
|
| |
It's now "exported" through the pcap_t ops vector, rather than being
directly called from pcap-win32.c, so make it static again and remove it
from pcap-tc.h.
|
| |
|
|
|
| |
Set it for pcap-win32.c. Fix the name, and set it (and bring
TcSetUserBuffer() back from the dead), for pcap-tc.c.
|
| |
|
|
|
| |
Since TcGetReceiveWaitHandle() is already in pcap-tc.h (cannot be static here).
I dropped TcSetUserBuffer() since set_userbuffer_op is missing.
|
| |
|
|
|
| |
"md.use_bpf" is now "filtering_in_kernel", but we always do the
filtering in our module, so there's no need to record that fact.
|
|
|
1) It's also apparently supported on Linux.
2) This cleans it up to match the way we're currently dealing with pcap
modules.
3) This cleans it up to the way we're handling the Win32 extensions.
Fix the configure script so that, if a pcap module that is supported
only if the relevant support software is available is being configured
in, we *add* its source to the list of source files to compile, rather
than making it *the* source file to compile, in case there's more than
one of them.
Fix a typo in a comment.
Add a comment about TurboCap using DLT_PPI for Ethernet.
Move the struct pcap_stat used for pcap_stats_ex() into the pcap
structure on Windows, as it's used by multiple modules.
Remove the stuff that handles TurboCap from pcap-win32.c, as the
routines that did that are now just module ops, so we call the TurboCap
versions for TurboCap devices.
Remove the stuff that handles remote captures from there as well; that
will eventually be handles by modules (plural) for the remote capture
protocols (plural).
Make all of the fields added to struct pcap_stat dependent on _WIN32 and
HAVE_REMOTE being defined. We don't want any of them for UN*X, as that
would potentially break binary compatibility; we make them all dependent
on HAVE_REMOTE being defined because that's what WinPcap currently does
(yes, that's a bad idea, but we'll be fixing this by deprecating that
structure as well as pcap_stats() and pcap_stats_ex() in favor of
something a bit more pcapng-like, which would be more extensible).
|
