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

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Jim,

On Thu, Aug 6, 2015 at 4:43 PM, Jim Young <jyoung@xxxxxxx> wrote:

Hello Yang,

I've been doing some testing with Npcap 0.03-r4.

Current observations:

I can confirm the ping -t -l 65500 127.0.0.1 command is now working as expected.

Also I have been unable to trigger any BSODs.

On my primary Windows 8.1 system I can easily reproduce the installation stall during the -il step.   But on a second (more pristine) Windows 8.1 system I had no issues with repeatedly reinstalling npcap 0.03. If I can successfully setup a npcap build environment I'll try to augment NPGInstall's InstallLoopbackAdapter() with some messages to help determine which specific call it stalls at during the installation attempt that immediately happens after an apparently successful uninstall. 

But regarding throughput capturing with Npcap, on a 1G nic interface Npcap appears to silently drop about 3 of every 4 packets when the interface is under load.  And there is no indication that there were packet drops when using Npcap.

Here's my testing methodology.

First I enabled the Window's Simple TCP/IP Services.   This is a set of test TCP and UDP services that are normally disabled on a Windows machine.  Once the Simple TCP/IP Services are enabled the Windows system will have five basic TCP and UDP services to test against.  These services includes echo (port 7, RFC 862), discard (port 9, RFC 863), daytime (port 13, RFC 867), quote service (port 17, RFC 865), and chargen (port 19, RFC 864).  The plan is to use the chargen service to test capture throughput.   One only needs to establish a TCP connection to port 19 to trigger a constant stream of traffic.  I installed cygwin's inettools package to be able to use cygwin's telnet client to connect to the Window's local chargen service (e.g. telnet 127.0.0.1 19).   To get telnet to exit gracefully, do a CTRL-C followed by a CTRL-].  The CTRL-] should present the "telnet>" prompt.  At the telnet> prompt enter the "quit" command (without the quotes) and press enter. 

When I captured using Npcap's loopback adapter Wireshark appeared to capture all packets for several seconds and then nothing.  When reviewing the TCP trace from the Loopback interface it did not appear that any packets were dropped up to the moment that no more packets were captured.   When reviewing the trace file I could see TCP Window FULL messages implying that the chargen service could send data faster than the telnet client could consume it. But it appeared that all chargen packets in the loopback interface were successfully captured up to the point where no more packets were received.  I suspect the point point where Wireshark stopped receiving packets to a be an issue between dumpcap and Wireshark and not related to Npcap.  When I ran dumpcap directly I could leave the telnet connection to the changen service up quite some time without dumpcap failing to update its packet counter (but I had to be careful to not run the SSD disk out of space).  

I don't know if this "no more packets" issue is related to Wireshark, but I captured nearly 10000 packets and didn't find this issue. 

 

I then established a direct 1G ethernet connection between the Windows 8.1 system and a MacBook Pro.  To allow access to the chargen service on the Window's machine from the MacBook Pro I had to temporarily disabled Window's firewall.   Like with cygwin I used a telnet client on the MacBook Pro to connect to the Window's machine's chargen service.  I used dumpcap on both systems to capture the packets.  With Npcap installed the Window's system only captured about 25% of the total chargen packets transmitted from the Windows system to the MacBook.  When dumpcap was shutdown there was no indication that any packets had been dropped on the Windows machine yet the total packets reported was 1/4 of the number reported by the MacBook's dumpcap process.   The MacBook Pro also reported capturing 100% of the chargen traffic which a review of the trace file on the OS X system appeared to confirm.   I then reinstalled WinPcap on the Windows machine and redid the test.  With the WinPcap driver in place dumpcap reported that it captured 99.9% of the chargen packets.  The resulting trace file was only missing a few hundred packets relative to the trace file captured onthe MacBook Pro.  Under load it appears that the current Npcap driver can NOT capture packets at the anywhere near the same rate as WinPcap.

I have confirmed this bug, when you follow the TCP stream, you could find some words like "[1460 bytes missing in capture file]". This is because Chargen packets used multiple net buffers, while Npcap only captures the first net buffer. This will be fixed in next release.

 

Additionally it does not appear that BPF filters are working with Npcap when applied against the Loopback interface.  Whenever I tried to capture on the loopback with with a capture filter I would receive no packets.  Within Wireshark after clearing the capture filter field I would still see no packets; I had to shutdown and restart Wireshark to again capture packets on the loopback interface.  Using tshark (or dumpcap) I could easily reproduce the problem with a capture filter on the loopback interface.  In this case I first proved that I could capture a packet on the loopback interface using the daytime service (e.g. telnet 127.0.0.1 13).  I then started tshark with a tcp capture filter (e.g. tshark -i 6 -f tcp) and I would see no packets are captured (the Npcap Loopback Adapter was device #6 as reported by the command tshark -D). 

This is also a bug, loopback packets will use multiple MDLs, while Npcap only uses the first MDL (only first 20 bytes) for BPF filtering, the following bytes can be viewed as zero, so all filter strings for IP header and later (like tcp) will fail. I have fixed this bug.

 

Cheers,

Yang