Unable to activate the adapter (NpcapRemoteCapture Example)

[exp1azy]

I'm trying to connect to a remote computer and get its interfaces, the IP address of which is entered in the command line arguments, and the port is set to default 2002:

var remoteInterfaces = PcapInterface.GetAllPcapInterfaces(new IPEndPoint(ipAddress, port), null);

I get the remote computer interface in the line above and in the line below I try to open the device to capture:

device.Open(new DeviceConfiguration { ReadTimeout = 500 });

on this line I get an exception:
SharpPcap.PcapException: "Unable to activate the adapter (rpcap://[#Remote IP#]/\Device\NPF_{#SOME_GUID#}). (Error Code: Generic)".

WinPcap is installed on the local computer, as well as Npcap version 0.991, because I read that this error disappears with this version (On the latest version, I didn’t even get the remote computer’s interfaces! There were only mine for some reason). The rpcap.exe daemon is running on the remote computer on port 2002.
Using Wireshark I was able to get the same interface of the remote computer and start intercepting packets, but using the library I can't do it.

How can I fix that?

[kayoub5]

Npcap broke the remote capture support when they took over the WinPcap project, see nmap/npcap#312 and nmap/npcap#74 this is not an issue with sharppcap itself.

To use remote pcap, use libpcap (depending on disto, it could be disabled by default), or WinPcap

[daluu]

Just to get some clarity, is libpcap option usable on Windows platform for this library or is only for Linux platforms? It wasn't clear looking at the README file. I haven't used this library myself so haven't looked through any documentation.

Asking as winpcap is kind of deprecated/obsolete with newer versions of Windows? So really users are left with npcap or libpcap. And npcap offers an installer, on Windows I assume user will have to build libpcap from source? And then i'm wondering where might the user have to place or register the built libpcap sources (some DLLs), perhaps under C:\Windows\system32? like packet.dll, assuming that is one of the outputs of libpcap on Windows - because winpcap and ncpap have that. Based on reading https://omnine.blogspot.com/2020/08/wireshark-remote-capture-with-rpcapd.html.

[kayoub5]

libpcap is Linux/macos only, Npcap is a commercial port of libpcap, WinPcap is the predecessor of Npcap, and abandoned by its maintainers.

Libpcap can be compiled to work on Windows, but then you would only have offline api (read/write pcap), with no network access due to the lack of a driver.

[daluu]

For anyone interested in this further, and still having issues, I'd be interested how it is working on Wireshark but not here. Because latest Wireshark uses Npcap by default, and remote pcap (client) works there.

I'm assuming this issue may go away if user upgrades to a newer or latest npcap version? Per the referenced npcap issue link for client side rpcap, the fix was in npcap v0.9983+, and there was upgrade of libpcap used by npcap in v1.31+.

[kayoub5]

Wireshark have its own rpcap imlimentation it does not use libpcap or npcap for remote capture.

[guyharris]

Wireshark have its own rpcap imlimentation it does not use libpcap or npcap for remote capture.

That is... not the case. Wireshark calls pcap_findalldevs_ex() to enumerate remote devices and calls pcap_open() to open remote devices. It does not have its own implementation of the rpcap protocol, although it does have a dissector for that protocol.

[guyharris]

libpcap is Linux/macos only,

The 1.10 branch of libpcap supports:

• Linux;
• macOS/*BSD/Solaris 11/AIX (AIX capture support not tested; it may have issues), all using the same capture mechanism (the BPF capture mechanism, not to be confused with the BPF filtering mechanism, which it supports);
• HP-UX/Solaris 10 and earlier, using the DLPI capture mechanism, although the HP-UX support may suffer from code rot;
• Tru64 UNIX, using the pf capture mechanism, although that may suffer from code rot;
• IRIX, using the snoop capture mechanism, although that may suffer from code rot;
• SunOS 3.x and 4.x, using the NIT and STREAMS NIT capture mechanisms, although that may suffer from code rot;
• Haiku, with some new code;
• Windows - including capture support if you have downloaded and installed the WinPcap or Npcap SDK and pointed CMake at it when configuring libpcap, as per libpcap's README.windows.md file.

The main branch has dropped support for many of the code-rotted platforms.

Npcap is a commercial port of libpcap,

...based on the most recent 1.10.x release of libpcap.

WinPcap is the predecessor of Npcap, and abandoned by its maintainers.

...and has never been updated to a recent version of libpcap (and "abandoned by its maintainers" means it almost certainly will never be updated).

Libpcap can be compiled to work on Windows, but then you would only have offline api (read/write pcap), with no network access due to the lack of a driver.

Unless you install WinPcap and the WinPcap SDK, or Npcap and the Npcap SDK, and configure and build libpcap as described above.

[kayoub5]

For compiling libpcap without Npcap/WinPcap, look at the conan recipe of libpcap https://github.com/conan-io/conan-center-index/blob/master/recipes/libpcap/all/conanfile.py there is no sdk steps involved there.

For wireshark, it could have been that I was looking at the wrong files.

It could be that client support was fixed since I last tested npcap, if it's working in wireshark then it should also work in sharppcap.

try passing a non null credentials object.

[guyharris]

try passing a non null credentials object.

If you mean "try connecting with a username and password", if I run rpcapd as root on Linux, it "works" to the extent that libpcap, as run by Wireshark, can connect and enumerate devices, but attempting to capture on one of those devices fails because rpcapd starts running with the user ID for the username, and that user doesn't have sufficient privileges to capture. It doesn't work on macOS, but that's because macOS requires you to go down the rathole of PAM to do user/password authentication, and nobody's written that code yet (it's On My List(TM)).

[kayoub5]

You don't have to pass a username/password, just a non null credentials object

The credentials object can still use null authentication with no username / password.

reason is that sharppcap decides to use pcap_create instead of pcap_open based on the presence of a credentials object, and as far as I know, libpcap support remote pcap only with pcap_open

See https://github.com/dotpcap/sharppcap/blob/master/SharpPcap/LibPcap/LibPcapLiveDevice.cs#L129

[guyharris]

reason is that sharppcap decides to use pcap_create

Which is, currently, a mistake when doing remote capture. Properly suporting the pcap_create()/pcap_activate() requires more API work.

and as far as I know, libpcap support remote pcap only with pcap_open

Yes.

The pcap_create()/pcap_activate() was developed after WinPcap added pcap_open() and before the remote-capture code was added to mainstream libpcap.

[kayoub5]

reason is that sharppcap decides to use pcap_create

Which is, currently, a mistake when doing remote capture. Properly suporting the pcap_create()/pcap_activate() requires more API work.

what's the "correct" logic then?

and as far as I know, libpcap support remote pcap only with pcap_open

Yes.

The pcap_create()/pcap_activate() was developed after WinPcap added pcap_open() and before the remote-capture code was added to mainstream libpcap.

Any plans to add remote capture support to pcap_create?

[guyharris]

what's the "correct" logic then?

What tcpdump does is

#ifdef HAVE_PCAP_OPEN
    if (device name begins with "rpcap://" or "rpcaps://") {
        use pcap_open()
        return the results of that
    }
#endif

#ifdef HAVE_PCAP_CREATE
    use pcap_create() and pcap_activate()
#else
    use pcap_open()
#endif
    return the results of that

Wireshark's logic is similar, although the "is this a remote capture?" test is done separately and earlier and the device's information has that as an attribute attached to it.

[guyharris]

Any plans to add remote capture support to pcap_create?

Plans, yes; scheduled plans, no, but it won't be in 1.10.x. Note that there will be additional return values from pcap_activate(), such as "authentication failed".