| 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of them are locale-dependent, and all of them run the risk of
failing if you hand them a char with the 8th bit set.
Define our own locale-independent macros that can be handed any integral
value.
Don't include <ctype.h>.
This should address the issue in GitHub pull request #839, and should
also catch any (highly unlikely) cases in which something other than
Boring Old Space And Tab and, sometimes, CR and LF are treated as white
space. (No, we don't want FF or VT treated as white space.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Hiding it inside "if (0)" causes "code not reachable" warnings.
|
| | |
|
| |
|
|
|
|
|
| |
Note that we should be checking for FreeBSD *and* DragonFly BSD (perhaps
we should be checkign for IFF_PPROMISC and ifr_flagshigh).
Add comments explaining what we're doing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resolve two problems:
1. When uint32_t if_flags is bigger than SHORT_MAX then assigning it to the
short ifr_flags is "implementation-defined" ie. it may give diffrent results
on different compilers/machines (according to C11).
2. When the short ifr_flags has MSB set to 1 then it is "negative signed".
If it will be assigned to the uint32_t if_flags then in result of integer
promotion all bits higer than MSB will be set to 1 and therefore in if_flags
we will see flags that are not really set. This problem affects only FreeBSD
where flags are stored on all 32 bits (on Linux only 16 bits are used).
Using 16-bits mask resolves both problems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Indicate why we don't try to enumerate netmap devices, and mark the
arguments to the findalldevs routine as unused while we're at it.
|
| | |
|
|
|
Based on https://github.com/luigirizzo/netmap-libpcap.
|
