mirror of
https://github.com/nmap/nmap.git
synced 2026-02-15 01:46:35 +00:00
bc132b963c
DLT_LINUX_SLL, as well as the DLT_EN10MB that was formerly supported. This type is used on some interfaces where Linux doesn't reliably retain the link-layer header, and when capturing on the "any" device. On such interfaces, you would get the error read_arp_reply_pcap called on interfaces that is datatype 113 rather than DLT_EN10MB (1) For more on this datalink type, see pcap-linktype(7) http://wiki.wireshark.org/SLL I tested this by hacking scan_engine.cc to use the "any" device: --- scan_engine.cc (revision 16972) +++ scan_engine.cc (working copy) @@ -4882,7 +4882,7 @@ } } - USI->pd = my_pcap_open_live(Targets[0]->deviceName(), 100, (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2); + USI->pd = my_pcap_open_live("any" /*Targets[0]->deviceName()*/, 100, (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2); if (USI->ping_scan_arp){ /* Some OSs including Windows 7 and Solaris 10 have been seen to send their ARP replies to the broadcast address, not to the (unicast) address that I had to use a newer version of libpcap from git. The 1.0.0 that we ship has a bug that keeps "any" from working. You would get SIOCGIFHWADDR: No such device.
Here is some documentation for Nmap, but these files are much less comprehensive than what you'll find at the actual Nmap documentation site ( http://nmap.org ).