Wireshark · Wireshark-dev: Re: [Wireshark-dev] Npcap 0.04 call for test

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi,

This issue has been added to list at: https://github.com/nmap/nmap/issues/200. Windows is slightly different for this thing, because Npcap Loopback Adapter is actually based on "Microsoft KM-TEST Loopback Adapter" and Windows makes "Microsoft KM-TEST Loopback Adapter" an Ethernet adapter, it has a MAC address and MTU is 1500 (can be seen in Wireshark and Nmap). Before the DLT_NULL/DLT_LOOP change, the MAC address should be removed first, the MTU should be modified to an apropriate value, like 65535. It's weird to have a pure loopback interface with MAC address. 

It seems that most softwares can handle DLT_NULL/DLT_LOOP for the captured data. So I think "02 00 00 00" for IPv4 and "23 00 00 00" for IPv6 are enough, right? This can be handled by Npcap. Then how about the sending side? I think Nmap just constructs a packet from Ethernet header before sending it. How to make Nmap construct a DLT_NULL/DLT_LOOP header instead of an Ethernet header?

Cheers,

Yang

On Wed, Aug 19, 2015 at 2:33 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Aug 18, 2015, at 9:50 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> Current fake Ethernet encapsulation of Npcap refers to the Linux implementation (actually is Ubuntu, as I am only familiar with it for a Linux system). I don't own a OS X computer now so I can't test or use it. One question is is NULL/Loopback encapsulation a widespread protocol standard like Ethernet?

DLT_NULL is not a published standard, but it's used for loopback devices on

        1) the most common desktop UNIX (no, it's not anything Linux-based, it's BSD-flavored)

and

        2) the second most common smartphone/tablet UN*X

as well as on FreeBSD, NetBSD, and DragonFly BSD.  DLT_LOOP is used on OpenBSD.

A program that can't handle DLT_NULL or DLT_LOOP *cannot* handle loopback device captures from any of those OSes.

> Also What I am worried about is that is NULL/Loopback encapsulation type compatible with other softwares? Like Nmap, NetScanTools, etc. I don't know if they have a smart dissector like packet-null.c in Wireshark to tell it's a loopback packet coming.

There's nothing "smart" needed - Wireshark's just working around some screwups in some OSes that mistakenly use DLT_NULL for things that didn't have a DLT_NULL link-layer header.  All a program needs to do is catch DLT_NULL and DLT_LOOP, fetch the 4-byte header, and compare it against 2 for IPv4 and against various values for IPv6.

Tcpdump had support for it before Wireshark even *existed*, even under the name Ethereal.  Look at null_if_print() in print-null.c in the tcpdump source - it doesn't bother with the "smart" stuff.

Nmap handles it, except for libnetutil/netutil.cc, which doesn't handle *anything* other than DLT_EN10MB and DLT_LINUX_SLL - that code can't handle PPP on anything other than Linux (and that only because Linux doesn't, or at least didn't, bother to supply a useful link-layer header for PPP, so libpcap falls back on cooked mode so it can get *some* packet information).

NetScanTools - unknown, but, as they're Windows-only and use WinPcap, they might not bother handling DLT_NULL/DLT_LOOP, as WinPcap hasn't supplied them.  The "Packet Capture Tool" can save a pcap file and presumably can read a saved file:

        http://www.netscantools.com/nstpro_packet_capture.html

"Saving the capture or a specific packet is fully supported and you can reload a capture later for future analysis."

but if all they support is reading files saved from the "Packet Capture Tool", they might not support any DLT_/LINKTYPE_ values that you don't get from WinPcap.

> Moreover, I found a link: https://ask.wireshark.org/questions/7849/null-loopback-link-encapsulation-conversion. It seems that some softwares did have problem with NULL/Loopback encapsulation,

Yeah, another tool that didn't bother with DLT_NULL/DLT_LOOP.  Perhaps Riverbed fixed that after buying OpNet.

> so could you tell me the advantages of this method except saving 10 bytes (Ethernet is 14 bytes without the checksum)?

Not confusing people into thinking that they have an Ethernet capture with meaningful source and destination addresses in the capture?

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe