Wireshark · Wireshark-dev: Re: [Wireshark-dev] Npcap 0.01 call for test about Windows loopback traffic capture feature

[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

2015-07-15 16:30 GMT+02:00 Pascal Quantin <pascal.quantin@xxxxxxxxx>:

Le 15 juil. 2015 5:14 AM, "Yang Luo" <hsluoyb@xxxxxxxxx> a écrit :
>
> Hi Pascal,
>
> I am not very familiar about dialup/PPP interfaces, perhaps you mean capturing on adapters like below?
> WAN Miniport (SSTP)
> WAN Miniport (IPv6)
> WAN Miniport (IP)
> WAN Miniport (L2TP)
> WAN Miniport (PPPOE)
> WAN Miniport (PPTP)
> WAN Miniport (Network Monitor)
> WAN Miniport (IKEv2)
>
> These adapters are listed on my machine, theoretically should be able to be opened by Npcap driver.

Hi Yang,

I guess the corresponding miniport should be PPPoE but I cannot verify it as I do not have such device. I was asking just in case as this is a question we have from time to time on http://ask.wireshark.org.

But I do have access to a MBIM (USB class used to control wireless modems starting from Windows 8) which is not listed by WinPcap either (for now I'm using USBPcap to capture the traffic).
According to https://msdn.microsoft.com/en-us/library/windows/hardware/ff557177(v=vs.85).as pu it should be listed as a WWAN (or MB) miniport driver. Do you see such miniport or only the WAN family? Eventually I could give it a try if you can add its support.

Later tonight I will try Nmap on a Windows 8.1 x64 box and see whether I can reproduce the issue reported by Tyson.

Pascal.

>
>
>
> Cheers,
> Yang
>
>
> On Wed, Jul 15, 2015 at 3:16 AM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:
>>
>>
>>
>> 2015-07-11 11:15 GMT+02:00 Yang Luo <hsluoyb@xxxxxxxxx>:
>>>
>>> Hi list,
>>>
>>> In order not to diverge with WinPcap interfaces, I have made a "WinPcap Mode" for Npcap, it uses the same system32 directory to put DLLs and has the same "npf" service and driver name. So it can be directly used in Wireshark without any patch. 
>>>
>>> Another news is that I have finished Windows loopback packet capture feature in Npcap, Npcap will install an adapter named "Npcap Loopback Adapter". And I can see the loopback traffic using Wireshark now (See the attached pic). It seems to still have problems, like the "(no response found!)" in the ICMPv6 packets (ping ::1) in the pic. I don't know why Wireshark shows like this, perhaps you guys can provide me a clue.
>>>
>>> The latest Npcap installer is:
>>> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.01.exe
>>>
>>> I have tested this version Npcap under Wireshark 1.12.6 x64, in Windows 8.1 x64 and Windows Server 2016 TP2.
>>>
>>> Notice: You need to try it under Win7 and later, and no need to change the installation options, just click the "Next"s. Npcap installed in "WinPcap Mode" is exclusive with WinPcap, so you must uninstall WinPcap first (installer will prompt you this).
>>>
>>> The README is:
>>> https://github.com/nmap/npcap
>>>
>>> The implementation internal about loopback traffic feature is:
>>> http://seclists.org/nmap-dev/2015/q3/35
>>>
>>>
>>> Cheers,
>>> Yang
>>
>>
>> Hi Yang,
>>
>> I just gave a quick try to Npcap 0.0.1 on my Windows 7 x64 box and it seems to work pretty well. Congratulations and thanks for your work!
>> Any chance to add support for dialup / PPP interfaces? This is one of the WinPcap feature that got lost when transitioning from Windows XP to Vista (http://www.winpcap.org/misc/faq.htm#Q-5).
>>
>> Regards,
>> Pascal.
>>

I just tested Npcap in WinPcap compatibility mode on my Windows 8.1 x64 box, on top a Windows 7 x64 and Windows 10 x64 virtual machines and have consistent results:

- if I uninstall WinPcap 4.1.3 and install Npcap without rebooting, everything works fine and I capture on my Wifi interface (or Ethernet interface for the virtual machines) at the same time as the loopback interface without any issue (no BSOD)

- on Windows 10, the loopback interface is named 'Ethernet 2' instead of 'Npcap Loopback Adapter'

- as soon as I reboot, npf service cannot launch anymore and I need to remove Npcap, reinstall Winpcap and reboot. I did not notice this yesterday as I did not reboot. I do have the packet.dll and wpcap.dll files in windows\system32 folder, and npf.sys in windows\system32\drivers folder coming from your isntaller

- I noticed that packet.dll and wpcap.dll are signed but not timestamped (and still using SHA1). I do not know whether it matters or not.

Pascal.