Re: Patches to Nmap 5.30BETA1

[David Fifield <david () bamsoftware com>]

On Tue, Apr 06, 2010 at 12:15:21AM -0700, Darren Reed wrote:
> On 04/03/10 13:15, David Fifield wrote:
> > On Sat, Apr 03, 2010 at 12:19:59AM -0700, Darren Reed wrote:
> > > Patches required to build on OpenSolaris with gmake 3.81
> > >
> > > I hope I have fixed all of the cut-n-paste errors.
> > >
> > > The common theme throughout is that our gmake seems to behave a lot   
> > > differently to either the linux one or the makefiles are just broken. 
> > >  Either way, the changes below should work on all platforms.
> >
> > Hmm, can you tell us more about the platform? What version of
> > OpenSolaris (uname)? Are you sure it's gmake 3.81?
>
> /tmp/nmap-5.30BETA1.Solaris# uname -a
> SunOS hostname 5.11 snv_130 i86pc i386 i86pc
> /tmp/nmap-5.30BETA1.Solaris# gmake --version
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> This program built for i386-pc-solaris2.11
>
>
> > The reason I ask is that we had reports of successful builds on
> > OpenSolaris recently, with only a small problem keeping Nping from
> > building.
> >
> > http://seclists.org/nmap-dev/2010/q1/870
>
> That was build 111, which is almost a year old (1 build every 2 weeks
> or thereabouts.)

I started looking into this, and I got snv_134 running.
SunOS opensolaris 5.11 snv_134 i86pc i386 i86pc Solaris
I ran into the same problem you did, which is that libdnet failed trying
to build eth-linux.c.

I'm sure you know this, but I'll write down what I've found for the
benefit of other readers. OpenSolaris now has support for PF_PACKET
sockets and SIOCGIFHWADDR. These weren't present in snv_111, which is
OpenSolaris 2009.06, or the latest live CD version. To upgrade after
installing, follow the instructions at
http://pkg.opensolaris.org/dev/en/index.shtml.

The fact that PF_PACKET sockets are present makes libdnet think it
should compile eth-linux.c, when before it compiled eth-dlpi.c.
eth-linux.c only compiles on Linux at the moment, because it uses
headers like <linux/if_packet.h> and a symbol ETH_P_ALL, which I
couldn't find on OpenSolaris.

The fact that SIOCGIFHWADDR is defined means that
getinterfaces_siocgifconf in tcpip.cc tries to use ioctl(SIOCGIFHWADDR)
to get the interface MAC address. But SIOCGIFHWADDR only works on
PF_PACKET sockets, not PF_INET, which is what the code expects. So
running Nmap, you get the error:
Failed to determine the MAC address of bge0!: Invalid argument (22)
Before, when SIOCGIFHWADDR was not defined, getinterfaces_siocgifconf
used whatever code is in libdnet's route-bsd.c.

We had a report of the SIOCGIFHWADDR problem last year:
http://seclists.org/nmap-dev/2010/q1/684
http://mail.opensolaris.org/pipermail/networking-discuss/2009-December/012910.html
This document describes the addition of PF_PACKET and SIOCGIFHWADDR:
http://arc.opensolaris.org/caselog/PSARC/2009/232/pfp-psarc.txt

In r17402 I made the PF_PACKET Autoconf check more Linux-specific so
that it wouldn't be true for OpenSolaris and eth-dlpi.c would be used
instead. Potentially the code in eth-linux.c could be made more
cross-platform but that will be a bigger undertaking.

The other problem, that of SIOCGIFHWADDR not being supported on PF_INET
sockets, remains. As you suggested, the absolute best solution would be
for this support to be added to OpenSolaris. Alternatively, we have to
add an Autoconf check not only that "SIOCGIFHWADDR is defined" but that
"SIOCGIFHWADDR works on PF_INET sockets." Then we would avoid using it
on OpenSolaris and use the route-bsd.c code instead. Wine added a check
for the member ifreq.ifr_hwaddr.
http://bugs.winehq.org/show_bug.cgi?id=20714
http://bugs2.winehq.org/attachment.cgi?id=26765
I don't think it's the best approach because OpenSolaris could
conceivably add that member and still not support SIOCGIFHWADDR on
PF_INET. Can you suggest a good way to check for this?

> > And things like this:
> >
> > > -       cd $(NSOCKDIR)/src && $(MAKE)
> > > +       cd $(NSOCKDIR)/src && $(MAKE) NBASEDIR=../../nbase
> >
> > should not be necessary with GNU Make, because there's an
> > "export NBASEDIR" earlier in the makefile.
>
> It may be something from my environment that interferes...
>
> But...
>
> In the top level Makefile, there is "export NBASEDIR=nbase", etc.
>
> *My* understanding of Makefile's is that if a variable is already
> present in the current environment then the any setting in the
> Makefile itself is ignored. Otherwise you cannot do "make CC=pcc"
> in a build tree that has subdirectories.

No, it's just the opposite. Settings in the Makefile always override the
environment.
http://www.gnu.org/software/make/manual/html_node/Environment.html
When you do "make CC=pcc", you're not setting the environment variable
CC, you're passing an argument to Make that it knows to parse as a
variable assignment. Assignments of this type *do* override Makefile
assignments.
http://www.gnu.org/software/make/manual/html_node/Overriding.html
Anyway, I didn't need any of this part of the patch for a successful
build.

> > > I know it is bad form to patch "configure" but I don't know any other 
> > >  way to fix the detection of bpf here. The configure script is also 
> > > wrong  for many BSD's because NetBSD, etc, now only have /dev/bpf (a 
> > > cloning  device) and no longer have /dev/bpf0-15.

In this case you should patch config/acinclude.m4 and then run autoconf.
The point about /dev/bpf is good but I've left it alone for now because
it's not yet working on OpenSolaris. Checking for /dev/bpf would make
eth-bsd.c be used in place of eth-dlpi.c, and then we would be in the
same situation as with eth-linux.c.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/