Nmap Development mailing list archives
Re: Patches to Nmap 5.30BETA1
From: David Fifield <david () bamsoftware com>
Date: Tue, 27 Apr 2010 18:30:53 -0600
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.11The 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/870That 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=../../nbaseshould 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/
Current thread:
- Patches to Nmap 5.30BETA1 Darren Reed (Apr 03)
- Re: Patches to Nmap 5.30BETA1 David Fifield (Apr 03)
- Re: Patches to Nmap 5.30BETA1 Darren Reed (Apr 06)
- Re: Patches to Nmap 5.30BETA1 David Fifield (Apr 22)
- Re: Patches to Nmap 5.30BETA1 David Fifield (Apr 27)
- Re: Patches to Nmap 5.30BETA1 Darren Reed (Apr 28)
- Re: Patches to Nmap 5.30BETA1 David Fifield (Apr 28)
- Re: Patches to Nmap 5.30BETA1 Darren Reed (Apr 06)
- Re: Patches to Nmap 5.30BETA1 David Fifield (Apr 03)