[Patch] rpcap:// support

[guyharris]

Converted from SourceForge issue 3518553, submitted by darkjames

Attaching patch to support remote pcap (rcpcap:// URLs) There's no rpcap specification, so it's written from winpcap sources + wireshark rpcap dissector. Still it's much more compact than winpcap version (but we miss some API for auto-detecting interfaces, and so on... I'll submit missing API in next patch)

It mostly work, but... something is wrong with filtering. It sometimes work, sometimes don't. (I was testing it with rpcapd on Windows machine)

Cheers, Kuba.

[guyharris]

Submitted by darkjames

Attaching v2 of patch.

Changes from v1:

• fixed filtering

[guyharris]

Submitted by darkjames

Attaching v3 of patch.

Changes from v2:

• use new libpcap interface
• fix port parsing

[fenner]

I could not find the patch attachment. It does appear to be available on sourceforge in http://sourceforge.net/p/libpcap/patches/_discuss/thread/fc8f43a0/ad35/attachment/rpcap3.patch .

[infrastation]

Yes, exactly, I usually copy patches from SF to GH for clarity but that one is really long.

[jmayer]

Would anynone be willing to forward port this patch to current git HEAD and maybe even commit it? Even with it maybe not stable currently it should be committed (possibly disabled by default). The porting work gets done time and again and to no avail.

[infrastation]

@darkjames is the original author of this work.

[darkjames]

If anyone is interested - https://github.com/darkjames/libpcap/commit/c63e80c191c848d4f17b8cb5648849df09004ac1 (compiles-only tested).

[meiser79]

I looked at Wireshark 1.10.7 and it expects the following functions for remote pcap support:

checking whether to use libpcap remote capturing feature... yes checking for pcap_open... no checking for pcap_findalldevs_ex... no checking for pcap_createsrcstr... no checking for pcap_setsampling... no

But these are not implemented in darkjames' patch.

[guyharris]

I looked at Wireshark 1.10.7 and it expects the following functions for remote pcap support:

The APIs that should be used for remote capture would be the same pcap_create() and pcap_activate() used for local capture, as well as assorted new APIs that will have to be introduced to support various forms of authentication. When the API extensions are added, programs will require no change at all to support remote capture if the user doesn't have to be prompted for information; they will only need to be changed to support prompting the user for user name information (although that could be supplied in the URL) and password information (which should _NOT_ be supplied in the URL, as that can show up in the output of ps!) or "we're running over SSL/TLS but the certificate has expired, so do you want me to continue or not?" information or....

At that point, Wireshark (and TShark and dumpcap) will be changed to support that.

This is a work in progress. I have something based on Jakub's patch compiling (on OS X, so I ripped out the check for Linux and the Linuxisms), along with the rpcap daemon, but it still needs work.

[guyharris]

Note also that there will be a configure-script option to enable this, with the default being "no". Enabling remote capture increases the attack surface of an application using libpcap, as it would receive messages from a not-necessarily-trusted remote host; the code to parse them needs to be very careful. The code should, ideally, run without elevated privileges when it's trying to open a remote capture source, as that's not needed, and, if you're going to have a bigger attack surface, you don't want to run with elevated privileges.

The low-level socket access for the client should go through the WinPcap sockutils.c routines, so that it will work on UNX and on Windows, and so that differences between UNXes don't cause an issue (there are some #ifdefs in that code to handle BSDisms and Linuxisms). I have that code in the stuff I'm working on; the rpcap daemon uses it (because that's taken from WinPcap), but I haven't yet changed the client code to do so.

The stuff I'm working on has a table of URL schemes and routines to handle them, so that it could be extended to handle protocols other than rpcap. For example, there could be "tcpdump+ssh", i.e. "ssh over to the remote machine and run tcpdump", and there's a protocol that Wireshark dissects, in which some 802.11 APs (Cisco and somebody else) send out packets over UDP - Wildpackets' OmniPeek handles it directly, and it'd be nice if tcpdump/*Shark/etc. could do so as well.

[meiser79]

May I ask about the status? The feature is still interesting for me.

[guyharris]

Still a work in progress.

I'll probably end up using WinPcap's code, instead, as it's a more complete implementation (supports both Windows and UN*X, handles some cases the reimplementation doesn't seem to), but I need to add a new API for enumerating interfaces, so both opening a device and enumerating interfaces can deal with a variety of ways of authenticating.

[jcreigh]

Would it be possible to get a new patch with at least the partial support?

[guyharris]

I'll probably end up using WinPcap's code

That's currently checked in, albeit...

but I need to add a new API for enumerating interfaces, so both opening a device and enumerating interfaces can deal with a variety of ways of authenticating.

...without the new API, currently. That part's a work in progress.

You have to configure libpcap with --enable-remote, but it seems to work with the tests I've done (macOS client, macOS and Solaris rpcapd built from the current source, Windows rpcapd as distributed in WinPcap; tcpdump, with some additional changes, and Wireshark as clients).

I'll leave it open until I finish all the API work (and code auditing...).

[jmayer]

Would it make sense to fully move the code from pcap-new.c into pcap-rpcap.c? pcap-new.c doesn't seem to have any value outside pcap-rpcap.c.

[guyharris]

Would it make sense to fully move the code from pcap-new.c into pcap-rpcap.c? pcap-new.c doesn't seem to have any value outside pcap-rpcap.c.

My ultimate goal is to have the APIs implemented in pcap-new.c exist only for backwards compatibility with WinPcap, and to have pcap_create()/pcap_activate() be the official way to do remote capture, with a new API for listing remote (and local) interfaces.

The pcap-new.c APIs - and the new active-mode APIs in pcap-rpcap.c - would be useful on UN*X, in that case, only to support 1) porting code from Windows to UN*X and 2) supporting with Windows applications using those APIs under Wine.

However, as the APIs in pcap-new.c could be used by Windows applications to access local interfaces and savefiles, I'd prefer to keep them separate from the private-to-RPCAP code and the RPCAP-only APIs in pcap-rpcap.c.

[jmayer]

So once you ulimately succeed it could be moved into pcap-win32.c? Another thing that I don't like about the file is its name - maybe pcap-win32-aux.c would be a better one before removing it entirely.

[guyharris]

So once you ulimately succeed it could be moved into pcap-win32.c?

No, because pcap-win32.c isn't "pcap extensions for Windows", it's "the pcap capture module, for local capture, that runs atop the WinPcap and NPcap driver and Packet.dll", just as pcap-bpf.c is "the pcap capture module, for local capture, that runs atop BPF" and pcap-linux.c is "the pcap capture module, for local capture, that runs atop Linux PF_PACKET sockets" and.... pcap-win32.c is a misleading name; if somebody came up with a completely different driver+library with a different interface, or if Windows 10 Happy 2018 Edition included a built-in capture API that was at least as capable as what WinPcap/NPcap provide, there could be a module for that, which would also work with WIn32 (and Win64).

Perhaps renaming pcap-new.c to pcap-wpcap-compat.c or something such as that, once none of the routines in it are required for remote capture support, would make sense.

[ghost]

This is a very old ticket! I am trying to compile libpcap with remote capture support but running into this issue, clearly missing something fundamental.

Is this feature supported in latest in latest stable release? I am using 1.8.1

libpcap-1.8.1$ ./configure --enable-remote configure: WARNING: unrecognized options: --enable-remote

checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out

---

[guyharris]

Is this feature supported in latest in latest stable release?

No. It's only in the master branch of the Git repository.

[guyharris]

OK, it's in 1.9.x. Done.