Re: Npcap 0.03 call for test

[Jim Young <jyoung () gsu edu>]

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 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.

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).

Best regards,

Jim Y.


________________________________
From: wireshark-dev () wireshark org on behalf of Yang Luo <hsluoyb () gmail com>
Sent: Wednesday, August 5, 2015 03:39

<snip>

Thanks for test. I have confirmed and fixed this "Malformed Packets" issue, this is because the packet read function 
NPF_TapExForEachOpen didn't copy the 2nd MDL data if the data has crossed the buffer boundary. Latest installer that 
has this bug fixed is:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.03-r4.exe 
<https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.03-r4.exe>

<snip>

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe