Add separate ENABLE_RPCAPD option to build rpcapd

[netrounds-fredrik]

This PR is related to #955 and shows how rpcapd can be build without having to enable the new and experimental "remote" libpcap API (ENABLE_REMOTE).

[guyharris]

So you're building the experimental daemon for a protocol, but not the client code for that protocol? :-)

[guyharris]

1. This should be supported both by CMake and autotools.

2. There should be a single flag that enables both client and server, with a flag that enables just the server, and perhaps another flag to enable just the client. (Either that, or a single flag that can specify "don't enable any remote capture", "enable only the client", "enable only the server", or "enable both".)

[netrounds-fredrik]

So you're building the experimental daemon for a protocol, but not the client code for that protocol? :-)

Yes. A use-case for this is to run rpcapd on a Linux machine and Wireshark on Windows which has support for the rpcap protocol (https://qnaplus.com/capture-protocol-packets-from-remote-windows-or-linux-computer-using-wireshark/).

[mcr]

I am not seeing ./configure changes here. I guess they are coming.
I believe that we will eventually drop autoconf, but it hasn't happened yet.

[mcr]

Suggested change

	option(ENABLE_RPCAPD "Enable building of rpcapd" ON)
	option(ENABLE_RPCAPD "Enable building of remote capture daemon (rpcapd)" ON)

[mcr]

Suggested change

	option(ENABLE_RPCAPD "Enable building of rpcapd" OFF)
	option(ENABLE_RPCAPD "Enable building of remote capture daemon (rpcapd)" OFF)

[mcr]

Suggested change

	option(ENABLE_REMOTE "Enable libpcap API for connecting to rpcapd" OFF)
	option(ENABLE_REMOTE "Enable libpcap client API for collecting remote captures via rpcapd" OFF)

[mcr]

1. This should be supported both by CMake and autotools.

Yes.

2. There should be a single flag that enables both client and server, with a flag that enables just the server, and perhaps another flag to enable just the client. (Either that, or a single flag that can specify "don't enable any remote capture", "enable only the client", "enable only the server", or "enable both".)

I think that this is a step forward, and if there is demand for that flag, I guess we can add it.

[guyharris]

Yes. A use-case for this is to run rpcapd on a Linux machine and Wireshark on Windows which has support for the rpcap protocol (https://qnaplus.com/capture-protocol-packets-from-remote-windows-or-linux-computer-using-wireshark/).

That's also a use case for an option not to build libpcap at all, just rpcapd. Yes, ./configure --disable-libpcap sounds a bit weird if you're running libpcap's configure script, but.... :-)

[mcr]

Guy Harris <[email protected]> wrote: That's also a use case for an option not to build libpcap *at all*, just rpcapd. Yes, `./configure --disable-libpcap` sounds a bit weird if you're running libpcap's configure script, but.... :-) Building in libpcap statically rather than risk confusion with "system" libpcap makes a lot of sense to me. Even more so on systems that might not have libpcap at all, and one ships rpcapd as part of some debug enablement.

[antoniovazquezblanco]

I have discovered rpcapd recently.

Looking at this PR I wonder if it makes sense to have a separate repos for libpcap and rpcapd. It seems that it makes sense to enable and disable both libpcap building as well as rpcapd server and client.

Please excuse me if this makes little or no sense as I am getting in touch with this tool.

Thanks!

[guyharris]

Looking at this PR I wonder if it makes sense to have a separate repos for libpcap and rpcapd.

The libpcap client for the rpcap protocol, and the rpcapd server for the rpcap protocol, share:

• the sockutils.c code that provides APIs for networking that 1) provide some convenience and 2) handle differences between UN*X sockets and WinSock and between various UN*X socket implementations;
• the sslutils.c code that provides convenience routines for doing TLS;
• the rpcap-protocol.c code that provides APIs for handling the rpcap protocol;
• the fmtutils.c code for formatting error messages.

Having separate copies of those in two repositories would complicate maintenance of that code - changes to that code in one repository would have to be propagated to the other repository. There might be ways to untangle the dependencies, but it'd take more thought to come up with a good way to do it.