Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
|
|
It's now used only in pcap-rpcap.c.
|
|
It's not a general API, it's a hack for doing active mode with RPCAP.
Make the variables it uses static, as they're not used anywhere else.
|
|
Rewrite a bit, fix typoes we found, and update to reflect current
reality (i.e., the pcap module mechanism, which means that very little
of the common pcap code knows anything about local vs. remote captures,
it just calls functions through pointers).
|
|
That makes it more like the other routines.
|
|
Absorb pcap_opensource_remote() into pcap_open_rpcap().
Make pcap_startcapture_remote() static.
|
|
Pass the interface name, not the full URL, to pcap_create().
If pcap_open_rpcap() fails, copy the error message from the pcap_t to
errbuf, as we'll be closing and freeing the pcap_t.
|
|
Move rpcap_remoteact_getsock() before its caller as part of that
process.
|
|
That's the constant to use on Windows; we define it as -1 on UN*X.
|
|
That means that everything in rpcap is part of rpcapd.
Fix up the list of files included in the tarball while we're at it.
|
|
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.)
|
|
An address that's not AF_INET is not necessarily AF_INET6.
While we're at it, clean up the code that processes the various
addresses in an address entry - let rpcap_deseraddr() do the checks for
AF_INET/AF_INET6 and, if neither the address nor the netmask nor the
broadcast address nor the destination address were allocated, discard
the entry, otherwise add it to the lsit of entries.
|
|
While we're at it, make rpcapd depend on libpcap.a, as we link with it.
|
|
This is a cleanup in the process of adding the rpcap server to the
project.
|
|
|
|
In order to be able to arrange that, when doing a remote capture, the
machine doing the capturing doesn't capture the traffic it sends
containing the captured packets, we have to tweak the user's filter to
filter out traffic to and from the port(s) being used for capturing, and
tell the remote machine to use that as the filter.
WinPcap did this by inserting a hack into pcap_compile() to save the
filter.
We do it by having a hook, called by pcap_compile(), so it doesn't have
to know anything about remote packet capture; we handle that all in our
hook routine.
Ideally, we should do this by compiling the additional filter code
ourselves and combining it with the existing filter code in our
pcap_setfilter routine, and get rid of this hack entirely. That way, we
don't have to *assume* that 1) the filter code being used was generated
by pcap_compile() (which needn't be the case), 2) the filter is in
standard pcap syntax (which it might not be - there's a pull request to
add the ability to specify raw BPF machine code, in binary form, to
pcap_compile()), and 3) nobody ever calls pcap_compile() to compile a
filter that they *aren't* going to hand to pcap_setfilter (which they
might do, e.g. if they're using BPF filters to do packet classification
on packets we hand them).
Fix up some comments while we're at it.
|
|
Also clean up some comments.
|
|
|
|
|
|
The user name and password lengths must fit in a 16-bit field; make sure
they do, and return an eror if they don't.
|
|
|
|
|
|
Also, clean up white space and shuffle some declarations.
|
|
Also define PCAP_STATS_EX only on Windows, as it's used internally only
on Windows.
|
|
That way, we support either 0 or a negative number as a pcap_dispatch()
count meaning "keep processing packets until you run out" and a
pcap_loop() count meaning "keep processing packets forever", as we do
for other capture modules.
While we're at it, shuffle some declarations and get rid of some blank
lines.
|
|
|
|
That's consistent with the names of other ops functions, and emphasizes
that this is specific to the rpcap protocol; there may, in the future,
be support for other protocols for remote capture.
|
|
|
|
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.
|
|
ctrlport is an array, so it needn't be checked against NULL.
In UN*X, the last argument to getsockopt() is a pointer to socklen_t; in
Windows, it's a pointer to int. On Windows, sockutils.h typedefs
socklen_t as int, so use socklen_t as the type of the variable.
In C, for historical reasons, a function with no arguments must be
declared or defined with "void" as the argument list - if there's no
argument list, it's an old-style no-prototype function.
|
|
|
|
That should make it clearer that the timeout does *not* guarantee that a
call that reads packets will return within N milliseconds even if no
packets arrive.
In the pcap_open_live() and pcap_set_timeout() calls, point to the
detailed description of the packet buffer timeout in pcap(3PCAP).
|
|
ps_capt, ps_sent, and ps_netdrop are only available on Windows if
HAVE_REMOTE is defined; don't set them otherwise.
|
|
|
|
A SOCKET is unsigned in Windows, and INVALID_SOCKET is defined so that
you can compare a SOCKET against it without complaints.
|
|
They're not for remote capture in general, they're just for remote
capture using the rpcap protocol.
|