search

nmap / npcap

Nmap Project's Windows packet capture and transmission library
https://npcap.com
Other
2.98k stars 514 forks source link

Add/Test rpcap client support to Npcap #312

Open 1001QAdotNET opened 5 years ago

1001QAdotNET commented 5 years ago

It seems that if I use winpcap it will work I am trying to switch my system to npcap I am running Windows 10 Business and Wireshark latest version with the latest version of Ncap I am trying to run a remote capture, the remote system is Ubuntu, rpcapd compiled from the sources managed by the tcpdump project

I am not seeing any traffic hitting the remote system when Wireshark is trying to retrieve the remote interfaces. Is this a well known problem? Are the above components compatible with each other?

fyodor commented 5 years ago

Thanks for your note. rpcapd is not something we've looked into too much for Npcap, but it is on our radar. Please see nmap/npcap#74. I'm closing this as a duplicate of that one, but feel free to continue the discussion on nmap/npcap#74 as desired.

guyharris commented 5 years ago

@fyodor This isn't exactly a duplicate, as I read this bug and nmap/npcap#74.

Remote capture support in libpcap includes both client and server code; both autotools and CMake have an option, which is off by default, to enable building both the client code in the libpcap library and the server code in the rpcap daemon.

I don't know whether the Npcap builds are using CMake or the out-of-date-and-not-very-well-maintained Visual Studio files in the Win32/Prj subdirectory of the libpcap source.

If they're using CMake, then, if they run CMake with the flag -DENABLE_REMOTE=YES, then the VS files generated by CMake will cause the client and server code to be built.

If they're using the project files, it appears that the client code, but not the server code, will be built, but I just did a quick grep of the project files for "rpcapd" and didn't find anything - maybe it's more subtle than that.

This bug appears to be asking whether the client code is compiled into Npcap's version of the libpcap DLL. nmap/npcap#74 appears to be asking whether the server code - rpcapd.exe, on Windows - could be shipped with Npcap.

(WinPcap provided both.)

guyharris commented 5 years ago

It appears that Npcap is shipping remote capture client code; however, that code is buggy. See nmap/nmap#1506.

guyharris commented 4 years ago

Npcap should now be shipping non-buggy remote capture client code, as of 0.9983.

eliassal commented 3 years ago

Hi, can you please let me know how to add a remote interface using NpCap on a server?

fyodor commented 3 years ago

OK I understand now that this isn't a duplicate of #74, so I'm reopening. This issue is about rpcap CLIENT support (capturing packets from a remote rpcapd) while #74 is about including the rpcap server (rpcapd) with Npcap so external systems can listen in through that server. Libpcap apparently already has working code to do this and we recently upgraded to Libpcap 1.10, so it may work already. Has anyone tested with Npcap 1.31?

daluu commented 6 months ago

So it's not quite clear about this particular issue request. How exactly should people test that the client support is working with npcap? Should just using recent/latest Wireshark (where ncap is installed as the dependency, not winpcap) as rpcap client be sufficient or is there other use cases to cover?

Or how can one test the client aspect from npcap standalone installation itself?

Also, regarding the rpcap support, for the server aspect, rpcapd, there are actually extra steps to get that running, this being a good article: https://omnine.blogspot.com/2020/08/wireshark-remote-capture-with-rpcapd.html. I'm just curious to wonder, does the client side support aspect require any extra steps as well from manually compiling libpcap for the rpcap support, or should we just expect npcap to already have the support given it uses an updated libpcap now?

daluu commented 5 months ago

On a related note, for this it would be nice to consider/test https://github.com/nmap/npcap/issues/721 so that we can ensure or have TLS support for rpcap functionality, to which Wireshark downstream can later make use of in the GUI and CLI as options for rpcap.

guyharris commented 5 months ago

tcpdump can be used to, at minimum, test non-authenticated captures.

The main branch version of libpcap supports putting both a user name and password in the rpcap:// URL, although the latter (and perhaps the former) may be unwise, especially if there are non-privileged tools that allow one to list all processes running on the system, including the arguments passed to the program running in that process.

tcpdump should, if it can determine that a login attempt failed, perhaps be changed to prompt for a user name and password from the command line (if available), with the latter not being echoed. (If it's run non-interactively, if a password is necessary, it would need to get it somehow.)