NMap iflist returns WINDEVICE <None> for a Virtual Wireguard Interface #173

TomisderMeister · 2020-05-24T14:02:56Z

Hello everyone,
I faced a problem regarding a missing/inaccessible adapter with Wireshark/Scapy created by Wireguard.
nmap --iflist returning:

eth0 is the Virtual Adapter from Wireguard. The adapter working correctly, but I am unable to sniff data with npcap/scapy/Wirteshark.
NMap -> 7.80
Scapy -> 2.4.3
Wireshark -> 3.2.4
Wireguard -> 0.1.0
NPcap -> 0.9991

Diag Report:
DiagReport-20200524-155041.txt

I tried mutliple releases and the bug is reproducable on a second device.
I would be really glad if you could help regarding this problem.

guyharris · 2020-07-11T08:38:59Z

So the only occurrences of "WireGuard" in the Diag Report are in:

*************************************************
Network Adapter(s) Info:
*************************************************

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
Ethernet                  Realtek PCIe GbE Family Controller           14 Up           50-46-5D-8D-83-71         1 Gbps
TobiTunnel                WireGuard Tunnel                              7 Up                                   100 Gbps

Caption         : [00000002] Realtek PCIe GbE Family Controller
GUID            : {98D2E49D-710A-48FF-ABDC-89BA36048B9F} = eth1
Index           : 2
InterfaceIndex  : 14
Manufacturer    : Realtek
NetConnectionID : Ethernet
PNPDeviceID     : PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09\4&21A1C3AE&0&00E5

Caption         : [00000012] Wintun Userspace Tunnel
GUID            : {3B758425-0C12-5B9B-708D-C6F0A39B222C}
Index           : 12
InterfaceIndex  : 7
Manufacturer    : WireGuard LLC
NetConnectionID : TobiTunnel
PNPDeviceID     : ROOT\NET\0000

Can you try to capture with TShark (tshark.exe should be in the same directory as Wireshark.exe), passing it the command-line argument -i \Device\NPF_{3B758425-0C12-5B9B-708D-C6F0A39B222C} ?

What does the command ipconfig/all print?

per-allansson · 2020-07-15T08:35:20Z

I have the same problem, attached info.

