failed to set hardware filter to promiscuous mode with Windows 11

[Hobo2k]

Describe the bug After Upgrade from Windows 10 to Windows 11 I can't capture any more in promiscuous mode. I tried it with my LAN Interface not WLAN. I upgraded npcap from 1.70 to 1.71 and tried Wireshark 3.6.7, 3.6.8 and 4.0.0rc1

Message is: The capture session could not be initiated on capture device "\Device\NPF_{8B94FF32-335D-443C-8A80-F51BDC825F9F}" (failed to set hardware filter to promiscuous mode: Ein an das System angeschlossenes Gerät funktioniert nicht. (31)).

To Reproduce Steps to reproduce the behavior:

1. Doubleclick on the Interface from StartScreen
2. Otherwise go to Capture Options.
3. Than check the promiscous mode
4. last click on start.

Expected behavior A working capture. ;-)

Screenshots

Diagnostic information

• Windows version from winver: Windows 11 Version 21H2, OS Build 22000.856
• Output of DiagReport-20220908-131205.txt
• install.log

[Hobo2k]

The Problem only occurs with LAN adapters. At virtualbox, WLAN, WWAN promiscuous mode can be enabled at capture start.

USB LAN nor docking is working.

[guyharris]

31 is ERROR_GEN_FAILURE. NT status codes that translate to ERROR_GEN_FAILURE include a bunch of "somebody wrote to executable memory" codes, STATUS_WIM_NOT_BOOTABLE, and STATUS_UNSUCCESSFUL, which is, I guess, the NT status equivalent of ERROR_GEN_FAILURE, as in "something bad happened but I'm not going to tell you what it was".

There appear to be a lot of places in the driver that return STATUS_UNSUCCESSFUL.

[Hobo2k]

Okay Error found: Installing the Driver for Windows 10 instead of them for Windows 11 and it works again. I don't know if it's a driver or npcap error.

Drivers are for Realtek USB devices: https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software

[ralish]

Can confirm I see the same issue with a Dell WD19DC dock which contains a Realtek RTL8153 USB GbE controller. Was working fine prior to Windows 11 upgrade from Windows 10 21H2. Current driver is rtu53cx22x64.sys v1153.8.20.608 (Date: 9/06/2022),

Happy to provide whatever further information would be of assistance but unsure what's most helpful.

EDIT: Using Wireshark v3.6.8 with npcap v1.71.

[ralish]

Just a thought: could it be related to a lack of support for the new NetAdapterCx driver model?

I have no idea if Npcap is expected to "Just Work" with NetAdapterCx drivers or if additional work is required.

The latest Windows 11 driver for the RTL8153 has the following details:

• Driver: rtu53cx22x64.sys
• Version: 1153.8.20.608
• Date: 9/06/2022
• Type: NetAdapterCx
• NDIS Version: 6.85

The latest Windows 10 driver for the RTL8153 has the following details:

• Driver: rtump64x64.sys
• Version: 10.52.20.608
• Date: 8/06/2022
• Type: NDIS miniport
• NDIS Version: 6.40

The Windows 10 driver works fine with Wireshark while the Windows 11 driver has the described error on starting capture.

[kotori2]

Exactly same situation here. Using Intel I225-V wired adapter, Windows 11, and Wireshark 4.0.0. Downgrading to NDIS68 (v1.1.3.28) solves this issue for me.

[jd-imi]

On Windows 11, get the same message with Wireshark 4.0.0 and npcap 1.71 (but not with npcap 1.60) on the Ethernet interface (with the Wi-Fi, it was fine).

I reported the issue on Wireshark Q&A : https://ask.wireshark.org/question/29016/cannot-initiate-capture-session-on-a-device-after-having-installed-400/

[httpstorm]

My workaround after installing Wireshark 4.0.0 was to downgrade npcap to 1.60. This means some regression has been introduced in 1.71. Device manager shows Realtek PCIe GbE Family controller, date 2021-01-27, version 1.0.0.4.

[overcam]

Same. Error introduced after upgrade to 1.71; resolved by downgrading back to 1.60. Using Killer E3100 2.5 Gbps interface.

[mggaskill]

I, too, was able to resolve my error (Windows 11 / Wireshark 4.0.1) by downgrading npcap from 1.71 to 1.60. Thanks for the info!

[robsan00]

A colleague of mine (who does not have a GitHub account) has a similar issue, however, for him it happens on Windows 10. He is using a "QLogic BCM57810" network card, I don't know what chipset this card contains. Downgrading to npcap 1.60 fixed his issue as well. The driver is quite old as QLogic themselves have been bought up multiple times and their successor companies more less seem to have stopped support.

[halfranklin]

This happens on Windows 10, Aquantia AQtion AQC107 10Gbit Network Adapter. Downgrade to npcap 1.60 fixed it.

[M4jx]

Previously worked on 1.60 but got the same error as yours on 1.71. Realtek Gaming 2.5GbeE Family Controller.

[rampageX]

Same here, previously worked on 1.60 but not 1.71, Realtek Gaming GbE Family Controller on laptop and Realtek USB GbE Family Controller on PC. Windows 11 x64 22H2 22621.755

[enochi]

downgrade to 1.6 not always work,still got the problem.

[TylerJaacks]

I'm getting the same issue in Xemu (QEMU based Xbox Emulator) with an Intel(R) Ethernet Controller I225-V

[jensmunk]

Exactly the same problem here with a Tripp-Lite, a TP-Link and a Belkin USB adapter. They identify themselves as:

->TP-LINK Gigabit Ethernet USB Adapter ->Realtek USB GbE Family Controller ->Realtek USB GbE Family Controller

Downgraded to NPACP 1.60 and everything works fine.

Question: Are there any USB Network adapters that works with version 1.71 on Win11 at all?

[markkuleinio]

FWIW Npcap 1.72 did not fix this problem yet (Windows 11 22H2, Wireshark 4.0.2):

Npcap 1.60 still works.

[httpstorm]

@markkuleinio I installed Wireshark 4.0.2 a few hours ago and it came with npcap 1.71. Thanks for letting me know I should skip 1.72 as well! Hopefully this gets resolved sooner. Reverting the changes might be a good idea until a solution is found.

[ralish]

If there's an Npcap developer watching this, I'd be quite happy to provide the output from a debug build if one can be provided to help track down the root cause.

[davidebeatrici]

I encountered the same issue on Windows 11 22H2, 22621.963.

The network adapter is identified as Lenovo USB Ethernet, VID_17EF&PID_720C.

Downgrading to 1.60 indeed works.

[MaksymSofer]

The same issue

[rpersak]

Same here... After installing 1.60 it works...

[guyharris]

@jtippet Somebody asks, in this comment, "could it be related to a lack of support for the new NetAdapterCx driver model?"

I haven't found anything at learn.microsoft.com that looks like reference documentation for NetAdapterCx - some tutorial information, but nothing giving raw API details, siuch as, for example, how a NetAdapterCx driver is notified that an OID get or set operation is performed. What happens if you do an OID_GEN_CURRENT_PACKET_FILTER set operation? Is a NetAdapterCx driver told that the filter has changed, and what the new filter is?

[guyharris]

So, based on the GUID in the bug text and the error dialog, and the DiagReport, from the original bug report, the two adapter with the problem is "Lenovo USB Ethernet", with a manufacturer of Realtek and a service name of rtu53cx22x64, on Windows 11.

Other adapters reported are:

