Skip to content
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

Jump to bottom

Npcap 0.9985: Driver goes to DEMAND_START after Windows 10 feature update, won't start at pcap_findalldevs() #1911

Closed
akontsevoy opened this issue Feb 8, 2020 · 3 comments
Closed

Npcap 0.9985: Driver goes to DEMAND_START after Windows 10 feature update, won't start at pcap_findalldevs() #1911

akontsevoy opened this issue Feb 8, 2020 · 3 comments

Comments

@akontsevoy
Copy link

akontsevoy commented Feb 8, 2020 •
edited

Npcap 0.9985 was installed on a Windows 10 Enterprise version 1803 with the default start service start mode for npcap.sys (npcap-0.9985-oem.exe /loopback_support=no /admin_only=yes /dot11_support=no /winpcap_mode=no /S). It worked as expected until Windows received a feature update to version 1909. The driver start type has changed to DEMAND_START and no longer starts on OS boot:

>sc qc npcap                                                                                                                                                                          [SC] QueryServiceConfig SUCCESS                                                                                                                                                                                    
SERVICE_NAME: npcap
        TYPE               : 1  KERNEL_DRIVER
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : \SystemRoot\system32\DRIVERS\npcap.sys
        LOAD_ORDER_GROUP   : NDIS
        TAG                : 17
        DISPLAY_NAME       : Npcap Packet Driver (NPCAP)
        DEPENDENCIES       :
        SERVICE_START_NAME :

I think this behavior of Windows updates has been discussed before and it was concluded that nothing can be done about it.

However, the problem is that Npcap versions prior to 0.998x (or at least 0.99-r7) used to start the driver themselves when the library was opened and pcap_findalldevs() executed. But this no longer happens with 0.9985; the driver remains stopped and only the loopback interface is returned. If the driver is manually started, it works as expected.

Furthermore, the workaround we had in place to detect and remediate such condition (check if pcap_findalldevs() returns no adapters, execute NPFInstall.exe -r -n and manually restart the driver) is no longer effective, because at least since 0.998x a loopback adapter is always returned regardless of the state of the driver (though we can adjust the work-around on our end).

I believe the original behavior (i.e. to start the npcap service if stopped) was correct.
@dmiller-nmap
Copy link

Thanks for this report. The fact that Windows changes the start type of the service is a known issue (#998) which we do not have a solution to at the moment. The change to avoid starting the driver service was made in Npcap 0.9983 based on the fact that in the majority of cases the user running it doesn't have appropriate privileges to start or install the driver service. We were looking for ways to speed up the pcap_findalldevs() process, and a failed call to OpenServiceA() for every installed adapter seemed like a good thing to eliminate. I'll look into how we might re-enable this functionality in a different place that wouldn't have such an impact, like DllMain.

@akontsevoy
Copy link
Author

Sounds good to me, though it might be risky to do in DllMain() under a library lock (because who knows what additional libraries those OpenSCManager/OpenService/ControlService calls might be trying to load under the hood). Maybe it's better to check & start the driver lazily on any pcap API call once if this was not already tried, but if that fails, set the state variable accordingly and avoid trying that again.

dmiller-nmap pushed a commit to nmap/npcap that referenced this issue Feb 24, 2020
@bonsaiviking
Restore ability to start driver if it is stopped; only once per proce…
83b166d 
…ss. See nmap/nmap#1911
@dmiller-nmap
Copy link

This is fixed in Npcap 0.9988, released today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@akontsevoy @dmiller-nmap