| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
We don't modify the source argument to pcap_findalldevs_ex(), so make
that a promise, so compilers don't get upset when a constant string is
passed.
See, for example:
https://stackoverflow.com/questions/52397129/winpcap-findalldevs-const-char-incompatible-to-char
|
| |
|
|
| |
If we're not building remote support, we won't include this header.
|
| |
|
|
|
|
|
| |
Move the declarations of the interfaces that are currently used for
RPCAP by pcap_open_live(), pcap_open(), and pcap_findalldevs_ex() to
pcap-rpcap.h; in the future, that will hold the routines used by
pcap_create() and any future API for enumerating interfaces.
|
| |
|
|
|
| |
This is preparing for more general support for different types of remote
capture, using pcap_create() and pcap_activate().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We *CANNOT* use struct sockaddr_storage, as the layout and size are
platform-dependent, and that would mean that a client wouldn't be
guaranteed to work with a server running a different OS.
We also *CANNOT* send the OS's AF_ values over the wire, as AF_INET6 has
different values on different OSes.
So we choose a format that resembles the Windows struct
sockaddr_storage, and we choose the Windows AF_ value for IPv6.
We try, as best we can, to handle replies from older servers, although
that won't work with servers sending a struct sockaddr_storage that's
not 128 bytes long. (We could do more, I guess, by checking whether the
total message size, and count of interfaces, are consistent with a
128-byte or 256-byte struct sockaddr_storage.)
|
| |
|
|
|
| |
This is a cleanup in the process of adding the rpcap server to the
project.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a configuration option to enable remote capture in libpcap. It
defaults to being disabled, and, if enabled, warns that it might expose
libpcap-based programs to attack by malicious remote capture servers.
(The code needs to be carefully audite to make sure there aren't any
buffer overflow, etc. exploits before we remove that warning or default
to enabling it.)
Put the sampling parameters into the pcap_t; in theory, at least, it
could be supported by all capture mechanisms, although it's currently
only supported by Win32 local capture and rpcap-based capture.
Have a private data structure for remote capture, just as we do for
local capture sources. Have it contain only what's needed for remote
capture.
Have a pcap_open_rpcap() routine that does all the work of opening a
pcap_t; if remote capture is enabled, call it from pcap_open() and
pcap_open_live() if pcap_parsesrc() indicates that we were handed a
remote capture URL.
Put back the sampling code into the Win32 local capture code. Turn the
static variables used for sampling into members of its private data
structure, so we don't get collisions if there's more than one pcap_t
open.
Don't support remote capture for pcap_create()/pcap_activate() - that
might ultimately involve API changes that existing programs would have
to be changed to handle, such as "username/password needed" and
"authentication failed" error returns for which the application might
prompt or re-prompt for a user name and/or a password - we might, for
example, have a new pcap_create_ routine that would be called by
programs prepared to handle remote capture.
NOTE: this is not the final form of the code; once full remote capture
support is added, with some pcap_create_ routine handling URLs,
pcap_open() and pcap_open_live() will not have to handle URLs
themselves, for example.
|
|
|
They're not for remote capture in general, they're just for remote
capture using the rpcap protocol.
|