• Realtek RTL8153 USB GbE controller, with the same driver, rtu53cx22x64.sys, Windows 11.
• Intel I225-V, Windows 11.
• Realtek PCIe GbE Family controller, unknown Windows version.
• Intel Killer E3100, Windows 11.
• Aquantia (Marvell?) AQtion AQC107 10Gbit Network Adapter, Windows 10.
• Realtek Gaming 2.5GbeE Family Controller, unknown Windows version.
• Realtek Gaming GbE Family Controller and Realtek USB GbE Family Controller, Windows 11.
• Xemu (QEMU based Xbox Emulator) with an Intel(R) Ethernet Controller I225-V, unknown Windows version.
• TP-LINK Gigabit Ethernet USB Adapter, unknown chipset, unknown Windows version.
• Lenovo USB Ethernet, VID_17EF&PID_720C, Windows 11.
• Intel Killer E3100, e3k25cx21x64 driver, Windows 11.

So this is not a problem only with USB adapters, given that there's at least one report with a PCIe controller.

And this is not a problem only with Windows 11, given that there are some reports on Windows 10.

It might be a NetAdapterCx problem, if the driver for the adapter is, in all cases, a NetAdapterCx driver rathr than an NDIS driver.

[fyodor]

Thanks for all of the reports! This data really helps and we'll be discussing the issue in tomorrow's engineering meeting. We've also added it to the list of issues we're planning to fix for the upcoming 1.73 release.

[jtippet]

Is a NetAdapterCx driver told that the filter has changed, and what the new filter is?

Yes. A NetAdapterCx-based driver would advertise its supported flags by calling NetAdapterSetReceiveFilterCapabilities. When p-mode is enabled, the adapter receives an EVT_NET_ADAPTER_SET_RECEIVE_FILTER callback.

The actual netadaptercx code that handles this is available on github; you can see that it does a few checks to make sure the requested flags are supported by the driver, a bit of synchronization with other state-changing events, then sends the flags down. I'm not seeing a lot of opportunities for bugs to lurk in here, but maybe I'm overlooking something; there are a lot of customer reports, so something's clearly broken.

[Peter-Simpson]

Seeing the same issue so here is a further data point:

Asus ROG STRIX Z690-A Gaming WiFi D4 motherboard Windows 11 with latest updates Intel wired ethernet controller I225-V Driver version 2.1.2.3 (21/09/22)

Thanks for looking into this.

[fyodor]

Hi @Peter-Simpson , @rpersak, and @MaksymSofer, @davidebeatrici, @httpstorm, @ralish and anyone else experiencing this issue. Thanks for the reports, and can you please confirm using the Wireshark Help -> About dialogue that you are using Npcap Version 1.72? It was released on December 14 with a fix that we thought might resolve this. But if you're getting Npcap through Wireshark rather than from https://npcap.com, you might be using an older Npcap still. We'd like to hear from more people using 1.72. Thanks!

[markkuleinio]

Confirmed (Npcap 1.72):

Version 4.0.2 (v4.0.2-0-g415456d13370). ... Running on 64-bit Windows (22H2), build 22621, with 12th Gen Intel(R) Core(TM) i7-1270P (with SSE4.2), with 32435 MB of physical memory, with GLib 2.72.3, with PCRE2 10.40 2022-04-14, with Qt 5.15.2, with Npcap version 1.72, based on libpcap version 1.10.2-PRE-GIT, with c-ares 1.18.1, with GnuTLS 3.6.3, with Gcrypt 1.10.1, with nghttp2 1.46.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.5.2, without AirPcap, with light display mode, without HiDPI, with LC_TYPE=Finnish_Finland.utf8, binary plugins supported.

The capture session could not be initiated on capture device "\Device\NPF_{A586373D-21B0-41D4-995B-3617E49AEBCE}" (failed to set hardware filter to promiscuous mode: A device attached to the system is not functioning. (31)). Please turn off promiscuous mode for this device

The same error also with Wireshark 4.0.3 if that matters:

