New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

npcap & rpcapd support #1329

Open
ether42 opened this Issue Sep 18, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@ether42

ether42 commented Sep 18, 2018

Hi there,

I gave a try at rpcapd (via WinPCAP on Windows and libpcap master on Linux) and it seemed to fit our usage nicely. It seems broken (it probably worked one time out of ten and when it doesn't it reports some number of packets but won't forward them) on Windows 2016 (and probably Windows 10 from some reports I saw) but works fine on Windows 2012.

I quickly looked at different mailing lists & issues trackers hoping the problem was already reported or known and I stumbled on npcap.

WinPCAP seems frozen and I don't have much hope to make it work out the box without probably having to debug/recompile it (and I'll probably have issues later since I won't be able to sign it? I'm not well versed in Windows development, sorry :)).
Installing npcap in WinPCAP compatibility mode will make rpcapd.exe simply quit immediately and there doesn't seem to be an rpcapd server embedded with npcap.

Do you have any plans to provide rpcapd (which is now available from libpcap with configure --enable-remote) and the corresponding service or do you have any clue why npcap's compatibility mode seems to make rpcapd.exe from WinPCAP exit?

Thanks!

Regards.

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Sep 18, 2018

We haven't done much testing with rpcapd, so I'm not surprised that there are some bugs there. Since the-tcpdump-group/libpcap has taken ownership of the rpcap source, it would be most appropriate to file issues there if the client code (libpcap or Npcap communicating with a correctly-functioning rpcapd.exe) has problems.

I will take a look at running WinPcap's rpcapd.exe under Npcap and see if I can identify why that's not working. That may very well be a Npcap bug, though we do not encourage the use of WinPcap API-compatibility mode if it can be avoided.

A future Npcap release may ship with a rpcapd service, but for now, it's not in our immediate plans. For this reason, I'm using the 'enhancement' label instead of the 'bug' label.

dmiller-nmap commented Sep 18, 2018

We haven't done much testing with rpcapd, so I'm not surprised that there are some bugs there. Since the-tcpdump-group/libpcap has taken ownership of the rpcap source, it would be most appropriate to file issues there if the client code (libpcap or Npcap communicating with a correctly-functioning rpcapd.exe) has problems.

I will take a look at running WinPcap's rpcapd.exe under Npcap and see if I can identify why that's not working. That may very well be a Npcap bug, though we do not encourage the use of WinPcap API-compatibility mode if it can be avoided.

A future Npcap release may ship with a rpcapd service, but for now, it's not in our immediate plans. For this reason, I'm using the 'enhancement' label instead of the 'bug' label.

@ether42

This comment has been minimized.

Show comment
Hide comment
@ether42

ether42 Sep 18, 2018

Thanks for taking a look, I understand the priority so no worries.

To avoid any ambiguities I should probably have said that the following work fine:

  • tcpdump/libpcap master on Linux communicating to rpcapd/libpcap master on Linux
  • tcpdump/libpcap master on Linux communicating to rpcapd/WinPCAP on Windows 2012 (r2)
  • Wireshark (probably the latest version from the site but don't have it right now so can't quote it, sorry) on Windows communicating to rpcapd/WinPCAP on Windows 2012

The misbehaving part seem to be rpcapd.exe (or its dependencies) on Windows 2016.

I don't do anything special beside executing rpcapd -n on one machine and tcpdump (tested both TCP and UDP for data transport)/Wireshark on another.

I would gladly avoid using/recommending WinPCAP if Npcap was embedding a working rpcapd.exe since you have signed drivers and actually maintain the project, it's a no-brainer :)

EDIT: I would gladly test some stuff if you have some kind of list, it's just that I'm not accustomed/don't even have the minimum setup to do Windows development so it would probably take me a bit of time just to start digging where the problem could be :)

ether42 commented Sep 18, 2018

Thanks for taking a look, I understand the priority so no worries.

To avoid any ambiguities I should probably have said that the following work fine:

  • tcpdump/libpcap master on Linux communicating to rpcapd/libpcap master on Linux
  • tcpdump/libpcap master on Linux communicating to rpcapd/WinPCAP on Windows 2012 (r2)
  • Wireshark (probably the latest version from the site but don't have it right now so can't quote it, sorry) on Windows communicating to rpcapd/WinPCAP on Windows 2012

The misbehaving part seem to be rpcapd.exe (or its dependencies) on Windows 2016.

I don't do anything special beside executing rpcapd -n on one machine and tcpdump (tested both TCP and UDP for data transport)/Wireshark on another.

I would gladly avoid using/recommending WinPCAP if Npcap was embedding a working rpcapd.exe since you have signed drivers and actually maintain the project, it's a no-brainer :)

EDIT: I would gladly test some stuff if you have some kind of list, it's just that I'm not accustomed/don't even have the minimum setup to do Windows development so it would probably take me a bit of time just to start digging where the problem could be :)

@guyharris

This comment has been minimized.

Show comment
Hide comment
@guyharris

guyharris Sep 28, 2018

I assume by "Windows 2016" you mean "Windows Server 2016"; at least if the "Windows Server 2016" Wikipedia page is to be believed, that's "Windows 10 Server", so this may be a Windows NT 10 issue.

The rpcapd source code in libpcap is changed from what's in the last WinPcap release (4.1.3); it has a bunch of changes to make it build "out of the box" on various UN*Xes, fix a protocol compatibility issue when running on Solaris (so the client and server, on Solaris, should be able to communicate with the server and client, respectively, on other OSes), and fix various other issues.

I don't know how Npcap builds the libpcap component, but if it uses CMake and builds with -DENABLE_REMOTE=YES, it should not only build Npcap with remote-capture support, but should also build rpcapd. That would produce an rpcapd built with the current rpcapd source.

I currently don't have a Windows 10 VM (and have a bunch of other stuff I'm juggling as well), so there's not much I can do right now to diagnose this problem.

guyharris commented Sep 28, 2018

I assume by "Windows 2016" you mean "Windows Server 2016"; at least if the "Windows Server 2016" Wikipedia page is to be believed, that's "Windows 10 Server", so this may be a Windows NT 10 issue.

The rpcapd source code in libpcap is changed from what's in the last WinPcap release (4.1.3); it has a bunch of changes to make it build "out of the box" on various UN*Xes, fix a protocol compatibility issue when running on Solaris (so the client and server, on Solaris, should be able to communicate with the server and client, respectively, on other OSes), and fix various other issues.

I don't know how Npcap builds the libpcap component, but if it uses CMake and builds with -DENABLE_REMOTE=YES, it should not only build Npcap with remote-capture support, but should also build rpcapd. That would produce an rpcapd built with the current rpcapd source.

I currently don't have a Windows 10 VM (and have a bunch of other stuff I'm juggling as well), so there's not much I can do right now to diagnose this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment