Nmap Development mailing list archives
Re: Weird Crash - "WAITING_TO_RUNNING"
From: Nathan <nathan.stocks () gmail com>
Date: Wed, 3 Nov 2010 16:32:30 -0600
On Wed, Nov 3, 2010 at 1:33 PM, Nathan <nathan.stocks () gmail com> wrote:
On Wed, Nov 3, 2010 at 11:29 AM, Patrick Donnelly <batrick () batbytes com> wrote:On Wed, Nov 3, 2010 at 1:07 PM, Nathan <nathan.stocks () gmail com> wrote:"Is this on a 32-bit machine?" -- The hardware is 64-bit capable, but the old version of linux on it is compiled in 32-bit, I think. The OS can address more than 4GB RAM, but the stuff running on it seems to act very 32-bit. Python's maxint is 32-bit, anyway: $ python Python 2.5.2 (r252:60911, Oct 30 2008, 18:03:18) [GCC 4.1.2 (Gentoo 4.1.2 p1.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information.import sys sys.maxint2147483647 $ uname -a Linux scan5 2.6.23-gentoo-r9 #4 SMP Tue Oct 12 16:02:12 MDT 2010 i686 Intel(R) Xeon(R) CPU E5507 @ 2.27GHz GenuineIntel GNU/LinuxYour processor (running as 32 bit) is using PAE (Physical Address Extension) to allow more than 4GB of RAM. Your process is still only allowed ~4GB of addressable RAM. This is why Nmap is crashing for you.Okay, I'll buy that that is the _symptom_ we're seeing. I can't imagine you're trying to imply that it's normal for an nmap scan of one target to take that much RAM, though. At 65,535 ports, 4GB gives you 64KB PER PORT. I could generate a small jpeg thumbnail of the traffic sent to each port at that rate. The question is, WHAT is using up that RAM, and how do we stop it? I could run multiple instances of this same scan on this same box with nmap 4.68 (that I just upgraded from) against this target without any problems at all. Did anyone look at the stack trace??? It seriously can't be normal to run "skypev2-version" and "jdwp-version" tens of thousands of times until you run out of RAM. Infinite loop, anyone? Or, perhaps this is caused by nmap erroneously thinking every single port is open (which is one of the things I hoped upgrading would fix), where the underlying assumption is that very few ports will be open so we can use a ton of memory to investigate each open port? ~ Nathan
Found a workaround: add "--scan-delay 1ms". It finishes a lot quicker too. It seems much more accurate too. At least it has a lot less than 65,535 ports listed as open like nmap 4.68 thought. So now my question is: According to the nmap man page, nmap will "try" to dynamically determine an appropriate delay time, but it's unclear as to whether specifying this option overrides that dynamic determination completely or if it just sets a starting point that will still be dynamically adjusted if it thinks is necessary. Does anyone know which behavior I just described matches reality? If specifying "--scan-delay" overrides the dynamic determination completely, then I'll need to do some careful testing of appropriate values, because I may not want to blindly add this option to all the hosts that I need to scan. /usr/bin/sudo /usr/bin/nmap --scan-delay 1ms -sS -sV -T4 -p 1-65535 74.62.92.70 -P0 Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-11-03 14:21 MDT Nmap scan report for remote.tjwels.net (74.62.92.70) Host is up (0.076s latency). Not shown: 65523 closed ports PORT STATE SERVICE VERSION 20/tcp filtered ftp-data 21/tcp filtered ftp 25/tcp open smtp Microsoft ESMTP 53/tcp open domain Microsoft DNS 6.0.6002 80/tcp open http Microsoft IIS httpd 7.0 110/tcp filtered pop3 143/tcp filtered imap 443/tcp open ssl/http Microsoft IIS httpd 7.0 663/tcp filtered unknown 987/tcp open ssl/http Microsoft IIS httpd 7.0 3389/tcp open microsoft-rdp Microsoft Terminal Service 4125/tcp filtered rww Service Info: OS: Windows Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 346.09 seconds ~ Nathan _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 01)
- Re: Weird Crash - "WAITING_TO_RUNNING" Patrick Donnelly (Nov 02)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 02)
- Re: Weird Crash - "WAITING_TO_RUNNING" David Fifield (Nov 02)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 03)
- Re: Weird Crash - "WAITING_TO_RUNNING" Patrick Donnelly (Nov 03)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 03)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 03)
- Re: Weird Crash - "WAITING_TO_RUNNING" David Fifield (Nov 03)
- Re: Weird Crash - "WAITING_TO_RUNNING" David Fifield (Nov 03)
- Re: Weird Crash - "WAITING_TO_RUNNING" Patrick Donnelly (Nov 03)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 08)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 08)
- Re: Weird Crash - "WAITING_TO_RUNNING" Rob Nicholls (Nov 08)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 02)
- Re: Weird Crash - "WAITING_TO_RUNNING" Patrick Donnelly (Nov 02)
- Re: Weird Crash - "WAITING_TO_RUNNING" David Fifield (Nov 05)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 08)
- Re: Weird Crash - "WAITING_TO_RUNNING" Nathan (Nov 08)
- Re: Weird Crash - "WAITING_TO_RUNNING" Patrick Donnelly (Nov 08)