C:\Program Files\Wireshark>tshark.exe -i \Device\NPF_{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
Capturing on '\Device\NPF_{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}'
tshark: The capture session could not be initiated on interface '\Device\NPF_{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}' (No such device exists).
Please check that you have the proper interface or pipe specified.

DiagReport-20200715-102840.txt
ipconfig.txt

guyharris · 2020-07-15T08:44:20Z

The device in question appears in the DiagReport:

Caption             : [00000000] Wintun Userspace Tunnel
GUID                : {3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
Index               : 0
InterfaceIndex      : 6
Manufacturer        : WireGuard LLC
MACAddress          : 
Speed               : 100000000000
NetConnectionID     : AppGateSDP
NetConnectionStatus : 2
PNPDeviceID         : ROOT\NET\0000
ServiceName         : wintun
AdapterType         :

but does not appear in the ipconfig/all output.

The Hyper-V virtual adapter appears in both:

Caption             : [00000003] Hyper-V Virtual Ethernet Adapter
GUID                : {1ED37246-AA38-47E3-9D32-8D89AD4D054E}
Index               : 3
InterfaceIndex      : 29
Manufacturer        : Microsoft
MACAddress          : 00:15:5D:BB:38:A1
Speed               : 10000000000
NetConnectionID     : vEthernet (Default Switch)
NetConnectionStatus : 2
PNPDeviceID         : ROOT\VMS_MP\0000
ServiceName         : VMSNPXYMP
AdapterType         : Ethernet 802.3

and

Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-15-5D-BB-38-A1
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::7547:886:90f6:53c6%29(Preferred) 
   IPv4 Address. . . . . . . . . . . : 172.19.128.1(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . : 
   DHCPv6 IAID . . . . . . . . . . . : 486544733
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-62-76-D9-90-1B-0E-4E-3B-EF
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

per-allansson · 2020-07-15T08:47:20Z

Well I change the description in my code when setting up the device, so the device you are looking for is the one with in diag txt "NetConnectionID : AppGateSDP" - which matches the "Unknown adapter AppGateSDP" in ipconfig. Apart from that description change the setup code is the same that the normal Wireguard client uses.

guyharris · 2020-07-15T08:52:18Z

Well I change the description in my code when setting up the device, so the device you are looking for is the one with in diag txt "NetConnectionID : AppGateSDP"

Yes. that's the entry I mentioned.

which matches the "Unknown adapter AppGateSDP" in ipconfig. Apart from that description change the setup code is the same that the normal Wireguard client uses.

OK, so that's

Unknown adapter AppGateSDP:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : AppGate SDP VPN Tunnel
   Physical Address. . . . . . . . . : 
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fd00:ffff:b:20::714(Preferred) 
   IPv4 Address. . . . . . . . . . . : 192.168.100.172(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 
   DNS Servers . . . . . . . . . . . : 172.17.40.65
                                       172.17.40.66
                                       172.17.40.9
  NetBIOS over Tcpip. . . . . . . . : Enabled

So what's the difference between the two?

per-allansson · 2020-07-15T08:55:27Z

Sorry don't follow - difference between the two what?

guyharris · 2020-07-15T09:08:44Z

The difference between the AppGate SDP VPN Tunnel/Wintun Userspace Tunnel device and the Hyper-V Virtual Ethernet Adapter device.

If capturing on the latter doesn't work, there may not be a difference. If capturing on the latter does work, then the first one gets ERROR_BAD_UNIT back from an attempt to open it, the second one doesn't, so why?

That means that either:

PacketFindAdInfo() returns NULL for the device;
the Flags field of what PacketFindAdInfo() found has a bogus type (either not an NPF device or has the "not exported" flag set.

"Not exported" appears to happen only for FireWire devices, which the device almost certainly isn't. Perhaps there is no entry for it in the Registry, or the open attempt on it failed for some reason while constructing the list of devices?

per-allansson · 2020-07-15T09:12:08Z

Ah. Capturing on the the Hyper-V Virtual Ethernet Adapter is fine, at least wireshark/tshark/etc finds and connects fine to it.

Yeah, so maybe there is something funny going on in how the Wintun device gets registered / set up - that's more than I know - I only reuse the WG code for setting it up.

per-allansson · 2020-07-15T09:16:39Z

These are the logs for testing directly with the official WireGuard client - I attached the WG profile I used as well (dummy keys ofc) - you could test this by yourself by just installing the WireGuard client and giving it that profile and activate it - there is no need for an actual WG server - the Wintun device gets set up anyway.

You can find the WG client here: https://www.wireguard.com/install/

tshark.txt
DiagReport-20200715-110019.txt
ipconfig.txt
W10.conf.txt

timg11 · 2020-08-01T14:49:47Z

I have a similar issue on Windows 10.
nmap --iflist and Wireshark using npcap 0.9995 are unable to detect the Wireguard interface created by Mozilla VPN.
I posted details on Stackoverflow

DiagReport-20200801-093901.txt

per-allansson · 2020-09-08T16:17:03Z

So I started to see if I could figure out something more and found the iflist example in the npcap source code - it also fails to list the Wintun Virtual NIC as expected, but together with a debug version of packet.lib/dll I could at least get out some more logs that might shed some more light for those more familiar with the inner workings of npcap.

So the diagreport on this machine shows the Wintun NIC nic:

Caption             : [00000013] Wintun Userspace Tunnel
GUID                : {3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
Index               : 13
InterfaceIndex      : 9
Manufacturer        : WireGuard LLC
MACAddress          : 
Speed               : 100000000000
NetConnectionID     : AppgateSDP
NetConnectionStatus : 2
PNPDeviceID         : ROOT\NET\0000
ServiceName         : wintun
AdapterType         :

while the Packet.log shows this when it tries to grab hold of the device npcap path thing:

[00005D88] 2020-09-08 18:03:29     14) Successfully retrieved info for adapter \Device\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}, trying to add it to the global list...
[00005D88] 2020-09-08 18:03:29 --> PacketAddAdapterNPF
[00005D88] 2020-09-08 18:03:29     Trying to add adapter \Device\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
[00005D88] 2020-09-08 18:03:29     Trying to open the NPF adapter and see if it's available...
[00005D88] 2020-09-08 18:03:29 --> PacketOpenAdapterNPF
[00005D88] 2020-09-08 18:03:29     Trying to open adapter \Device\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
[00005D88] 2020-09-08 18:03:29 --> PacketStartService
[00005D88] 2020-09-08 18:03:29     PacketStartService: Already tried once.
[00005D88] 2020-09-08 18:03:29 <-- PacketStartService
[00005D88] 2020-09-08 18:03:29 --> NpcapIsAdminOnlyMode
[00005D88] 2020-09-08 18:03:29 <-- NpcapIsAdminOnlyMode
[00005D88] 2020-09-08 18:03:29     SymbolicLinkA = \\.\Global\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}, lpAdapter->hFile = ffffffff
[00005D88] 2020-09-08 18:03:29     PacketOpenAdapterNPF: CreateFile failed, LastError= 8034002b
[00005D88] 2020-09-08 18:03:29 <-- PacketOpenAdapterNPF
[00005D88] 2020-09-08 18:03:29     NPF Adapter not available, do not add it to the global list
[00005D88] 2020-09-08 18:03:29 <-- PacketAddAdapterNPF
[00005D88] 2020-09-08 18:03:29 --> IsFireWire
[00005D88] 2020-09-08 18:03:29 <-- IsFireWire

The adapter properties for the Wintun adapter does show the "Npcap Packet Driver (NPCAP)" and "Npcap Packet Driver (NPCAP) (Wi-Fi)" as enabled.

Using npcap 0.9997 - and the debug build of packet.lib/dll built from latest git sources when running the iflist.exe

fghzxm · 2020-11-15T10:24:25Z

Is there any easy way we can talk to the WireGuard people about this problem? They don't use GitHub issues, and the WireGuard mailing list doesn't look particularly hospitable.

zx2c4 · 2020-11-18T14:21:47Z

Hi, Wintun developer here. I noticed the same issue a few weeks ago actually. I assume that npcap only binds to ethernet interfaces and doesn't know about layer 3 interfaces on Windows. Wintun uses these specification in its inf:

Characteristics = 0x1 ; NCF_VIRTUAL
*IfType = 53 ; IF_TYPE_PROP_VIRTUAL
*MediaType = 19 ; NdisMediumIP
*PhysicalMediaType = 0 ; NdisPhysicalMediumUnspecified

I assume that npcap doesn't know about either IF_TYPE_PROP_VIRTUAL or NdisMediumIP or both.

Looking at npcap's inf, we see this:

HKR, Ndi\Interfaces,UpperRange, , noupper
HKR, Ndi\Interfaces,LowerRange, , "ndis5,ndis4"
HKR, Ndi\Interfaces, FilterMediaTypes,,"ethernet, fddi, wan, ppip, wlan, bluetooth, ndis5, vwifi, flpp4, flpp6, vchannel, nolower"

This suggests that it's left out whatever is needed to match on Wintun. I don't know if NdisMediumIP corresponds to adding , ip to that list, or some other string.

stvitaly · 2020-11-19T14:13:58Z

Now when WinTun is a part of OpenVPN 2.5 installation this became much more important to support WinTun in npcap.
Is there any intention to change something here or in WinTun in the near future, so this pair would work?

zx2c4 · 2020-11-19T14:45:53Z

to change something here or in WinTun in the near future, so this pair would work

This appears to be a npcap issue, rather than a Wintun one.

stvitaly · 2020-11-19T15:15:46Z

I have another virtual adapter on the system with the below properties in the .inf:

Characteristics = 0x1 ; NCF_VIRTUAL (0x1) ; NCF_NOT_USER_REMOVEABLE (0x20); NCF_HIDDEN (0x8); NCF_HAS_UI (0x80)
*IfType = 0x6 ; IF_TYPE_ETHERNET_CSMACD
*MediaType = 0x0 ; NdisMedium802_3
*PhysicalMediaType = 14 ; NdisPhysicalMedium802_3

Which is detected just fine. If the problem was with filtering of MediaType as you suggest above, I suppose it was excluded as well. So, IfType seems to be more relevant.
BTW as I said this interface is virtual as well, but it still present itself as ethernet one and I can see MAC in ipconfig and captures on it.
Is this specific to WinTun to omit any layer2 detail?

zx2c4 · 2020-11-19T15:17:49Z

NCF_VIRTUAL != IF_TYPE_PROP_VIRTUAL. That adapter is Ethernet+802.3, so of course it's covered by npcap.

The issue with wintun concerns IF_TYPE_PROP_VIRTUAL+NdisMediumIP.

stvitaly · 2020-12-25T14:30:52Z

Bumping.
@fghzxm I would really appreciate if you could take a look.
You have a wintun developer in the thread here (@zx2c4) as you asked.

zx2c4 · 2020-12-25T14:42:16Z

the WireGuard mailing list doesn't look particularly hospitable.

@fghzxm It's actually a pretty hospitable place, so if you'd like to discuss there instead of here, that's fine too.

Either way, I remain at your disposal for helping to fix this.

stvitaly · 2021-01-31T13:45:10Z

the WireGuard mailing list doesn't look particularly hospitable.

@fghzxm It's actually a pretty hospitable place, so if you'd like to discuss there instead of here, that's fine too.

Either way, I remain at your disposal for helping to fix this.

@zx2c4 I have tried to join it twice through wintun site, didn't get any reply.
I got a message that joining should be approved by list admin, maybe your admin stopped to approve people joining.

zx2c4 · 2021-01-31T13:47:48Z

I don't see anything from you, in the spam box or otherwise.

dovholuknf · 2021-03-18T00:11:38Z

@zx2c4 I had that same issue recently and you fixed it for me somehow so that i was subbed to the mailing list. I'm following this thread with interest as we use wintun as well

fyodor · 2021-04-29T18:25:33Z

Thanks folks. I was talking to @dmiller-nmap about this issue and he noted that Npcap currently doesn't bind to NdisMediumIP virtual adapters. We specifically check for a set of known values when a binding request comes in, and reject it if it's not known. NdisMediumIP is not in the list. So it is possible that all we need to do is add this to the list (or even remove the list checking). It may not really matter what the value is, since we don't create layer-2 headers within the driver anyway. As long as we can map the value to something that a user can understand via Packet.dll -> libpcap, we should probably allow the bind to continue. Of course, once we allow the binding, it's possible there's something we've overlooked and it ends up interfering with the connection.

So we will probably make this new change for the next release and then hopefully you folks who have experienced the issue can test whether this resolves it. Or maybe we can test with Wireguard/Wintun ourselves. The next release will probably be sometime in May since we're currently in the middle of WHQL (Windows Hardware Qualification Labs) certification process which involves setting up a bunch of new hardware, virtual machines, testing, etc. We're hoping to make a new release after that.

We don't really use these in the driver. Kernel Dump mode used to do so, but that's not supported. We have probably been missing adapters we could support otherwise, e.g. #173

dovholuknf · 2021-06-08T19:53:25Z

I see npcap 1.31 was released, i see the commit was pushed but I don't quite know how to verify if this fix is in 1.31 or not.

So we will probably make this new change for the next release and then hopefully you folks who have experienced the issue can test whether this resolves it.

I am happy to try to test this in some way. Is there a preferred mechanism you'd like to test? When I run:

nmap -v -A 100.64.0.0/10
Starting Nmap 7.90 ( https://nmap.org ) at 2021-06-08 15:50 Eastern Daylight Time
NSE: Loaded 153 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 15:50
Completed NSE at 15:50, 0.00s elapsed
Initiating NSE at 15:50
Completed NSE at 15:50, 0.00s elapsed
Initiating NSE at 15:50
Completed NSE at 15:50, 0.00s elapsed
Initiating ARP Ping Scan at 15:50
dnet: Failed to open device eth1
QUITTING!

I also tried to use a hostname which resolves for me that is assigned to this adapter:

nslookup mattermost.openziti.org
Server:  UnKnown
Address:  100.64.0.1

Name:    mattermost.openziti.org
Address:  100.64.2.46


C:\Program Files\Npcap>nmap -v -A mattermost.openziti.org
Starting Nmap 7.90 ( https://nmap.org ) at 2021-06-08 15:52 Eastern Daylight Time
NSE: Loaded 153 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 15:52
Completed NSE at 15:52, 0.00s elapsed
Initiating NSE at 15:52
Completed NSE at 15:52, 0.00s elapsed
Initiating NSE at 15:52
Completed NSE at 15:52, 0.00s elapsed
pcap_activate(eth1) FAILED: No such device exists.
my_pcap_open_live(eth1, 50, 1, 25) failed three times.

If you can help me with the proper command to use to test - I'm happy to try it out

dmiller-nmap · 2021-06-08T20:36:41Z

@dovholuknf Thanks for offering to test. This change did not make it into 1.31, so we will have to wait for the next release to test it.

4-FLOSS-Free-Libre-Open-Source-Software · 2021-06-21T22:40:43Z

Seems fixed now in latest :)

Npcap 1.40
• Npcap driver no longer excludes adapters based on media type, which may allow
capture on some devices that were previously unavailable.

dovholuknf · 2021-06-22T11:20:20Z

I dl'ed the 1.4 installer yesterday to test it out but it failed to install. I see it's no longer on the download page. I'll be happy to test it out once I can get my hands on it :) and now i see you filed #513 :)

fyodor · 2021-06-23T01:40:38Z

1.50 is out now at https://npcap.org and hopefully resolves the issue. Please let us know how it goes!

-Gordon

fghzxm · 2021-06-23T03:18:31Z

@fyodor Thanks for your work on this issue, and my apologies for my previous judgmental comment.

However, it seems like with the newest version of npcap Wireshark does not correctly identify the packets inside Wintun as IP, instead decoding them as Ethernet. Is it a bug in npcap, Wireshark, or one related to the Wintun project?

guyharris · 2021-06-23T05:37:13Z

However, it seems like with the newest version of npcap Wireshark does not correctly identify the packets inside Wintun as IP

The current version of Npcap doesn't correctly identify NdisMediumIP, which is what the Wintun device provides as its link-layer type, as DLT_RAW, which is the pcap (libpcap, WinPcap, Npcap) way of saying "the packets begin with an IPv4 or IPv6 header...

...and that's the fault of the libpcap code, not of the Npcap code that's combined with the libpcap code to make Npcap, so please file a bug on the libpcap issues list, not on the Npcap issues list.

Wireshark trusts pcap (libpcap/WinPcap/Npcap) to provide the right link-layer type, and libpcap defaults to DLT_EN10MB (meaning Ethernet - the "10MB" is a historical artifact, dating back to the days where there were the Xerox 3Mb experimental Ethernet and the DEC/Intel/Xerox 10Mb standard Ethernet, with all subsequent versions of Ethernet having the same link-layer header) for Windows link-layer types it doesn't understand, so it tells Wireshark that it's Ethernet.

What Wireshark is doing wrong is not reporting the warning that Npcap is returning for that case, and thus not telling you that there's a bug that needs to be reported. That's a separate bug, which I'll work on.

When encountering the NDIS medium type `NdisMediumIP`, treat the interface as an IP interface. Related to nmap/npcap#173. Signed-off-by: fghzxm <fghzxm@outlook.com>

guyharris · 2021-06-23T09:58:52Z

@fghzxm's fix doesn't compile with VS 2015, probably because the Windows SDK that comes with VS 2015 is too old to have NdisMediumIP.

What's the oldest version of VS that can be used to build Npcap? If it's newer than VS 2015, I'll remove them from the AppVeyor CI builds and note that libpcap requires that version or later.

guyharris · 2021-06-23T10:00:34Z

What Wireshark is doing wrong is not reporting the warning that Npcap is returning for that case, and thus not telling you that there's a bug that needs to be reported. That's a separate bug, which I'll work on.

I've checked that in, although, on most platforms, the capture mechanism providing an unknown link-layer type should probably be a fatal error. Linux is the only platform where it's not, because we can do the capture in "cooked mode" with a link type of DLT_LINUX_SLL as a workaround, so, for that, we can issue a warning (so the user knows they're not getting the link-layer header).

dmiller-nmap · 2021-06-23T20:47:12Z

@guyharris I'm not sure what the oldest VS that can be used to build Npcap is. We do use VS 2019 currently. Our primary intent is to be able to build it ourselves, so we don't have any particular requirement to support older build environments. Of course we want to make it easy for others to link with and use Npcap, but the intent is that they would use our builds under license.

guyharris · 2021-06-23T23:48:47Z

OK, I went with doing a check in CMake, so it should still build with pre-8.1 Windows SDKs, albeit without NdisMediumIP support. You can grab change 74be794fe7b3540999149f976e4a829289ad43ef from the main branch or ef0e7b15fe871d79e678a3482b0c5a02171dacfe from the libpcap-1.10 branch; we recently released 1.10.1, so it probably won't show up in a release soon.

dovholuknf · 2021-06-25T11:27:59Z

@dmiller-nmap any expectation setting you can do for when this might be able to incorporated and tested? I'm eager to be able to capture wintun traffic. :) I gave a shot at building locally but hit some compilation bumps and didn't end up getting it working.

Thanks for pushing this issue along everyone !

The NDIS medium type NdisMediumIP transports raw IP packets. If we encounter such an interface, say it's DLT_RAW. Related to nmap/npcap#173. Signed-off-by: fghzxm <fghzxm@outlook.com>

The NDIS medium type NdisMediumIP transports raw IP packets. If we encounter such an interface, say it's DLT_RAW. Related to nmap/npcap#173. Signed-off-by: fghzxm <fghzxm@outlook.com> (cherry picked from commit c1a7c08)

per-allansson · 2021-08-09T18:05:51Z

Putting a comment here since searches about Wireshark + Wintun support eventually end up in this ticket - to get Wireshark working it needs to pull in the fixed npcap build (which it does now I think), but also an updated build of libpcap - which it pulls from vcpkg - and which does not have a recent build of libpcap at the moment. So if anyone want this to happen sooner than later, please make a PR to https://github.com/microsoft/vcpkg to update libpcap to 1.10 - I might try do it when I have caught up on 100 other things that have more prio - but that is likely to qualify as "later".

DentonGentry · 2021-08-27T15:59:29Z

Confirmed that wireshark 3.5.0rc0 includes npcap 1.5.0 and sees the wintun device. There is a popup message "Unknown NdisMedium value 19, defaulting to DLT_EN10MB", and it is trying to decode the IP header bytes as an Ethernet header. (from tailscale/tailscale#1660)

I think we need the NdisMediumIP handling added in https://github.com/the-tcpdump-group/libpcap/blob/728f4339fac6bddb0350e69cb62a862b917ad3e3/pcap-npf.c#L1112 which should be included in libpcap 1.10.2, but 1.10.2 isn't quite out yet.

dmiller-nmap · 2021-08-30T17:37:32Z

Thanks everyone for commenting. We will be using the latest from the head of upstream's libpcap-1.10 branch to ensure this change is incorporated in the next release, even if libpcap 1.10.2 is not yet released.

kaplun · 2021-08-31T08:20:01Z

Hi @DentonGentry , @dmiller-nmap! Is there somewhere an unofficial build of WireShark built as you describe, that could be used in order to support Wintun, while waiting for official releases?

per-allansson · 2021-09-03T15:17:55Z

A very easy workaround is to capture the packets with Wireshark, save them as normal pcap (not pcapng) file, and then change the pcap file header so it says the link format is Raw IP (0x65) and not Ethernet (0x01). Simple python script for this is:

import sys

with open(sys.argv[1], "r+b") as fh:
    fh.seek(20)
    fh.write(bytes([0x65]))

per-allansson · 2021-09-04T07:46:22Z

Thank you @dmiller-nmap, looks good now when capturing from Wireshark

dmiller-nmap · 2021-09-09T17:19:58Z

Fixed in Npcap 1.55 release.

The NDIS medium type NdisMediumIP transports raw IP packets. If we encounter such an interface, say it's DLT_RAW. Related to nmap/npcap#173. Signed-off-by: fghzxm <fghzxm@outlook.com>

DentonGentry mentioned this issue Apr 6, 2021

Contribute support for WinTun in wireshark/npcap tailscale/tailscale#1660

Closed

dmiller-nmap pushed a commit that referenced this issue May 13, 2021

Don't be picky about media types

14b9b02

We don't really use these in the driver. Kernel Dump mode used to do so, but that's not supported. We have probably been missing adapters we could support otherwise, e.g. #173

fghzxm added a commit to fghzxm/libpcap that referenced this issue Jun 23, 2021

pcap-npf.c: handle NdisMediumIP

1281e9a

When encountering the NDIS medium type `NdisMediumIP`, treat the interface as an IP interface. Related to nmap/npcap#173. Signed-off-by: fghzxm <fghzxm@outlook.com>

fghzxm mentioned this issue Jun 23, 2021

pcap-npf.c: handle NdisMediumIP the-tcpdump-group/libpcap#1027

Merged

dmiller-nmap pushed a commit that referenced this issue Sep 4, 2021

Update libpcap to head of 1.10 branch. See #173

ea92c1e

dmiller-nmap closed this as completed Sep 9, 2021

NMap iflist returns WINDEVICE <None> for a Virtual Wireguard Interface #173

NMap iflist returns WINDEVICE <None> for a Virtual Wireguard Interface #173

Comments

TomisderMeister commented May 24, 2020 • edited Loading

guyharris commented Jul 11, 2020 • edited Loading

per-allansson commented Jul 15, 2020

guyharris commented Jul 15, 2020

per-allansson commented Jul 15, 2020 • edited Loading

guyharris commented Jul 15, 2020

per-allansson commented Jul 15, 2020

guyharris commented Jul 15, 2020

per-allansson commented Jul 15, 2020

per-allansson commented Jul 15, 2020 • edited Loading

timg11 commented Aug 1, 2020

per-allansson commented Sep 8, 2020 • edited Loading

fghzxm commented Nov 15, 2020

zx2c4 commented Nov 18, 2020

stvitaly commented Nov 19, 2020

zx2c4 commented Nov 19, 2020

stvitaly commented Nov 19, 2020

zx2c4 commented Nov 19, 2020

stvitaly commented Dec 25, 2020 • edited Loading

zx2c4 commented Dec 25, 2020

stvitaly commented Jan 31, 2021

zx2c4 commented Jan 31, 2021

dovholuknf commented Mar 18, 2021

fyodor commented Apr 29, 2021

dovholuknf commented Jun 8, 2021 • edited Loading

dmiller-nmap commented Jun 8, 2021

4-FLOSS-Free-Libre-Open-Source-Software commented Jun 21, 2021

dovholuknf commented Jun 22, 2021 • edited Loading

fyodor commented Jun 23, 2021

fghzxm commented Jun 23, 2021 • edited Loading

guyharris commented Jun 23, 2021 • edited Loading

guyharris commented Jun 23, 2021

guyharris commented Jun 23, 2021

dmiller-nmap commented Jun 23, 2021

guyharris commented Jun 23, 2021

dovholuknf commented Jun 25, 2021

per-allansson commented Aug 9, 2021

DentonGentry commented Aug 27, 2021

dmiller-nmap commented Aug 30, 2021

kaplun commented Aug 31, 2021 • edited Loading

per-allansson commented Sep 3, 2021

per-allansson commented Sep 4, 2021 • edited Loading

dmiller-nmap commented Sep 9, 2021

TomisderMeister commented May 24, 2020 •

edited

Loading

guyharris commented Jul 11, 2020 •

edited

Loading

per-allansson commented Jul 15, 2020 •

edited

Loading

per-allansson commented Jul 15, 2020 •

edited

Loading

per-allansson commented Sep 8, 2020 •

edited

Loading

stvitaly commented Dec 25, 2020 •

edited

Loading

dovholuknf commented Jun 8, 2021 •

edited

Loading

dovholuknf commented Jun 22, 2021 •

edited

Loading

fghzxm commented Jun 23, 2021 •

edited

Loading

guyharris commented Jun 23, 2021 •

edited

Loading

kaplun commented Aug 31, 2021 •

edited

Loading

per-allansson commented Sep 4, 2021 •

edited

Loading