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 Cheers, Yang On Thu, Aug 20, 2015 at 2:17 PM, Yang Luo <hslu...@gmail.com> 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 <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
