[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

2015-08-22 7:55 GMT+02:00 Yang Luo <hsluoyb@xxxxxxxxx>:

Hi list,

Npcap 0.04 r5 has added the DLT_NULL protocol support, you need to check the "Use DLT_NULL protocol as loopback packets' link layer instead of Ethernet II" option when installing (default is not checked). The problem is Wireshark didn't recognize these loopback packets correctly, I think Windows is little-endian system, so "02 00 00 00" protocol header should be right. Hope any helpful answers.

Latest install is at:

https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r5.exe

Hi Yang,

DLT_NULL does not work as expected because Npcap is still providing a linktype of type Ethernet instead of Null. I was able to fix the encapsulation of a captue by running editcap -T null dlt_null.pcapng dlt_null_fixed.pcapng.

Another issue is that value 23 is not interpreted as IPv6 for Windows, but as Netware IPX/SPX. Should we "steal" the value of another system? For now the NULL dissector supports IPv6 codes for BSD (24), FreeBSD (28) and OS X (30). Guy, what do you think?

Cheers,

Pascal.

On Thu, Aug 20, 2015 at 2:17 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

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

___________________________________________________________________________
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