-
Notifications
You must be signed in to change notification settings - Fork 524
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 strange behavior with WireShark #334
Comments
Since you have Npcap 0.9983 installed, you no longer need the Npcap Loopback Adapter in order to do loopback capture. This dummy adapter was needed in previous releases, but had an unfortunate side effect of causing routing problems especially on systems with multiple network adapters or VPNs. The only reason it is left in is for legacy support for certain programs that need it, primarily Nmap 7.80 and earlier. Try reinstalling Npcap and un-checking the "Legacy loopback" installation option. If this does not solve the problem, we will see what remains to be done. |
Thanks for the response! I tried the following but am still seeing the issue:
A few observations:
|
Yes, Wireshark requires Npcap to be running in order to do capture because Npcap is what does the capturing, so your observations are as expected. I will look into this and see if I can reproduce your issue here. |
I have not been able to reproduce this issue, so I have a few more diagnostic questions or suggestions:
|
Answering your questions in order:
Big thanks again and I'll report back with any new info soon! |
Okay, some updates related to the previous list of questions:
The issue is definitely a direct result of the "C:\Windows\System32\Npcap\wpcap.dll" file. When I move this file to a temporary location, the issue goes away and the loopback adapter does not show up in Wireshark. When this file is in its normal location, the issue occurs immediately after starting Wireshark and it loads the list of interfaces (i.e. no need to start a capture). I did notice some strange Wireshark traffic graphs with npcap enabled and disabled (by moving the wpcap.dll): Maybe there is some strange interaction with Hyper-V (this is Windows 10 Pro, I forgot to mention that previously, sorry). I might try to temporarily disable Hyper-V later using these instructions found on StackOverflow. I cannot permanently disable Hyper-V since Docker is needed on this machine. |
If Npcap is disabled in the second screenshot, presumably WinPcap is being used - some capture driver, packet.dll for that driver, and capture DLL for Wireshark to use is present. |
Quick update, I haven't investigated this much further recently. After some reading, was scared away from disabling Hyper-V since some people report issues afterwards. If anyone has advice on how to debug this, please give a holler. |
I believe that I'm having the same issue with users here as well. Web browsing stops working after starting Wireshark/Npcap 0.9986 Setup:
Other notes:
|
When Wireshark starts up, it begins packet capture on all interfaces, using the statistics to create the "sparkline" traffic graphs next to each interface. This is likely the event that is triggering the network interruption, which as @daulis points out is likely unavoidable now that the Npcap Loopback Adapter is not required in order to do loopback capture. You may be able to avoid this by using the command-line to start Wireshark, specifying a particular interface with the I have just a few more questions that I would like to have answered to help me narrow down the scope of the issue:
|
I tried these things on a different PC than my previous report, so I can confirm that it's reproducible on at least 2x PCs here. Some extra info that I did before answering your questions above:
Answers to your questions. For these steps, I installed 0.9986, and unchecked "Install Npcap in WinPcap API-compatible Mode". I did this to match what Wireshark sets as defaults during install.
It appears just the act of Listing Interfaces is enough to trigger the issue. |
Note that giving You'd have to give the Big Ugly String With a GUID as the |
@guyharris When I tried using GUID, Wireshark still does the "Finding local interfaces" step. I tried using |
Then you'll have to try it with |
|
Unfortunately, the code that processes the This is a job for tcpdump, but there's currently no convenient binary build for recent tcpdump; you might try windump, which may require installation of npcap in WinPcap-compatibility mode. |
@guyharris Thanks for jumping in with suggestions and explanations. It seems simply opening the Loopback device is sufficient to trigger the bug, so unless @daulis is looking for a workaround that involves separate packet capture with windump and subsequent analysis with Wireshark, it seems the ball is in our court to figure out a fix. We are looking into a separate privately-reported crash related to repeated opening of the loopback adapter, so I'm hopeful we can improve things generally and take care of this bug in the process. |
Or, at least, that any call to Given that the Presumably the bug not showing up if there is no loopback adapter is what shows that the bug is probably triggered by opening the loopback adapter. (Unless 0.9982 has been tested with "Support loopback traffic" checked, it has not been established that the bug was introduced in 0.9983; if, with 0.9982 installed with loopback traffic support enabled, the problem shows up, what has been demonstrated is that 0.9983 removed the one reliable way of preventing the bug from being triggered, at the expense of having loopback capture support removed - which might be a reasonable tradeoff for some users.)
WinDump will only call |
@dmiller-nmap I can pull extra data from one of the PCs that is having this issue, and I can also try out test builds of npcap if that helps you. |
As a workaround, Npcap 0.9987 released today includes the above commit, which will allow you to use the Windows Registry to disable the loopback WFP callouts, which likely contain the problem code that we have not yet identified. Just set |
Two observations when using 0.9987:
|
This issue should be resolved by Npcap 0.9988, released today. We would appreciate your feedback so we know whether to close this issue. |
Just updated to Npcap 0.9988 and the issue appears to be resolved! Thank you greatly! |
Been seeing strange behavior with Wireshark and the Npcap Loopback Adapater. After starting a Wireshark capture on that interface, websites no longer load in a browser. For example, trying to browse to Wikipedia might result in a "Can’t reach this page" in Microsoft Edge or a ERR_CONNECTION_ABORTED/ERR_CONNECTION_RESET in Chrome. This issue will continue after the capture has stopped until I manually stop Npcap in a terminal using "net stop npcap".
It's possible that just having Npcap running is the issue but the issue seems to consistently happen after starting a Wireshark capture.
I added a screen capture of the issue here: https://youtu.be/eUuBBvwRU0g
Windows 10 version 1803
Wireshark version 3.0.5 (v3.0.5-0-g752a55954770)
Npcap version 0.9983
DiagReport-20191017-164533.txt
The text was updated successfully, but these errors were encountered: