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 extremely slowing down connectivity at boot WIN10 #65

Open
crankedguy opened this issue Mar 5, 2019 · 7 comments
Open

Npcap extremely slowing down connectivity at boot WIN10 #65

crankedguy opened this issue Mar 5, 2019 · 7 comments

Comments

@crankedguy
Copy link

@crankedguy crankedguy commented Mar 5, 2019

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

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Mar 5, 2019

We have had lots of problems getting the "driver not started at boot time" feature to work. The general issue is that Windows expects network drivers to be available at boot. If you mark your driver as "optional," then it hangs around for a while trying to see if it will start anyway. If it's "mandatory," then it's started at boot or you don't boot. I will still look into this, but be aware that it's a known source of problems.

Can you help us diagnose by providing a bit more information?

  • What version of Npcap are you using?
  • Output from DiagReport.
  • Why is it important to you to not start Npcap at boot? If it is for performance reasons, can you provide performance measurements showing that it causes slowness?

@crankedguy
Copy link
Author

@crankedguy crankedguy commented Mar 7, 2019

Hi,
I am using npcap-0.99-r9
Well are we just talking now about just a driver load with this setting or the running service in terms of packet capturing possibility? Because I don't care if a driver is loaded at boot but I do care if a capturing service is started/running at boot. That is why I disabled this. Don't want that on my machine(s) and with Winpcap it was always done manually without issues and without delays on boot. When I want to capture packets it is no issue to do a simple net start command, and that is how it should be from my pov.
I will be away for some time now so I might not answer shortly but will stay on this topic.

Thanks

@gvanem
Copy link

@gvanem gvanem commented Mar 7, 2019

... and with Winpcap it was always done manually without issues and without delays on boot.

Speaking for myself, I have no need for NPcap until such trivia is fixed.
But what features of NPcap do you really need in favour of WinPcap now?

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Mar 19, 2019

I found the reference for this issue from Microsoft: "Optional NDIS Lightweight Filters (LWF) could cause 90-second delay in network availability"

To summarize, there is good news and bad news. The good news is that Npcap is implemented as a NDIS 6 Lightweight Filter (LWF) driver, which means that it has substantially less overhead and
faster performance than WinPcap. The bad news is that filter drivers are not intended to be started and stopped frequently, so Windows expects all installed filter drivers will be started as part of startup. "Optional" filters (like Npcap) won't prevent the network from starting altogether, but Windows will wait to see if anything starts them before it makes the network available.

At this point, our plan for the next release is to simply remove the "Automatically start the Npcap driver at boot time" option and have the driver always start at boot. This avoids the issue reports like this one complaining of network interruption at boot, streamlines the installation process, and better fits Microsoft's design for NDIS driver architecture.

@crankedguy
Copy link
Author

@crankedguy crankedguy commented Mar 19, 2019

Well, but this doesn't explain the apparent difference to WinPcap startup. While it is nice for sure that npcap has better performance this is not exactly the topic here...
WinPcap simply does not have a delay if installed, but not started at boot. Maybe it has but it is not noticeable at all while with Npcap the delay is somewhere around 30 seconds on all my systems which is highly annoying.
A driver like npcap should only be started with admin rights and not running in the background at a normal system boot.
But maybe this is just my point of view.

Thanks for the hint that you will remove this in the future.

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Mar 20, 2019

As I mentioned before, WinPcap is a different type of driver entirely. It is a NDIS 5 protocol driver, and is therefore subject to different rules within Windows. This 90-second delay when NDIS 6 LWF drivers are unavailable is the "cost of doing business" in the modern NDIS architecture. It is not a choice that we made, and there is nothing we can do to avoid it. But this is not the bad thing that it might seem, because Npcap comes with better options for access control than not starting at boot.

Npcap can be installed with the "admin-only" option, which requires a process to be running with administrator privileges in order to perform any packet capture or injection operations. WinPcap never had this level of access control: even if you require admin privilege to start the driver service, once it is started, any process can access capture and injection capabilities.

For convenience and least privilege, Npcap's Packet.DLL launches a helper process to elevate to administrator (UAC prompt) and mediate requests from the original application, which still runs with standard privileges. We have some tentative plans to expand this feature to allow admins to configure access control to allow only certain groups to access Npcap functions. If you have concerns or suggestions for improving this feature, we'd be very happy to hear them.

@crankedguy
Copy link
Author

@crankedguy crankedguy commented Mar 20, 2019

Now looking a bit deeper into going this way you describe with the admin-only option, this sounds like a better approach indeed than it was done the old fashioned way. It will allow more granular control for sure.
Thanks for explaining it in more detail.

Group privileges to "access" npcap would be highly welcome here

@fyodor fyodor transferred this issue from nmap/nmap May 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants