Wireshark-dev: Re: [Wireshark-dev] Npcap 0.03 call for test
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Yang Luo <hsluoyb@xxxxxxxxx>
Date: Wed, 5 Aug 2015 15:39:39 +0800
Hello Jim,

On Tue, Aug 4, 2015 at 12:23 PM, Jim Young <jyoung@xxxxxxx> wrote:
Hello Yang,

While testing Npcap 0.03-r3 I stumbled into one reproducible issue but I
also triggered a crash (which I am currently unable to reproduce).

The reproducible issue involves capturing on the Npcap loopback interface and
then starting a cmd shell and pinging the loopback address as follows:

ping -t -l 65500 127.0.0.1

The first several ping requests and responses are seen and captured but after
several seconds I started seeing "[Malformed Packets]" of length 14.  A pair of
Malformed packets were seen each second.  When I stopped the ping, the Malformed
Packets stopped.  I stopped and restarted Wireshark but the same thing happened. 

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:


I then wanted to reboot the system to see if I could still replicate this Malformed
Packet issue.

After the system rebooted I double-clicked on the Wireshark icon but it did not
immediately start.  I thought that I had not double-clicked on it properly so I
double-clicked on the Wireshark icon a second time and then the system crashed
with the following Bug Check Message:

DRIVER_IRQL_NOT_LESS_OR_EQUAL

This is still the NdisFOidRequest BSoD issue we talked about on this list before, IMO this BSoD has nothing to do with the "Malformed Packets" issue. The last way to fix it is to just disable the GetDeviceMTU call and directly returns 1514 for MTU, so this issue should be got rid of, however this is never a good way to fix a problem.
 

Cheers,
Yang