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

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

Open
akontsevoy opened this issue Feb 8, 2020 · 2 comments

Comments

@akontsevoy
Copy link

@akontsevoy akontsevoy commented Feb 8, 2020

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

This comment has been minimized.

Copy link

@dmiller-nmap dmiller-nmap commented Feb 24, 2020

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

This comment has been minimized.

Copy link
Author

@akontsevoy akontsevoy commented Feb 24, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.