Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nmap 7.8 Assertion failed: htn.toclock_running == true #1764

Closed
lpesyna opened this issue Sep 27, 2019 · 12 comments
Closed

Nmap 7.8 Assertion failed: htn.toclock_running == true #1764

lpesyna opened this issue Sep 27, 2019 · 12 comments

Comments

@lpesyna
Copy link

@lpesyna lpesyna commented Sep 27, 2019

I am now getting this error when I attempt to do a full discovery sweep on our Class C systems. Using a local Windows 7 PC, no router hop, using syn scans as some devices do not respond to ping.

This is new to us in version 7.8, We have used these routines in version 7.7, 7.6, 6.x, and prior.

Assertion failed: htn.toclock_running == true, file ..\Target.cc, line 503

The command for a specific instance is as below.

"C:\Program Files (x86)\Nmap\nmap.exe" -v -T2 -p21,23,80 -n -oA c:\uploads\local -Pn --exclude 10.11.11.234,10.11.11.254 10.11.11.234/24

By trial an error I have found the threshold for triggering the error is a target range on or around 104 IP addresses. Setting --max-parallelism to 10 (random choice) prevents the error in the situations I tried.

Of course, I am unable to reproduce this in our lab environment, it only has occurred in our production subnets,

@twkrol
Copy link

@twkrol twkrol commented Oct 4, 2019

Same on my Windows 10 with freshly instaled nmap 7.8
Setting --max-parallelism to 10 or even 100 - helps.

@lpesyna
Copy link
Author

@lpesyna lpesyna commented Oct 4, 2019

nmap-bot pushed a commit that referenced this issue Dec 3, 2019
We probably want a more explicit handling of the case where we get an
ARP response to a request that we did not send (system's own, or another
Nmap scan running at the same time). In any case, this ought to solve
the crashes reported as #1797 and #1764.
@davidasailor
Copy link

@davidasailor davidasailor commented Dec 27, 2019

I am having the same problem on my home network, scanning 192.168.1.0/24. Nmap version 7.80 on Fedora 31, run as root. Was not a problem until I updated to Fedora 31 this week (I presume Fedora 30 had an earlier Nmap version). It seems to be inconsistent, but fails more often than not. Does not seem to be affected by max-parallelism.

# nmap -V
Nmap version 7.80 ( https://nmap.org )
Platform: x86_64-redhat-linux-gnu
Compiled with: nmap-liblua-5.3.5 openssl-1.1.1c libssh2-1.9.0 libz-1.2.11 libpcre-8.43 libpcap-1.8.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

# nmap -vvv -sn -d --max-parallelism 10 192.168.1.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2019-12-27 11:45 EST
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 10
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Initiating ARP Ping Scan at 11:45
nmap: Target.cc:503: void Target::stopTimeOutClock(const timeval*): Assertion `htn.toclock_running == true' failed.

@phodina
Copy link

@phodina phodina commented Feb 5, 2020

Same on my Mac OS (macOS 10.14.6)

# nmap -sS 192.168.1.1-254
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-05 16:18 CET
Assertion failed: (htn.toclock_running == true), function stopTimeOutClock, file Target.cc, line 503.
[1]    2485 abort      sudo nmap -sS 192.168.1.1-254
@xyxzxyz
Copy link

@xyxzxyz xyxzxyz commented Mar 9, 2020

Same issue here on Win 10

@jpluimers
Copy link

@jpluimers jpluimers commented Mar 24, 2020

Could this be This is indeed related to #1797 ? (I previously missed 33f421f that should fix this).

On Windows 10, this simple case already fails (similar to the Mac OS case above) some of the times:

nmap -sn 192.168.71.0/24

The suggested workaround to add --max-parallelism 100 works fine:

nmap -sn --max-parallelism 100 192.168.71.0/24

Note that :

  • a Physical MacOS 10.13.6 machine on the same network does not exhibit the behaviour.
  • Windows 7 Professional and Windows 8.1 Enterprise machines (both VM and Physical) on the same network do not exhibit the behaviour
@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Apr 27, 2020

Duplicate of #1764, solved in 33f421f

@wgaylord
Copy link

@wgaylord wgaylord commented Jul 2, 2020

Will a build with this fix be out soon for windows? Or do we have to build it to get this fix.

@marcingryska
Copy link

@marcingryska marcingryska commented Jul 10, 2020

Will a build with this fix be out soon for windows? Or do we have to build it to get this fix.

Thumbs up for this important question. I also would like to know when this fix would be available in stable Windows version. We also encouterred such issue.

@PinkDev1
Copy link

@PinkDev1 PinkDev1 commented Sep 1, 2020

@bonsaiviking @dmiller-nmap new release for Windows pls

@amitai
Copy link

@amitai amitai commented Sep 8, 2020

Will a build with this fix be out soon for windows? Or do we have to build it to get this fix.

Thumbs up for this important question. I also would like to know when this fix would be available in stable Windows version. We also encouterred such issue.

big same my friends

@fyodor
Copy link
Member

@fyodor fyodor commented Sep 11, 2020

Hi Folks. Our goal is to have a new Nmap release this month which would include this and all of the other fixes we've made since the last release. Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.