Npcap скачать для windows 7 x64

Hello

I am using Wireshark with npcap on Windows 7 to develop an EtherNet/IP client application. Setup is as follows: My development PC -> VPN into the office -> EtherNet/IP Device connected to network. I have been using Npcap 0.99-r8 and Npcap 0.99-r7 — the issue is the same.

Test scenario:

• Start test application, send any EtherNet/IP request packet (e.g. List Identity, using UDP unicast)
  => Response is successfully received
• Start WireShark witn NPcap driver, select appropriate NdisWan Adapter.
• Send any EtherNet/IP request packet (e.g. List Identity, using UDP unicast)
  => Request packet can be seen in Wireshark, but no response.
  => Subsequent request packets can be seen in Wireshark, but no response.
• Stop logging or Exit WireShark
• Send any EtherNet/IP request packet (e.g. List Identity, using UDP unicast)
  => Response is successfully received

I use my own EtherNet/IP client software or the free Molex EtherNet/IP tool, which is great for showing this issue. Download: https://www.molex.com/mx_upload/superfamily/iccc/EtherNet_IPTool.html
Usage: Start tool, stay on first tab (List Identity), Message Type ‘Unicast’, enter IP address of target device, press ‘Send List Identity Request on UDP’. If successful, ‘Station’ (device) will show up in the frame to the right, otherwise not.

Thanks.

Last several versions of Windows 10 Insider 20H1 have been causing GSOD with kernel access violations.

When I try to start wireshark and it gets the interfaces will GSOD.

minidump.txt
DiagReport-20191011-111305.txt

I installed npcap with Nmap; however, it doesn’t seem to be working for either Wireshark or Nmap. In Nmap I get a failed to open lo0 and in Wireshark there are no interfaces. In Nmap I simply tried to scan my ip with the default settings. In Wireshark I only opened the program. I would expect the scan to return some kind of results and for Wireshark to find my adapters. My e-mail is [email protected]. I look forward to any help you may be able to provide.

DiagReport-20191013-220531.txt

I’m seeing a similar problem seen in the closed issue nmap/nmap#1055.

Basically I’m seeing duplicated outbound packets in Wireshark with Npcap. I do not see the issue when using WinPcap. The person who posted issue nmap/nmap#1055 said that toggling the Npcap driver on the network adapter would temporarily fix the issue, however, this does not seem to work for me. When viewing in Wireshark, the timestamps of the duplicated packets are a few nanoseconds apart. The receiving end does not see the duplicate packets, so it’s not actually transmitting them. I’ve seen the issue on multiple machines and Npcap versions, but my current setup is:

Npcap 0.992
Windows 10 1809
Wireshark 3.0.1

Npcap does not currently do anything with NDIS status notifications, which NDIS documentation states are a more efficient means of obtaining information than issuing OID requests. Furthermore, OID requests may be returned without an answer, with the answer coming later in a status notification.

Mishandling of status notifications is implicated in connectivity problems on Win7: See nmap/nmap#1998 (comment)

The main Windows tcpdump port is currently windump.exe by the WinPcap folks. But like winpcap, it hasn’t been updated in years and isn’t really maintained. It also doesn’t work with our Npcap because it relies on a too-old libpcap. But the changes to make current tcpdump work on Windows with Npcap are minor (we’ve done it in initial testing) and a lot of us still love tcpdump (even though it doesn’t hold a candle to the amazing Wireshark feature-wise).

So the thought is that we should probably make a tcpdump.exe that uses Npcap (submitting any needed changes upstream for hopeful incorporation) and then we could include that as an optional (install by default) checkbox component. It would be useful both to everyone who appreciates tcpdump for Windows, and also handy as a quick check that an Npcap install is working. The tcpdump builds we have been making are less than 1mb, so fairly immaterial space wise. And of course people can choose not to include it in the install by unchecking or using command line installer option if desired.

Currently (Npcap 0.9984), Npcap can only control access to capture and inject at the device level, where the device is the special name and handle that the Npcap driver creates on the system, through which Packet.dll requests handles based on network interface name/GUID. In order to increase security, Npcap offers «Admin-only mode,» which uses SDDL for Device Objects to restrict access to users with Builtin Admin privilege. This requires UAC elevation and applies to all Npcap functions on all interfaces. It is not possible to grant access to individual users or groups.

Instead of relying on device-level access control, Npcap could check the calling user’s security identifier against a fully-featured ACL within the IRP_MJ_CREATE handler. This could enable us to do very specific access control like «Members of the Npcap Read domain group can do packet capture on these interfaces, but not packet injection.»

Challenges:

1. Where and how should the ACL be stored? Probably the Registry, but need specifics and format.
2. How should system admins update or modify the ACLs? Probably a helper program, but it would be best to use existing Windows APIs and dialogs for identifying principals and editing ACEs.
3. Synchronization between Registry and running driver, avoiding race conditions.

Version Information