Version 4.0.3 (v4.0.3-0-gc552f74cdc23). ... Running on 64-bit Windows (22H2), build 22621, with 12th Gen Intel(R) Core(TM) i7-1270P (with SSE4.2), with 32435 MB of physical memory, with GLib 2.72.3, with PCRE2 10.40 2022-04-14, with Qt 5.15.2, with Npcap version 1.72, based on libpcap version 1.10.2-PRE-GIT, with c-ares 1.18.1, with GnuTLS 3.6.3, with Gcrypt 1.10.1, with nghttp2 1.46.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.5.2, without AirPcap, with light display mode, without HiDPI, with LC_TYPE=Finnish_Finland.utf8, binary plugins supported.

[guyharris]

It was released on December 14 with a fix that we thought might resolve this.

It might resolve some cases, but if the driver, for whatever reason, rejects attempts to set the receive filter, and either 1) it returns STATUS_UNSUCCESSFUL or 2) it returns STATUS_NOT_SUPPORTED, as would make sense in this case, but something in the subsequent code path turns it into STATUS_UNSUCCESSFUL, that would cause this problem, even with the current Npcap code. Pull request #656 restores a workaround for that problem, by setting the C bit in the status (see my huge comment added by that commit).

[dmiller-nmap]

@guyharris Thanks! Checking it out now.

[jensmunk]

I have a TP-Link adapter showing the problem I would be pleased to you. Just let me know where you want it sent.

[Hobo2k]

No npcap 1.72 has the same problem at my pc

Windows 11 Version 22H2 (22621.1105) Lenovo Ethernet: USB\VID_17EF&PID_A387&REV_3103

[Peter-Simpson]

Hi,

I recently had a similar issue and found that I had to uninstall NCAP 1.7 and then to install v1. 60. Wireshark then worked ok in promiscuous mode.

Best wishes Peter

⁣Get BlueMail for Android ​

On 27 Jan 2023, 09:12, at 09:12, Felix @.***> wrote:

No npcap 1.72 has the same problem at my pc

Windows 11 Version 22H2 (22621.1105) Lenovo Ethernet: USB\VID_17EF&PID_A387&REV_3103

-- Reply to this email directly or view it on GitHub: https://github.com/nmap/npcap/issues/628#issuecomment-1406214945 You are receiving this because you were mentioned.

Message ID: @.***>

[ralish]

@fyodor Can confirm I'm running Npcap v1.72. Let me know if I can offer any further data.

[TylerJaacks]

xemu

[agould123]

Thanks for the info, this fixed my problem. I was seeing "the capture session could not be initiated on capture device failed to set hardware filter to promiscuous mode" . I tried downgrading from wireshark 4.0.3 to 3.6.11 but that did not fix it. However, downgrading the npcap version did fix it. I had Npcap 1.71, downgrading to 1.60 fixed it. I can now run wireshark on my ethernet interface again. I use a Laptop Dell Precision 5400, which is usb-c thunderbolt connected to my dell docking station WD19TB.

This is how i could see my npcap version....

