Re: Patches to Nmap 5.30BETA1

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

On 27/04/10 05:30 PM, David Fifield wrote:
> 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?
> ...
> > > > 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.

Right.

What I'd like to suggest is that the detection and use of
a method to access raw ethernet packets be separated from
querying the kernel for a MAC address.

I can add SIOCGIFHWADDR support for PF_INET but in this case
that would presume that PF_PACKET was the right choice for
raw access. While that will work, I'd prefer to see BPF used
because it is much more efficient for packet capture than
PF_PACKET.

Additionally, what if someone added SIOCGIFHWADDR support
to a BSD platform at some point in the future?

Darren

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