OS: Windows 10 Pro, version 1803, build 17134.556
NPCAP: 0.99-r7, tested and confirmed on 0.99-r8 as well

Current Behavior

When capturing traffic with Wireshark (with NPCAP 0.99-r7 installed as a dependency) while utilizing a capture filter that filters based upon packet data, egress traffic sourced from the local machine that should pass through the filter without issue does not pass through the filter. When capturing traffic without a capture filter that filters based upon packet data, egress traffic sourced from the local machine appears without issue.

An example of a capture filter that filters based upon packet data is as follows:

In the compressed file attached to the bottom of this issue are two PCAPs captured on my computer (IP of 192.168.10.50):

• npcap_broken_udp_capture_filter_with_data_filter.pcapng — Hereafter called «broken_udp», this capture utilized the above capture filter udp[8:2] & 0xf = 1
• npcap_working_udp_capture_filter.pcapng — Hereafter called «working_udp», this capture utilized udp as a capture filter

Both PCAP files result from captures taken at close to the exact same time. For reference, the first packet in «broken_udp» is the 217th packet in «working_udp» (almost exactly the same arrival time and epoch timestamp, and the rest of the packet is identical.) As you can see, all of the traffic in «broken_udp» is destined to my computer at 192.168.10.50, while «working_udp» has a considerable amount of traffic sourced from 192.168.10.50 that does not show up in «broken_udp».

One example of a packet in «working_udp» that should have been captured in «broken_udp» is packet 219 in «working_udp» (source 192.168.10.50, destination 69.47.158.237). The Message Type field in the STUN header has a value of 0x0001, which should be matched by the udp[8:2] & 0xf = 1 capture filter. However, this packet does not appear in the «broken_udp» PCAP.

These PCAPs demonstrate the current behavior with UDP, but I was able to reproduce the same behavior with a TCP capture filter as well. If you use the capture filter tcp[32:2] & 0xf = 1, only traffic that ingresses the machine will be displayed. Utilizing bit masks is not necessary to reproduce the behavior, either — I attempted to use a capture filter of udp[8:2]==0x0001 and encountered the current behavior as well.

Expected Behavior

Expected behavior is for a capture filter that filters based upon data within the packet itself to capture traffic in both ingress and egress directions.

Additional Troubleshooting

I believe this is an issue with NPCAP 0.99-r7/r8 because this issue did not exist when WinPCAP v4.1.3 was installed on my computer. @vaindil originally encountered this issue when he was running NPCAP 0.99-r7, and we were puzzled over how the same capture filter yielded different results on our different computers. The biggest relevant difference between our machines was that he was using NPCAP, while I was using WinPCAP. When I uninstalled WinPCAP and NPCAP 0.99-r7, I was able to reproduce this issue.

A DiagReport is also included in the compressed file uploaded to the bottom of this issue.

Please let me know if you need any additional information about this issue!

npcap_issue.zip

We are considering adding Windows 10 ARM64 support to Npcap. With that, we would support all 3 Windows 10 architectures. Windows 10 ARM64 is a new (released in late 2017) system that is used on some more portable laptop/tablet devices like the Samsung Galaxy Book 2. @pmsjt from Microsoft has already done and tested an initial port and submitted it as a pull request here: #18 .
Having ARM64 Npcap should enable Nmap to work on these ARM64 devices too, which would be nice.

We’re wondering how much Nmap/Npcap user interest there is in supporting Windows 10 ARM64? If it is something you want for a specific reason, please comment and describe your use case, including any particular devices you’d want to make sure are supported. Based on the responses, we’ll decide whether to buy some ARM64 hardware and get to work. Thanks!

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.

Just updated to version 3.2 and installed npcap in the process. Had a version running ok with WinPCap. Windows 7 x64. After successful install no adapters listed. Have reinstalled several times as well as cleaned old drivers/files, installed in safe mode, etc. I ran the fixinstall.bat inside the npcap directory and got an error:

The service name is invalid [SC] Open Service FAILED 1060: The specified service does not exist as an installed service see: net helpmsg 2185

Can’t seem to revert to old version. Have tried uninstalling and manually removing drivers.

Somebody complained about packet time stamps drifting from system time with WinPcap on Windows 10.

WinPcap has, at least on 32-bit Windows, a registry parameter HKLMSystemCurrentControlSetServicesNPFTimestampMode that controls how time stamps are generated:

• 0 (default) -> Timestamps generated through KeQueryPerformanceCounter, less reliable on SMP/HyperThreading machines, precision = some microseconds
• 2 -> Timestamps generated through KeQuerySystemTime, more reliable on SMP/HyperThreading machines, precision = scheduling quantum (10/15 ms)
• 3 -> Timestamps generated through the i386 instruction RDTSC, less reliable on SMP/HyperThreading/SpeedStep machines, precision = some microseconds