before... C:\Program Files\Npcap>NPFInstall.exe NPFInstall for Npcap 1.71 ( https://npcap.com )

after... C:\Program Files\Npcap>NPFInstall.exe NPFInstall for Npcap 1.60 ( http://npcap.org )

i didn't reboot, it just worked after getting npcap 1.60 from here.... https://npcap.com/dist/

[1160300131]

So can we say this problem could be resolved in next version? I have the same problem. Use npcap v1.60 can fix it. windows: win11 22H2 (22621.1105) wireshark v4.03 npcap: v1.71/v1.72

[jensmunk]

Any news on this issue?

Wireshark just rolled out an update again, and if you don't pay attention, it by default "upgrades" Npcap to version 1.71, and you are out.

[fyodor]

Thanks everyone. We're hoping PR #656 by @guyharris will resolve this. It has been merged and we're hoping to release Npcap 1.73 in the coming weeks with this and other improvements.

[guyharris]

Note that "resolve" means "cause the failure to set the filter to promiscuous mode to be reported to the libpcap component of Npcap in such a fashion that it can recognize that particular failure and ignore it, allowing capture to proceed", not "prevent the failure from occurring". The failure might be a problem with the Ethernet adapter driver or some part of NDIS, which may mean that there's nothing Npcap can do to fix it, because it's a problem with software not provided by the Npcap or libpcap developers.

My pull request merely causes the Npcap driver to report that error to userland the way earlier versions of that driver did.

I don't know whether this failure is real, in that the capture isn't done as a promiscuous-mode capture, or bogus, in that the adapter is in promiscuous mode. If you're only trying to capture packets to or from the machine running the program, it doesn't matter whether it's done in promiscuous mode or not. If you're trying to capture other machines' traffic from a non-switched Ethernet or from a "mirror port" (or whatever your switch vendor calls it), it does matter.

Libpcap should probably be changed to report that failure as a warning, so that programs that recognize the warning can report it before continuing to capture. I think Wireshark may report warnings in this case.

[DuncanConroy]

@guyharris I think you're a bit too humble :D Thanks 💯 times for the "fix"!

[mirozitnansky]

Unfortunately update 1.73 didn't help with this issue. Just installed 1.73 and when using with wireshark I am still getting with Intel(R) Ethernet Controller I225-V on windows 11.

[markkuleinio]

Confirmed:

The capture session could not be initiated on capture device "\Device\NPF_{A586373D-21B0-41D4-995B-3617E49AEBCE}" (failed to set hardware filter to promiscuous mode: Couldn't get error message for error (3758096385)). Please turn off promiscuous mode for this device

Wireshark on Windows 11, with a Realtek-based USB-C NIC.

Version 4.0.4 (v4.0.4-0-gea14d468d9ca). ... Running on 64-bit Windows (22H2), build 22621, with 12th Gen Intel(R) Core(TM) i7-1270P (with SSE4.2), with 32435 MB of physical memory, with GLib 2.72.3, with PCRE2 10.40 2022-04-14, with Qt 5.15.2, with Npcap version 1.73, based on libpcap version 1.10.3, with c-ares 1.18.1, with GnuTLS 3.6.3, with Gcrypt 1.10.1, with nghttp2 1.46.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.5.2, without AirPcap, with light display mode, without HiDPI, with LC_TYPE=Finnish_Finland.utf8, binary plugins supported.

[guyharris]

3758096385 is 0xE0000001.

The bits in the upper nibble of that are 1110, so, as per the format of an NTSTATUS value, that has:

• a 2-bit Sev field, containing the severity, with the value 0b11 = 0x3, for STATUS_SEVERITY_ERROR;
• a 1-bit C field, which is 1 for customer-defined values, and the value is 1;
• a 1-bit N field, which is reserved and must be zero, and is zero.

The Facility field is 0 and the Code field is 1.

The C bit is set in the driver in order to try to prevent some currently-unknown code from "helpfully" mapping STATUS_NOT_SUPPORTED to STATUS_UNSUCCESSFUL. STATUS_UNSUCCESSFUL is 0xC0000001, so this appears to be a case where either 1) STATUS_NOT_SUPPORTED was mapped to STATUS_UNSUCCESSFUL before we set the C bit or 2) something is failing and returning STATUS_UNSUCCESSFUL.

STATUS_UNSUCCESSFUL gets mapped to the Windows error code ERROR_GEN_FAILURE. Neither are very useful return code values, and should only be returned if no other status value is available, because all they tell the caller, the developer, and the user is "I couldn't do that for some unspecified reason", which is rather difficult to translate into a specific cause to fix.

[guyharris]

The places inside the NPF driver where STATUS_UNSUCCESSFUL is returned - as opposed to returning a status from other NT kernel-mode code, with that code returning STATUS_UNSUCCESSFUL - are:

• any place that calls NPF_Deny():
  • if Npcap is compiled with NPCAP_READ_ONLY, write calls call it;
• in funcBIOC_OID(), in the if (pOpen->pFiltMod->Dot11 && (OidData->Oid == OID_GEN_MEDIA_IN_USE || OidData->Oid == OID_GEN_MEDIA_SUPPORTED)) case, if it's a "set" operation;
• in NPF_GetCurrentOperationMode(), if the number of bytes processed, as returned by NPF_DoInternalRequest(), isn't equal to sizeof(CurrentOperationMode);
• in NPF_Read(), if Open->Size is 0;
• any place that calls EXIT_FAILURE() - but no places do, so EXIT_FAILURE() should perhaps be removed;
• in NPF_Write(), if:
  • Open->pFiltMod->MaxFrameSize is 0;
  • buflen is greater than Open->pFiltMod->MaxFrameSize;
• in NPF_BufferedWrite(), ifOpen->pFiltMod->MaxFrameSize` is 0.

None of those look as if they should cause STATUS_UNSUCCESSFUL to be returned in this case.

[guyharris]

@guyharris I think you're a bit too humble :D Thanks 💯 times for the "fix"!

No, I'm not too humble - this didn't fix the problem (so putting "fix" in quotes was appropriate).

However, it did help narrow down the cause of the problem, as the reported errors indicate that STATUS_UNSUCCESSFUL is probably being returned from the attempt to set the filter. It's probably the result of a change between 1.60 and 1.7x where, somehow, the setting of the filter changed in a way that causes drivers to report STATUS_UNSUCCESSFUL for an attempt to set the filter.

[fyodor]

Another report that 1.73 didn't fix the problem was provided by @youngbeggar in #665 . (Closed as duplicate of this one)

[guyharris]

Oh, and NDIS_STATUS_FAILURE is defined as...

...((NDIS_STATUS)STATUS_UNSUCCESSFUL)

so anything in Npcap that returns NDIS_STATUS_FAILURE is returning STATUS_UNSUCCESSFUL. That means some additional places where STATUS_UNSUCCESSFUL is returned are:

• NPF_OidGetUlongNonpagedPtr(), if the number of bytes processed, as returned by NPF_DoInternalRequest(), isn't equal to sizeof(ULONG);
• NPF_GetDataRateMappingTable(), if the number of bytes processed, as returned by NPF_DoInternalRequest(), isn't equal to sizeof(DOT11_DATA_RATE_MAPPING_TABLE), or if the type, revision, or size of the data rate mapping table aren't what's expected;
• NPF_SetPacketFilter(), if the number of bytes processed, as returned by NPF_DoInternalRequest(), isn't equal to sizeof(PacketFilter);
• NPF_SetLookaheadSize(), if the number of bytes processed, as returned by NPF_DoInternalRequest(), isn't equal to sizeof(ULONG);
• NPF_DoInternalRequest(), if NdisFOidRequest() returns NDIS_STATUS_SUCCESS but the RequestType argument is neither NdisRequestSetInformation, NdisRequestQueryInformation, nor NdisRequestMethod.

NPF_DoInternalRequest() has code that, if NdisFOidRequest() returns NDIS_STATUS_SUCCESS and the RequestType argument is one of the values listed, truncates the number of bytes processed value to a value no larger than the InformationBufferLength argument for NdisRequestSetInformation, andNdisRequestQueryInformation and no larger than the OutputBufferLength argument for NdisRequestMethod. The comment before that code says:

The driver below should set the correct value to BytesWritten or BytesRead. But now, we just truncate the value to InformationBufferLength due to bug in Nortel driver ipsecw2k.sys v. 4.10.0.0 that doesn't set the BytesWritten correctly The driver is the one shipped with Nortel client Contivity VPN Client V04_65.18, and the MD5 for the buggy (unsigned) driver is 3c2ff8886976214959db7d7ffaefe724 *ipsecw2k.sys (there are multiple copies of this binary with the same exact version info!) The (certified) driver shipped with Nortel client Contivity VPN Client V04_65.320 doesn't seem affected by the bug.