Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Npcap 0.03 call for test

From: Yang Luo <hsluoyb@xxxxxxxxx>
Date: Tue, 4 Aug 2015 12:23:39 +0800
Hi Jim,

On Tue, Aug 4, 2015 at 2:52 AM, Jim Young <jyoung@xxxxxxx> wrote:





From: wireshark-dev-bounces@xxxxxxxxxxxxx <wireshark-dev-bounces@xxxxxxxxxxxxx> on behalf of Pascal Quantin <pascal.quantin@xxxxxxxxx>
Sent: Monday, August 3, 2015 12:48
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Npcap 0.03 call for test
 
Hello Yang,

Since my last comments I've been (quietly) testing the various updated Npcap releases.   I've really had nothing new to add to Tyson's and Pascal's comments until now.

I'm currently testing with Npcap 0.03-r3.

But unlike Pascal I do not crash when starting Wireshark.

Up until this version I could reliably blue screen my Windows 8.1 machine simply by loading a Buildbot development version of Wireshark (I had been testing with 1.99.9-7-g23ca456) and simply leaving the Wireshark's Qt based Welcome screen up.  The Qt version of Wireshark will display spark lines of traffic through the various interfaces.  I would simply walk away and leave the system alone.  Prior to Npcap 0.03-r3 the system would generally bluescreen within 10 to 20 minutes (but sometimes more than an hour would pass before Windows would crash).   Most of these crashes were with the bug check string BAD_POOL_CALLER, but two times since last Thursday morning the crashes had the bug check string BAD_POOL_HEADER.  I have mini-dumps for those crashes but not a full dump.  (I've switched to collecting full dumps now).

The major work of 0.03-r3 is to fix the BAD_POOL_CALLER (BAD_POOL_HEADER) issue, so if you encounter any those more, please tell me.
 

From my point-of-view Npcap 0.03-r3 so far appears to be the most stable of the Npcap versions I've been testing with.

I did have the Npcap installation stall problem that I have reported in my earlier comments.  I have a theory (which I will be testing later today) regarding how to replicate the Npcap installer stall.

I have no clue about this "NPFInstall -il" stall issue, as it only occurs to me one time or two, and I haven't seen it for several weeks. It would be great if you can come up with a replicate approach.
 

I have VirtualBox 5.0 installed on the Windows 8.1 machine but at this point I am not currently running any VMs.

Since you released the first Npcap 0.03 version (I believe) I have not seen any more dialog pop-ups about the Cisco AnyConnect VPN adapter (but I also have not attempted to use same in the last week or so either).  (FWIW: The Device Manager's Device Description for this adapter is "Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64" with a Driver Date of Friday, August 30, 2013 and Driver Version of 3.1.4065.0).  I did just find this particular Network adapter disabled so I have re-enabled and will wait and see if any new Cisco AnyConnect VPN error dialogs pop up.

With adapter disabled, I'm afraid Cisco AnyConnect wouldn't work. And conflict wouldn't happen in this condition.
 

Since you resolved the TCP payload issues I can see the TCP payload packets that traverse the loopback interface (for example the payload packets when Firefox is running).

Over the next week I hope to be able to leverage some other tools to more extensively push the limits of sniffing on the loopback interface and also perhaps compare capture performance of Npcap version WinPcap on standard interfaces.  



It would be very nice to have some performance test, Npcap uses NDIS 6 which has better performance than WinPcap, but I didn't test it before. Such a test will motivate more people to use it.  


Cheers,
Yang