Wireshark · Wireshark-dev: Re: [Wireshark-dev] Get "Malformed Packet" for 802.11 Beacon frames on Windows

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 14 April 2016 at 11:01, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

On 14 April 2016 at 01:07, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

Hi Graham,

On Thu, Apr 14, 2016 at 12:50 AM, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

On 13 April 2016 at 17:26, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

Hi Graham,

On Wed, Apr 13, 2016 at 6:11 PM, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

On 13 April 2016 at 06:07, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

Hi Guy,

As you know, Npcap/WinPcap is currently based on libpcap 1.0 branch 1_0_rel0b (20091008), which is a very old version.

Adding features to so old wpcap.dll code will put me even farther away from the libpcap trunk.

So I wanted to use the latest libpcap code in Npcap before adding code. Actually I posted a thread on tcpdump list about how to build libpcap on Windows before. But no solutions.

Do you know how to build libpcap into wpcap.dll?

I guess Loris developed the 1st generation WinPcap and ported libpcap into wpcap.dll. How did he achieve this?

This is one of the priority items on my TODO list,

Good to hear it:)

 

 

however first I want to finish off getting all the Visual Studio Code Analysis issues first which has stalled due to lack of time,

I also gave a shot of using "Analyze" -> "Run Code Analysis" in VS2015 against Npcap driver project. It supplied me so many trivial alarms which are definitely not going to happen, like assuming the CPU count is 0.

I agree that some of the flagged issues are somewhat extreme, however that particular area of code does have some issues with the locks obtained and the IRQL.  I have a change for that pending but need to test some more.

I think for a driver we need to get it compiling as clean as possible, no warnings at all.

 

and the fact that VS2015 Update 1 has totally broken driver remote deploy and test.  I need to check if Update 2 has fixed that.

I'm using VS2015 Update 2 now. I have confirmed that the remote debugging is still not fixed. I use the "Network" connection way and it gave me:

----------------------------------------------------------------------------------

Installing necessary components...

Failed operation: An error occurred while connecting from the remote machine.

Error: 10060 (TimedOut)

Error message: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.47.139:50005

----------------------------------------------------------------------------------

So I guess the only workaround for now is rolling back to VS2013.

This seems to have changed though, before even attempting to configure it caused an error.  I shall try to have a look at that tonight.

Personally I don't mind going back to VS2013 because at least the debugging worked there, but what WDK do we use then, continue with Win 10 (if that's possible), or use 8.1?

Only the following two pairs work out. 

1) VS2013 + WDK8.1

2) VS2015 + WDK10

I have already adapted to the situation without remote IDE debugging. I primarily troubleshoot minor issues by looking at the print log. And for BSoD, I just analyze the dump file for causes. These two ways are barely adequate for me temporarily.

I did manage to get VS2015 remote kernel debugging running last night, it seems it's just the automated deploy of the driver that's broken.  I raised an issue on Microsoft Connect for that: http://connect.microsoft.com/VisualStudio/feedback/details/2586448/unable-to-remote-deploy-a-driver-for-testing

I think I'll be able to manually install the driver, not sure how I can run the tests yet though.

The Visual Studio debugging team have confirmed the issue, but marked it as "External" as it's a Visual Studio plugin (probably installed by the WDK) that's at fault.

They have passed it on to the appropriate team but we don't have external visibility of what they're doing about it now.  The debugging team did say to follow up with them if I don't hear anything back.

--

Graham Bloice