Thanks for bringing this up. We generally handle these by adding the appropriate hardware address type constant to libdnet, but I was inspired by your patch to make a likely-permanent fix. In r35782 of Nmap's development trunk, I added a patch to treat unsupported address types as ADDR_TYPE_NONE. Nmap will still list these as "ethernet" interfaces, but they should work just fine if you use the --send-ip option to avoid doing things like sending standard ARP messages (IEEE1394 network interfaces use a different ARP format). If we don't see any problems in testing, this patch will be included in the next feature release.
Dan P.S. This is easily reproducible on hardware with an IEEE1394 port by running: sudo modprobe firewire-net && nmap --iflist Quoting from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821913 : > Package: nmap > Version: 7.01-2 > Severity: important > > (renders package unusable, but only for an unlucky minority of users) > > Hi, > > my system configuration includes a firewire network device, so nmap fails to > find any interface whatsoever: > > ===== > root@inti:/tmp# nmap --iflist -d3 > > Starting Nmap 7.01 ( https://nmap.org ) at 2016-04-20 13:49 CEST > Fetchfile found /usr/bin/../share/nmap/nmap-services > PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0) > INTERFACES: NONE FOUND(!) > Reason: getinterfaces_dnet: intf_loop() failed > ROUTES: NONE FOUND(!) > Reason: getsysroutes_dnet: sysroutes_dnet_find_interfaces() failed > ===== > > (Low-level reason if of interest: addr_ston() has a switch{} on supported > sa_family types, and that firewire interface comes in as (ignore the members > after sin_family, interpretation as sockaddr_in is obviously misleading) > > ===== > Breakpoint 1, 0x00000000004d8bb0 in addr_ston () > (gdb) p/x *(struct sockaddr_in *)$rdi > $9 = {sin_family = 0x18, sin_port = 0xdef0, sin_addr = {s_addr = 0x636cfff1}, > sin_zero = {0x40, 0xff, 0xa, 0x2, 0x0, 0x1, 0x0, 0x0}} > ===== > > for which (0x18 == ARPHRD_IEEE1394) there's no case.) > > There have been occurrences of this behaviour before[1][2], and it's > ridiculous. The implementation of libdnet's _intf_loop() relies on every > single _intf_get_noalias() and _intf_get_aliases() call to succeed, which > means that if a single address interpretation through addr_ston() fails, the > whole scan comes up empty. > > Instead the scan should just ignore unenumerable interfaces and report the > others - that way new link types don't break libdnet (and thus nmap) for > everybody who happens to have such interfaces. > > A patch might look like this[att1]. With that applied, nmap --iflist shows > the desired list of interfaces (except for firewire0, as expected) again. > > > Thanks! > > Jan > > [1]: http://seclists.org/nmap-dev/2012/q3/997 > [2]: http://seclists.org/nmap-dev/2012/q2/478 > -- > Jan Nordholz <jnordh...@sec.t-labs.tu-berlin.de> > Security in Telecommunications <fgsect.de> > TU Berlin / Telekom Innovation Laboratories > Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany > phone: +49 30 8353 58663 > >
