2015-08-22 7:55 GMT+02:00 Yang Luo <hslu...@gmail.com>: > 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 <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 >
___________________________________________________________________________ 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
