Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
TomisderMeister opened this issue May 24, 2020 · 42 comments
Closed

Comments

@TomisderMeister
Copy link

@TomisderMeister TomisderMeister commented May 24, 2020

Hello everyone,
I faced a problem regarding a missing/inaccessible adapter with Wireshark/Scapy created by Wireguard.
nmap --iflist returning:
DeviceBug
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
Copy link

@guyharris guyharris commented Jul 11, 2020

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
Copy link

@per-allansson per-allansson commented Jul 15, 2020

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
Copy link

@guyharris guyharris commented Jul 15, 2020

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
Copy link

@per-allansson per-allansson commented Jul 15, 2020

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
Copy link

@guyharris guyharris commented Jul 15, 2020

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
Copy link

@per-allansson per-allansson commented Jul 15, 2020

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

@guyharris
Copy link

@guyharris guyharris commented Jul 15, 2020

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
Copy link

@per-allansson per-allansson commented Jul 15, 2020

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
Copy link

@per-allansson per-allansson commented Jul 15, 2020

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
Copy link

@timg11 timg11 commented Aug 1, 2020

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
Copy link

@per-allansson per-allansson commented Sep 8, 2020

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
Copy link

@fghzxm fghzxm commented Nov 15, 2020

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
Copy link

@zx2c4 zx2c4 commented Nov 18, 2020

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
Copy link

@stvitaly stvitaly commented Nov 19, 2020

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
Copy link

@zx2c4 zx2c4 commented Nov 19, 2020

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
Copy link

@stvitaly stvitaly commented Nov 19, 2020

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
Copy link

@zx2c4 zx2c4 commented Nov 19, 2020

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
Copy link

@stvitaly stvitaly commented Dec 25, 2020

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
Copy link

@zx2c4 zx2c4 commented Dec 25, 2020

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
Copy link

@stvitaly stvitaly commented Jan 31, 2021

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
Copy link

@zx2c4 zx2c4 commented Jan 31, 2021

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

@dovholuknf
Copy link

@dovholuknf dovholuknf commented Mar 18, 2021

@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
Copy link
Member

@fyodor fyodor commented Apr 29, 2021

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.

dmiller-nmap pushed a commit that referenced this issue May 13, 2021
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
Copy link

@dovholuknf dovholuknf commented Jun 8, 2021

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
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Jun 8, 2021

@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

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
Copy link

@dovholuknf dovholuknf commented Jun 22, 2021

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
Copy link
Member

@fyodor fyodor commented Jun 23, 2021

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

-Gordon

@fghzxm
Copy link

@fghzxm fghzxm commented Jun 23, 2021

@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?

wintun

@guyharris
Copy link

@guyharris guyharris commented Jun 23, 2021

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.

fghzxm added a commit to fghzxm/libpcap that referenced this issue Jun 23, 2021
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
Copy link

@guyharris guyharris commented Jun 23, 2021

@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
Copy link

@guyharris guyharris commented Jun 23, 2021

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
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Jun 23, 2021

@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
Copy link

@guyharris guyharris commented Jun 23, 2021

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
Copy link

@dovholuknf dovholuknf commented Jun 25, 2021

@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 !

fghzxm added a commit to fghzxm/libpcap that referenced this issue Jun 26, 2021
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>
guyharris added a commit to the-tcpdump-group/libpcap that referenced this issue Jun 26, 2021
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
Copy link

@per-allansson per-allansson commented Aug 9, 2021

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
Copy link

@DentonGentry DentonGentry commented Aug 27, 2021

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
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Aug 30, 2021

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
Copy link

@kaplun kaplun commented Aug 31, 2021

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
Copy link

@per-allansson per-allansson commented Sep 3, 2021

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
Copy link

@per-allansson per-allansson commented Sep 4, 2021

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

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Sep 9, 2021

Fixed in Npcap 1.55 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet