Re: Addressing the hang on Windows 2012 R2 w/WinPcap

[Daniel Miller <bonsaiviking () gmail com>]

Yang,

Thanks for your quick feedback.

On Mon, Sep 21, 2015 at 3:34 AM, 食肉大灰兔V5 <hsluoyz () gmail com> wrote:

> Hi Dan,
>
> From my perspective, WinPcap's binding adapters is designed to be
> reentrant, as no shared variables are used. And the NdisOpenAdapter
> function called by WinPcap should be reentrant too according to MSDN:
> https://msdn.microsoft.com/en-us/library/ee481122.aspx. So it's hard to
> see what happens, more details are needed to clarify this, e.g. at which
> source code line this hang happens, or how to reproduce this issue.

Yes, the difficulty was that I could not reproduce it myself on Windows
8.1. I could find no good reason why this was causing problems, so I view
the patch as a temporary workaround.


> The global mutex workaround can't address the hang occurs between two
> different applications-- as they can't share the named mutex.
In one user's testing, only multiple Nmap processes caused the hang;
Wireshark could be run concurrently with Nmap with no problem. This may be
because Nmap opens and closes the adapter many more times than Wireshark in
a typical execution. In any case, the chance of a hang would be greatly
reduced by Nmap managing its own accesses.


> WinPcap's adapter binding happens whenever packet.dll's PacketOpenAdapter
> is called, however this behavior has been changed in Vista and later (NDIS
> 6). That is adapters can be only bound once for all at the driver's loading
> moment. Although Windows provides shims for NDIS 5 legacy compatibility,
> this old driver model has already been marked as deprecated for quite a
> time. So you can try Npcap 0.05 to see what happens. Latest installer can
> be found at:
> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.05.exe.

If I were able to reproduce the hang, this would have been the first thing
I would have tried. I would not be surprised in the least if Npcap (or any
other redevelopment of WinPcap that changes the driver) would not have the
same problem. Hopefully we will be able to experiment with removing this
ugly workaround once we have settled on a next-generation WinPcap
replacement for Nmap.

Dan

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/