RE: nmap: do not fail enumerating interfaces if there are unknown link types

[Daniel Miller <dmiller () nmap com>]

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 <jnordholz () 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
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/