Re: Patches to Nmap 5.30BETA1

[Darren Reed <darren.reed () oracle com>]

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.)

> 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.

So because of the "export NBASEDIR=.." in the root Makefile, all
of the "export NBASEDIR=..." in the other Makefiles is ignored.


> > 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.
> >
> > btw, I think I need to ask for guidance here...
> >
> > OpenSolaris currently supports DLPI, PF_PACKET and BPF. DLPI will "work"
> > as it always has, but it is slow. With PF_PACKET some of the include paths
> > are different to Linux (there is no /usr/include/linux, for example) and
> > at present SIOCGIFHWADDR is only supported on PF_PACKET sockets (libdnet
> > usesSIOCGIFHWADDR on an AF_INET socket. The presence of BPF is taken to
> > indicate that the box is BSD and therefore the sysctl interface is used
> > to get the NIC address. The goal is to end up with nmap using BPF but
> > OpenSolaris isn't going to get sysctl any time soon. The next best
> > alternative seems to be supporting SIOCGIFHWADDR on AF_INET with
> > OpenSolaris and adapting the pcap/bpf part of nmap to use that ioctl
> > if it is present. Thoughts?
>
> How slow is DLPI compared to the alternatives? I'm afraid I don't know
> much about this.

I've measured DLPI to be about 1/3 of the speed of BPF on 10GE
on [Open]Solaris. Or BPF is 3x (or 300%) faster than DLPI.


> As far as I know, SIOCGIFHWADDR is already used (on an AF_INET socket)
> to get the interface list on OpenSolaris (in tcpip.cc). Does that not
> work? What does "nmap --iflist" say?

With some tweaking to get it to use bpf...

# ./nmap --iflist

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-04-05 22:42 PDT
Warning: Unable to get hardware address for interface e1000g0 -- 
skipping it.
Warning: Unable to get hardware address for interface vboxnet0 -- 
skipping it.
************************INTERFACES************************
DEV (SHORT) IP/MASK     TYPE     UP MAC
lo0 (lo0)   127.0.0.1/8 loopback up

WARNING: Unable to find appropriate interface for system route to A.B.C.D
WARNING: Unable to find appropriate interface for system route to A.B.C.E
WARNING: Unable to find appropriate interface for system route to F.G.H.I
**************************ROUTES**************************
DST/MASK     DEV GATEWAY
127.0.0.1/32 lo0 127.0.0.1

Darren

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