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 <g...@alum.mit.edu> wrote: > > On Aug 18, 2015, at 9:50 PM, Yang Luo <hslu...@gmail.com> 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@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