There also appears to be a setting of 1, the symbol for which in time_calls.h is TIMESTAMPMODE_SYNCHRONIZATION_ON_CPU_WITH_FIXUP, and a setting of 99, the symbol for which is TIMESTAMPMODE_SYNCHRONIZATION_ON_CPU_NO_FIXUP.

It looks as if, on 64-bit Windows, the RDTSC version isn’t supported.

From a quick look at the Npcap driver, it seems to behave similarly, although the NT GET_TIME() code went from

#ifdef _X86_
	if ( TimestampMode == TIMESTAMPMODE_RDTSC )
    	{
		GetTimeRDTSC(dst,data);
	}
	else
#endif // _X86_
	if ( TimestampMode == TIMESTAMPMODE_QUERYSYSTEMTIME )
	{
		GetTimeQST(dst,data);
	}
	else
	{
		GetTimeKQPC(dst,data);
	}

in WinPcap to

#ifdef _X86_
	if (g_TimestampMode == TIMESTAMPMODE_RDTSC)
	{
		GetTimeRDTSC(dst, data);
	}
	else
		#endif // _X86_
	if (g_TimestampMode == TIMESTAMPMODE_QUERYSYSTEMTIME)
	{
		GetTimeQST(dst, data);
	}
	else
	{
		GetTimeKQPC(dst, data);
	}

on Npcap — the mis-indentation of the #endif makes it less clear that modes 0 and 2 are still supported.

If a mode were supported in which KeQuerySystemTimePrecise() were used, at least on Windows 8 (and its server variant) and later, that would provide a mode that 1) gives high-resolution time stamps and 2) doesn’t drift from the system clock, although it might be more costly than using KeQueryPerformanceCounter(). (And if it’s not more costly, it’s probably the best mode on 64-bit Windows, given that RDTSC isn’t being used.)

Furthermore, given that there’s now a pcap_set_tstamp_type() in libpcap, having the time stamp type be per-pcap_t, rather than system-wide, might be useful. You’d offer a choice between:

• PCAP_TSTAMP_HOST — this would use KeQuerySystemTime() prior to Windows 8 and KeQuerySystemTimePrecise() on Windows 8 and later, and would always be available (it’s the default in libpcap);
• PCAP_TSTAMP_HOST_LOWPREC — this would always use KeQuerySystemTime(), and would be always be available;
• PCAP_TSTAMP_HOST_HIPREC — this would always use KeQuerySystemTimePrecise(), and would only be available on Windows 8 and later.

If the other time stamp types are useful, we could add new PCAP_TSTAMP_ types for them, and make them available only on Windows (the PCAP_TSTAMP_ADAPTER types are available only on Linux — and they have a number of problems, not the least of which is that they give time as seconds since January 1, 1970, 00:00:00 TAI with at least some adapters; don’t get me started on UN*X time stamps and leap seconds…).

I was trying to debug a problem where libpcap’s findalldevstest program wasn’t returning any interfaces; the problem is that I needed to copy the helper executable into the run/Debug subdirectory of my libpcap build directory.

If:

• NpcapStartHelper() were to return FALSE if the helper needed to be started but couldn’t be started, and TRUE otherwise;
• PacketOpenAdapterNPF() were to return NULL if NpcapStartHelper()` returned FALSE;
• PacketAddAdapterIPH() and PacketAddAdapterNPF() were to return FALSE for PacketOpenAdapterNPF() returning NULL and the error being any of the ShellExecuteExA() errors that mean «the helper couldn’t be started» rather than meaning «there is no such adapter»;
• PacketGetAdaptersIPH(), PacketGetAdaptersNPF(), and PacketUpdateAdInfo() were to return FALSE if the corresponding PacketAddAdapterXXX() routine failed with one of those errors;
• PacketPopulateAdaptersInfoList() were to do the same, and return a success/failure Boolean;

that would, I think, allow this.

This would also allow pcap_activate_npf() to return PCAP_ERROR_PERM_DENIED if a program tries to open an adapter, Npcap is in admin-only mode, and the user says «No» to the UAC prompt — and would also allow any future device-enumerating APIs to do so as well.

Npcap versions 0.95 through 0.995 had an uninstaller problem where they didn’t always correctly remove the «Npcap Loopback Adapter» that the installer creates. So systems could collect extra versions, since each upgrade during that time would add a new one without deleting any. I found I had 23 and it was bogging down Nmap scan times and Wireshark adapter listing times, mostly because adapter listing is not currently very efficient (see issue nmap/nmap#1551 ). Npcap versions 0.996 and later properly remove the loopback adapter when they uninstall, but they don’t (yet) remove any old duplicate adapters left by 0.95 and 0.995 uninstalls/upgrades. It would be nice to add a feature to the uninstaller to remove ALL old Npcap Loopback Adapters when detected rather than just the latest one. But it’s not quite as easy as expected because the trick is finding the appropriate one by index or GUID. There are several different registries of adapters, and the one with the «Npcap Loopback Adapter» description isn’t the one that NPFInstall currently uses to remove the adapter. So it’s something like: go through all the adapters by description, finding the GUIDs of the ones we want to remove. Then go through all the adapters by index, finding the ones that match one of the guids we want to remove, and remove it.

IN THE MEANTIME, users can manually remove any old loopback adapters by opening device manager (press Windows key and type «device manager»), then expand the «Network adapters» item, then, if there is more than one «Npcap Loopback Adapter», right click on them each and choose «uninstall device». Then reinstall Npcap so you get a proper one recreated. If you only have one «Npcap Loopback Adapter» and you aren’t having any problems with it, then no need to delete anything as you don’t have extras.

Update: Our suspicion is that this libpcap change may be the cause of the problem. Since libpcap changed the function into a compiler macro, code which uses it will need to be recompiled with latest headers (such as Npcap SDK) in order to continue using it. We may want to talk to Suricata folks about using newer headers for next version. This could also be a good chance for them to update to native Npcap API, if desired.

I haven’t fully investigated this yet, but am hearing reports of people having trouble running the free and open source Suricata IDS with recent versions of Npcap, even when older versions worked. There is an example report here or the error «can not find pcap_dump_open». I am checking whether there are other error messages. The person who reported it to me said that he had enable WinPcap compatability mode (which is apparently requried for Suricata to use Npcap). I installed Suricata 4.1.5 and did not see the WinPcap DLLs in the Suricata directly, but it’s possible they were installed somewhere else. I haven’t tried running it quite yet. We should test with Suricata and/or communicate with the project to ensure solid Npcap support. Ideally, Suricata would support Npcap native mode (it could still support Winpcap too).

During a recent install of Wireshark on Win10 I selected the «Restrict Npcap driver’s access to Administrators only» option. However, opening Wireshark caused a bunch of repeated UAC prompts to be triggered. I can’t remember the exact next sequence of events, but I eventually tried to reinstall npcap with that box unchecked. I remember the uninstall reporting success, but all attempts to reinstall with the standalone 0.9983 now fail:

I went on an npcap purge and manually deleted every reference to it that I could find: the Program Files folder that still existed, the loopback driver in device manager, all the .dll files for it, several registry keys referencing the drivers, and probably a few other things that I can’t remember. Install still fails at this screen.

I reinstalled Wireshark several times, and each time it detects that the 0.9982 is still installed. I went so far as to look at the source code that Wireshark uses to detect whether it’s already installed and found that it opens up a specific registry key. However, when I try to look that key up in RegEdit it doesn’t even exist. So I have no idea why Wireshark thinks it’s still installed or why the standalone installer just aborts when trying to stop the npcap driver.

Any help would be appreciated.

Hello there. I tried to install Npcap per warning message I received during Azure ATP sensor installation steps. I removed the WinPcap via Windows control panel, and proceeded to install the Npcap with the following options: loopback_support=no & winpcap_mode=yes.
Unfortunately, the Npcap install process failed and I gathered the logs and screen shot for further review. Any guidance or support/assistance is greatly appreciated. Let me know please. Thank you.

[NPFInstall.log](https://github.com/nmap/nmap/files/3911535/NPFInstall.log)
[install.log](https://github.com/nmap/nmap/files/3911536/install.log)

Hi,

I got error when trying nmap

dnet: Failed to open device eth6 QUITTING!

I tried to reinstall my Npcap but still didnt work

~#nmap -v
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-20 17:12 SE Asia Standard Time
Read data files from: C:Program Files (x86)Nmap
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.22 seconds
           Raw packets sent: 0 (0B) | Rcvd: 0 (0B)

~#Npcap version : 0.9983
~#Windows 10 Pro 64 bit
`nmap --iflist
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-20 17:11 SE Asia Standard Time
************************INTERFACES************************
DEV  (SHORT) IP/MASK                      TYPE     UP   MTU  MAC
eth0 (eth0)  fe80::bd3a:9069:1aa7:7d41/64 ethernet up   1500 02:00:4C:4F:xx:xx
eth0 (eth0)  169.254.125.65/16            ethernet up   1500 02:00:4C:4F:xx:xx
eth1 (eth1)  fe80::9e1:3379:6e48:eadf/64  ethernet up   1500 0A:00:27:00:xx:xx
eth1 (eth1)  192.168.56.1/24              ethernet up   1500 0A:00:27:00:xx:xx
eth2 (eth2)  fe80::2996:ca5c:784c:526c/64 ethernet down 1500 AC:B5:7D:06:xx:xx
eth2 (eth2)  169.254.82.108/16            ethernet down 1500 AC:B5:7D:06:xx:xx
eth3 (eth3)  fe80::116a:4787:4dec:44fc/64 ethernet down 1500 1E:B5:7D:06:xx:xx
eth3 (eth3)  169.254.68.252/16            ethernet down 1500 1E:B5:7D:06:xx:xx
eth4 (eth4)  fe80::a046:9f43:cdb1:ba6d/64 ethernet down 1500 2E:B5:7D:06:xx:xx
eth4 (eth4)  169.254.186.109/16           ethernet down 1500 2E:B5:7D:06:xx:xx
eth5 (eth5)  fe80::f1ef:e8ff:2d49:a0e5/64 ethernet down 1500 5E:B5:7D:06:xx:xx
eth5 (eth5)  169.254.160.229/16           ethernet down 1500 5E:B5:7D:06:xx:xx
eth6 (eth6)  fe80::1c3f:c7c1:7b7d:1b97/64 ethernet up   1500 F0:76:1C:37:xx:xx
eth6 (eth6)  192.168.41.117/24            ethernet up   1500 F0:76:1C:37:xx:xx
eth7 (eth7)  fe80::1da8:60a7:b42e:211/64  ethernet down 1500 00:FF:66:C0:xx:xx
eth7 (eth7)  169.254.2.17/16              ethernet down 1500 00:FF:66:C0:xx:xx
lo0  (lo0)   ::1/128                      loopback up   -1
lo0  (lo0)   127.0.0.1/8                  loopback up   -1

DEV    WINDEVICE
eth0   <none>
eth0   <none>
eth1   <none>
eth1   <none>
eth2   <none>
eth2   <none>
eth3   <none>
eth3   <none>
eth4   <none>
eth4   <none>
eth5   <none>
eth5   <none>
eth6   <none>
eth6   <none>
eth7   <none>
eth7   <none>
lo0    <none>
lo0    <none>
<none> DeviceNPF_Loopback

**************************ROUTES**************************
DST/MASK                      DEV  METRIC GATEWAY
255.255.255.255/32            eth4 281
255.255.255.255/32            eth0 281
255.255.255.255/32            eth3 281
255.255.255.255/32            eth5 281
255.255.255.255/32            eth2 281
169.254.125.65/32             eth0 281
169.254.255.255/32            eth0 281
255.255.255.255/32            eth1 281
192.168.56.255/32             eth1 281
192.168.56.1/32               eth1 281
192.168.41.117/32             eth6 291
192.168.41.255/32             eth6 291
255.255.255.255/32            eth6 291
255.255.255.255/32            eth7 311
255.255.255.255/32            lo0  331
127.255.255.255/32            lo0  331
127.0.0.1/32                  lo0  331
192.168.56.0/24               eth1 281
192.168.41.0/24               eth6 291
169.254.0.0/16                eth0 281
127.0.0.0/8                   lo0  331
224.0.0.0/4                   eth3 281
224.0.0.0/4                   eth4 281
224.0.0.0/4                   eth5 281
224.0.0.0/4                   eth2 281
224.0.0.0/4                   eth1 281
224.0.0.0/4                   eth0 281
224.0.0.0/4                   eth6 291
224.0.0.0/4                   eth7 311
224.0.0.0/4                   lo0  331
0.0.0.0/0                     eth6 35     192.168.41.1
fe80::2996:ca5c:784c:526c/128 eth2 281
fe80::f1ef:e8ff:2d49:a0e5/128 eth5 281
fe80::bd3a:9069:1aa7:7d41/128 eth0 281
fe80::a046:9f43:cdb1:ba6d/128 eth4 281
fe80::9e1:3379:6e48:eadf/128  eth1 281
fe80::116a:4787:4dec:44fc/128 eth3 281
fe80::1c3f:c7c1:7b7d:1b97/128 eth6 291
fe80::1da8:60a7:b42e:211/128  eth7 311
::1/128                       lo0  331
fe80::/64                     eth1 281
fe80::/64                     eth0 281
fe80::/64                     eth4 281
fe80::/64                     eth3 281
fe80::/64                     eth5 281
fe80::/64                     eth2 281
fe80::/64                     eth6 291
fe80::/64                     eth7 311
ff00::/8                      eth4 281
ff00::/8                      eth0 281
ff00::/8                      eth1 281
ff00::/8                      eth2 281
ff00::/8                      eth5 281
ff00::/8                      eth3 281
ff00::/8                      eth6 291
ff00::/8                      eth7 311
ff00::/8                      lo0  331`

1. Use the WinPCap 4.1.3
   I can retrieve the network speed with the following code.
2. Use the current Npcap «npcap-0.9984.exe»
   There are 12 adapters in my win7 system.
   But only 1 adapter’s link speed can retrieved.
   Following are all the adapters:
   1 — DeviceNPF_Loopback, speed = 10000000
   2 — DeviceNPF_{ D2F5FDB8 — 026D — 4E3C — 9603 — E0847AF4A334 }, speed = 0
   3 — DeviceNPF_{ 35E23E0A — 1D3B — 4BA8 — B1A3 — BFB5D407AFB1 }, speed = 0
   4 — DeviceNPF_{ A656415F — 88BE — 4CD1 — 8596 — C736CAFF67AC }, speed = 0
   5 — DeviceNPF_{ 23BD7BB6 — 5321 — 441B — 903A — 27418CBC8569 }, speed = 0
   6 — DeviceNPF_{ F37FB154 — 95B3 — 4047 — AA98 — F75C3DEC5285 }, speed = 0
   7 — DeviceNPF_{ A05D7D3F — 257C — 4D2F — 867A — E821A94B548C }, speed = 0
   8 — DeviceNPF_{ 78032B7E — 4968 — 42D3 — 9F37 — 287EA86C0AAA }, speed = 0
   9 — DeviceNPF_NdisWanIp, speed = 0
   10 — DeviceNPF_{ 4D3329D0 — 7D57 — 4385 — AB76 — 5AA0280929A1 }, speed = 0
   11 — DeviceNPF_NdisWanBh, speed = 0
   12 — DeviceNPF_NdisWanIpv6, speed = 0

My Code:
LPADAPTER lpAdapter = PacketOpenAdapter(PCHAR AdapterName);
NetType param;
PacketGetNetType(lpAdapter, &param);
uint64_t speed = param.LinkSpeed;

Users are complaining about Wireshark taking a long time to populate the list of adapters, even going so far as to suggest turning off Npcap when using Wireshark for reading pcap files. This shouldn’t take so long.

The most promising idea so far is: Don’t try to open each adapter as it is found (PacketOpenAdapter) in order to determine if it is supported. Packet API docs (unpublished) indicate that PacketGetAdapterNames is supposed to only return supported adapters, but I don’t know if anything relies on that. Need to check libpcap to see, since that’s the primary consumer of that API.

It appears that, for some devices, the signal strength is reported as 0 dBm; this probably means that the device doesn’t report the signal strength, not that the signal strength was 1 milliwatt.

See, for example, this ask.wireshark.org question.

Yeah,

Your team has hard-coded the npcap include paths. Please change them to use a relative path.

Npcap Guide does not have good documentation of the interaction between the sizes of the kernel buffer, the user buffer, and the number of CPU cores. This information is vital to proper tuning of performance. A brief description follows, which could be used to begin the appropriate documentation:

The Npcap driver stores captured packets in a circular buffer until they are retrieved (pcap_next_ex(), pcap_dispatch(), pcap_loop(), PacketRecievePacket()) by the user program. Each adapter handle (pcap_t or ADAPTER) has its own buffer, the size of which is set via pcap_set_buffer_size(), pcap_setbuff() (deprecated WinPcap extension), or PacketSetBuff(), and which defaults to 1MB. The buffer is split into a number of independent segments according to the number of processors on the system. When a packet is received by the driver, it is put into the buffer segment corresponding to the driver thread’s current processor. If there is not enough room in that segment, the packet is dropped.

A user program receives packets into a «user buffer» which is passed to PacketRecievePacket(). The driver empties packets from its own buffer segments in the order they were received until it runs out of space in the user buffer or runs out of packets to return. A large user buffer can ensure the kernel buffer is emptied more quickly, preventing packet drops. The libpcap API (wpcap.dll) configures the size of this user buffer via pcap_setuserbuffer(), which defaults to 256KB.

The current behavior of splitting the buffer into number_of_processors segments is flawed, as described in nmap/nmap#1967, but it needs to be documented anyway, since it’s how WinPcap did things, minus the mapping of processor numbers greater than 63 to 63. We can rewrite the documentation if and when we change the behavior.

We have received reports from 2 users of 802.1q authenticated networks that their Wifi connection was disrupted during Npcap install until they re-authenticated to rejoin the network or just rebooted their system. We don’t yet know if all 802.1q authenticated networks are similarly disrupted or if it was something specific to these particular networks/systems.

This issue is partially created as a call out for people to report if they are experiencing this issue or not. That will help us decide how to prioritize the issue and figure out what the cases might have in common besides 802.1q. Please let us know what version of Windows you are running too.

Obviously the best fix would be to prevent the network disruption in the first place, but that may be difficult if it is a bug/characteristic of how Windows handles the loading of WFP drivers. In the meantime, we are looking at creating a «/start_driver_now =no» install option that prevents the Npcap driver from loading until the next reboot. That means Npcap functionality won’t be available until then either, but it may be better than risking even temporary network disruption on a running system.

I’m trying to figure out how to profile a test program (it runs pcap_findalldevs() many times, to try to figure out where the CPU time is going), but apparently this may require 1) .pdb files for wpcap.dll and packet.dll and 2) might also require building the libraries with /PROFILE.

Should there be a guide for people doing development work on Npcap itself, indicating how to set up the development environment? It might belong in the «Npcap internals» documentation.

Problem

When using Wireshark, inbound packets are displayed but outbound packets are not displayed.

Environment

• Windows 8.1.1 x64
• Wireshark 3.0.1 (also tested with 2.x)
• Npcap 0.995

Details

An application is using the WinPcap 4.1.3 SDK to send and receive raw ethernet frames.

With WinPcap 4.1.3 actually installed, this works as expected (all packets are sent and received correctly, and using Wireshark on the interface sending the packets shows both the inbound and outbound packets).

With Npcap 0.995 installed (in WinPcap compatible mode), the packets are sent and received correctly but Wireshark (on the sending interface) only shows the inbound packets, not the outbound packets.

The Wireshark configuration is the same between these two cases; the only change is to uninstall one capture library and install the other.

Possibly of note (but probably unrelated) is that with Npcap installed the network interface shows bindings to NPF and NPCAP, but with WinPcap installed these do not appear. Unticking these causes Wireshark to not capture anything at all.

Currently, I’ve been trying to allow it to work with VS 2013, although I can’t guarantee that I’ve succeeded there.

The npcap README.md says, as of the time I’m filing this issue, that:

The DLLs need to be built using Visual Studio 2013. And the driver needs to be built using Visual Studio 2015 with Windows SDK 10 10586 & Windows Driver Kit 10 10586.

Does «the DLLs» include the libpcap DLL (npcap.dll or whatever it’s called)? If not, what VS version is it built with?

(If it requires VS 2015, including the VS 2015 runtime, or a later version, I can use snprintf() directly, and can use it to make an «generate a malloc()ed formatted string that’s large enough» routine and use that in some places, as long as I kick to the curb some older UN*X versions of snprintf() with non-C99 behavior, which I’m willing to do.)

Hi,

I got the below error when trying to install npcap on a win 2012r2 server.
Unknown error! 800f0203
Npcap LWF driver has failed to be installed.
Failed to create the npcap service for Win7, Win8 and Win10

May I check what is this error code about?

Thanks.
Dan.

Hi,

at least in latest Windows 10 version with all patches applied npcap extremely, really extremely slows down connectivity at startup. I would not bother if we were talking about 5 seconds here, but I have to wait like 40-50 seconds on boot to get network connectivity as soon as npcap is installed.
It is not system specific, it is the same on my laptop with wireless as on my desktop with just Ethernet.
Installed :
driver not started at boot time…I don’t want that
and for the rest it makes absolutely no difference if
loopback yes/no,
compatibility mode yes/no,
admin restriction yes/no
it is just always the same, tried on 2 computers as said.
Waiting a minute is too much.

Any ideas here on what that could be or how to investigate? As said I don’t think it makes sense to investigate too deeply for a specific system computer problem

Thanks

When I try to install Npcap every time i get this error:

In the details there was written
Unknown error! 8007007e

If i need to upload any files then just ask

Somebody reported a «failed to set hardware filter to promiscuous mode)» error; that comes from a PacketSetHwFilter() call, which ultimately does a DeviceIoControl() for NDIS adapters.

libpcap currently doesn’t call GetLastError() and report the error code as part of the error if if PacketSetHwFilter() fails. That might provide more useful debugging information.

Reported here: https://seclists.org/nmap-dev/2019/q1/89

On a Windows 10 laptop with VMware Workstation Pro 14.1.6, Npcap is running on the host OS but not on the Windows 10 VM. User suspends the VM, then hibernates the laptop. On wakeup, the VM has no network access until Npcap is uninstalled. Host OS is not affected.

Reported as affecting 0.99-r8 through 0.992.

I’ve googled this but can’t find anything and what I can find is total greek to me, so I’m posting it here.

I installed this, and rebooted my machine, but it doesn’t seem to be working? It’s listed in my adapters as being enabled, but isn’t in my active networks. It says there’s no network access and when I attempted to troubleshoot, it said there was no valid IP configuration.

I have no idea what any of this means, if it’s normal or how to fix it. Help?

npcap installation causes RSC (Receive Side Coalescing) to be disabled with failure reason «NDISCompatibility». In this case, this is OS software RSC that was introduced in Win10 RS2. I believe that it is enabled by default for devices that do not supports RSC (in HW). Below is the output of «Get-NetAdapterRsc» before and after npcap installation:

PS C:> Get-NetAdapterRsc *
Name IPv4Enabled IPv6Enabled IPv4Operational IPv6Operational IPv4FailureReason IPv6FailureR
State State eason

Wi-Fi True True True True NoFailure NoFailure

PS C:> Get-NetAdapterRsc *
Name IPv4Enabled IPv6Enabled IPv4Operational IPv6Operational IPv4FailureReason IPv6FailureR
State State eason

Wi-Fi True True False False NDISCompatibility NDISCompa…

Operating systems have various timestamp methods available with differing tradeoffs between granularity, accuracy, precision, efficiency, etc.

Npcap has an undocumented legacy method (inherited from Winpcap) for choosing this on a system-wide basis using TimestampMode registry key. It can be set to «0», «2», or «3»:

• 0 is the default and uses KeQueryPerformanceCounter. This provides great precision (some microseconds) but is less reliable on SMP/HyperThreading machines since it doesn’t return monotonic values across multiple CPUs.
• 2 uses KeQuerySystemTime instead, which is more reliable on SMP/HyperThreading machines, with a precision of a scheduling quantum (10/15 milliseconds)
• 3 uses the i386 RDTSC instruction. This is also less reliable on SMP/HyperThreading/SpeedStep machines and has a precision of some microseconds.

The registry location for this key depends on whether you are using Npcap native mode or Winpcap compatible:

• HKLMSystemCurrentControlSetServicesnpcapParametersTimestampMode if using Npcap native API mode (npcap driver)
• HKLMSystemCurrentControlSetServicesnpfParametersTimestampMode if using Winpcap compatible mode (npf driver)

It is probably best to just set both. Also note that even the Winpcap compatible location is a bit different than what Winpcap uses (which is HKLMSystemCurrentControlSetServicesNPFTimestampMode).

We have verified that this feature works with Npcap 0.9983, but we haven’t officially documented it because setting the timestamp mode system-wide is not a great approach. It could cause issues if multiple applications are using Npcap and each wants a different mode.

The better method that we might actually want to officially support uses the per-capture handle timestamp option as described here. That describes the options available on several platforms, but we don’t offer any non-default options through this API on Windows (Npcap). But we might, if we see demand for it. We created this issue both to document the current situation and also so folks can comment if the normal default mechanism doesn’t work well for them. Please also note what you would prefer and why. The more well-supported requests we get, the more we can prioritize this issue. We don’t waste time implementing a feature that nobody seems to want. And, at least for our Nmap Security Scanner, the default timestamp methods seem to be working well enough for us.

Wireshark is not able to see ethernet adapters after changing from WinPCAP to NPCAP on Windows server 2016 for Broadcom Netextreme Virtual Function ethernet adapter.

Attached is the Diagreport. I can reproduce on a fresh empty VM and provide remote access if desired.

C:Program FilesWireshark>dumpcap.exe -D

1. DeviceNPF_Loopback (Adapter for loopback traffic capture)

C:Program FilesWireshark>

Network Adapter(s) Info:

Name InterfaceDescription ifIndex Status MacAddress LinkSpeed

Ethernet Broadcom NetXtreme-E Virtual Function 3 Up 00-00-17-02-79-0E 25 Gbps

Caption : [00000002] Broadcom NetXtreme-E Virtual Function
GUID : {CC75C87B-6F35-4560-8556-EA0329DA6CB7}
Index : 2
InterfaceIndex : 3
Manufacturer : Broadcom Corporation
NetConnectionID : Ethernet
PNPDeviceID : PCIVEN_14E4&DEV_16DC&SUBSYS_16D7108E&REV_003&13C0B0C5&1&18
diagreport.txt

Greetings,

We have reports from multiple users that Npcap version 0.9990 intermittently disrupts connectivity on the loopback interface (causing connections made on 127.0.0.1 to time out). The issue seems isolated to Windows Server 2016, with isolated reports for WS2019. When it happens, the System process is seen to consume a whole CPU. The problem is resolved when Npcap is downgraded to 0.993 (the version we bundled previously). Has this been a known issue, possibly addressed in 0.9991? The similar issues I’m finding are either Windows 10 or Windows 7.

P.S. This happens despite our software not capturing anything from NPF_Loopback (not even opening a pcap handle on that adapter).

We have many Windows 7 installs and all of them have problems connecting with PPPoE when npcap is installed. I have tried 0.99-r7 and 0.992 version but the symptom is the same. If I uninstall the npcap and install winpcap 4.1.3 the problem disappears.

After installing npcap and trying to make a PPPoE connection an error window pops up with RAS error code 692: ERROR_PORT_OR_DEVICE, A hardware failure has occurred in the port or attached device. The second try shows a different RAS error code 813: ERROR_BROADBAND_ACTIVE, You have attempted to establish a second broadband connection while a previous broadband connection is already established using the same device or port. All other tries give the same error code 813.

Disabling npcap on the ethernet interface under the PPPoE connection doesn’t help. Stopping the npcap service does not help either. Another phenomena is something prevents Windows to be restarted, it stucks on the rebooting screen forever after the RAS error. Even the npcap uninstall stucks at 90% and never finishes after trying to use PPPoE. The uninstall log shows no problem, the last line is «Delete file: C:Program FilesNpcapFixInstall.bat». After restarting the computer the install.log contains more lines after this point. The last line shows «Jump: 76» and the service has removed.

The PPPoE connection should be established by the help of RAS. The computer is connected to a HGW with a 1 Gbps ethernet interface. The broadband connection is created in the Network Sharing Center:

• Set up a new connection
• Connect to the Internet
• Set up a new connection: WAN Miniport (PPPoE)
• Broadband (PPPoE)
• Enter username and password

I tried installing npcap with many different options, but none of them help:

• With or without WinPcap compatibility mode
• With or without Support loopback traffic