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

lpesyna · 2019-09-27T19:24:02Z

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 · 2019-10-04T08:07:51Z

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

lpesyna · 2019-10-04T09:26:04Z

I have some systems that I am unable to make work regardless of the max-parallelism setting. I've been forced to revert to 7.7. On Oct 4, 2019 4:08 AM, Tomasz Król <notifications@github.com> wrote: Same on my Windows 10 with freshly instaled nmap 7.8 Setting --max-parallelism to 10 helps. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#1764?email_source=notifications&email_token=ADYZ4PF6SVGLLIWMEZQBZ4LQM32XHA5CNFSM4I3KABB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAK3E7Y#issuecomment-538292863>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADYZ4PDCM2ASDXUKPWTNYUDQM32XHANCNFSM4I3KABBQ>.

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 · 2019-12-27T16:51:02Z

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 · 2020-02-05T15:24:20Z

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 · 2020-03-09T20:38:37Z

Same issue here on Win 10

jpluimers · 2020-03-24T13:22:38Z

~~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 · 2020-04-27T17:34:19Z

Duplicate of #1764, solved in 33f421f

wgaylord · 2020-07-02T18:36:32Z

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

marcingryska · 2020-07-10T06:36:32Z

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.

ItsIgnacioPortal · 2020-09-01T01:49:19Z

@bonsaiviking @dmiller-nmap new release for Windows pls

amitai · 2020-09-08T23:05:13Z

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 · 2020-09-11T22:06:14Z

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!

sandeep22-v · 2021-04-29T05:56:32Z

Internet might be very slow..That might be the reason

leoheck · 2021-09-21T18:09:24Z

Max --max-parallelism 100 did not work for me.

My command
nmap -oG - -p 554 --max-parallelism 100 ${network} 2>&1 >> .log

The output

nmap: Target.cc:503: void Target::stopTimeOutClock(const timeval*): Assertion `htn.toclock_running == true' failed.

My version

➜ nmap -v
Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-21 15:04 -03
Read data files from: /usr/bin/../share/nmap
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.03 seconds

➜ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=22.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=31.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=23.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=27.6 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=25.4 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.440/25.988/31.022/3.057 ms

My internet is not that bad, I should not have this problem, I think. It has to be something else.

leoheck · 2021-09-21T18:11:22Z

Now, some seconds after making the comment before, it worked. This issue is pretty hard to understand.

Saghetti0 · 2021-10-20T18:01:26Z

Building latest nmap (7,92) from source fixed this issue for me. As of now, the latest version of nmap for Ubuntu is 7.80, which still has the bug.

leoheck · 2021-10-20T19:09:19Z

Intereseting. But it takes more time to see if the issue persists since for me this comes and goes sporadically.

lepe · 2022-03-02T05:48:14Z

Same issue, same version. After rebooting the server it worked again.

Martyn575 · 2022-03-31T13:21:59Z

After consistently failing, it now consistently works. :)
As a workaround, go and make a cup of tea and come back and retry.

leoheck · 2022-03-31T13:31:58Z

I am still seeing nmap 7.8 as the default version on my pre-released Ubuntu 22.04 OS. Do you guys know when a new version of this tool is going to be spread to the world?

➜  ~ nmap --version 
Nmap version 7.80 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.6 openssl-3.0.0 nmap-libssh2-1.8.2 libz-1.2.11 libpcre-8.39 libpcap-1.10.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

➜  ~ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu Jammy Jellyfish (development branch)
Release:	22.04
Codename:	jammy

nnposter · 2022-03-31T16:26:44Z

As far as I know, it is up to the individual distros to decide what version they are going to ship.
Ubuntu Jammy appears to be shipping some hybrid version: 7.91+dfsg1+really7.80+dfsg1-2build1

dmak · 2022-04-12T20:53:18Z

Same issue with nmap 7.91+dfsg1+really7.80+dfsg1-2 from Debian x64 Bullseye:

# nmap --version
Nmap version 7.80 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.1j libssh2-1.9.0 libz-1.2.11 libpcre-8.44 libpcap-1.10.0 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Sometimes (about 1 per 5 runs) nmap fails with the following error:

# nmap --open -p 23,80 192.168.10.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2022-04-12 21:16 CEST
nmap: Target.cc:503: void Target::stopTimeOutClock(const timeval*): Assertion `htn.toclock_running == true' failed.

Core dump:

TIME                            PID   UID   GID SIG COREFILE  EXE
Mon 2022-04-11 10:05:04 CEST 123024     0     0   6 present   /usr/bin/nmap

           PID: 123024 (nmap)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 6 (ABRT)
     Timestamp: Mon 2022-04-11 10:04:57 CEST
  Command Line: nmap --open -p 23,80 192.168.10.0/24
    Executable: /usr/bin/nmap
       Message: Process 123024 (nmap) of user 0 dumped core.
                
                Stack trace of thread 123024:
                #0  0x00007f043ed6bce1 raise (libc.so.6 + 0x3bce1)
                #1  0x00007f043ed55537 abort (libc.so.6 + 0x25537)
                #2  0x00007f043ed5540f n/a (libc.so.6 + 0x2540f)
                #3  0x00007f043ed64662 __assert_fail (libc.so.6 + 0x34662)
                #4  0x000055f07b1f1da0 _ZN6Target16stopTimeOutClockEPK7timeval (nmap + 0xa4da0)
                #5  0x000055f07b1d7b08 _ZN13UltraScanInfo20removeCompletedHostsEv (nmap + 0x8ab08)
                #6  0x000055f07b1d90d4 _Z10ultra_scanRSt6vectorIP6TargetSaIS1_EEP10scan_lists5stypeP12timeout_info (nmap + 0x8c0d4)
                #7  0x000055f07b1f2b11 n/a (nmap + 0xa5b11)
                #8  0x000055f07b1f380c n/a (nmap + 0xa680c)
                #9  0x000055f07b1f3945 _Z8nexthostP14HostGroupStatePK7addrsetP10scan_listsi (nmap + 0xa6945)
                #10 0x000055f07b1aa5db _Z9nmap_mainiPPc (nmap + 0x5d5db)
                #11 0x000055f07b184028 main (nmap + 0x37028)
                #12 0x00007f043ed56d0a __libc_start_main (libc.so.6 + 0x26d0a)
                #13 0x000055f07b1840ca _start (nmap + 0x370ca)

I never faced the issue in Debian Buster (nmap v7.70).

dmiller-nmap closed this as completed Apr 27, 2020

tomaxuser mentioned this issue Sep 1, 2020

Assertion failure in HostOsScan::processTUdpResp #2114

Open

nmap / nmap Public

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

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

lpesyna commented Sep 27, 2019

twkrol commented Oct 4, 2019 •

edited

lpesyna commented Oct 4, 2019

davidasailor commented Dec 27, 2019

phodina commented Feb 5, 2020

xyxzxyz commented Mar 9, 2020 •

edited

jpluimers commented Mar 24, 2020 •

edited

dmiller-nmap commented Apr 27, 2020

wgaylord commented Jul 2, 2020 •

edited

marcingryska commented Jul 10, 2020 •

edited

ItsIgnacioPortal commented Sep 1, 2020

amitai commented Sep 8, 2020

fyodor commented Sep 11, 2020

sandeep22-v commented Apr 29, 2021

leoheck commented Sep 21, 2021

leoheck commented Sep 21, 2021

Saghetti0 commented Oct 20, 2021

leoheck commented Oct 20, 2021

lepe commented Mar 2, 2022

Martyn575 commented Mar 31, 2022 •

edited

leoheck commented Mar 31, 2022

nnposter commented Mar 31, 2022

dmak commented Apr 12, 2022 •

edited

nmap / nmap Public

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

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

Comments

lpesyna commented Sep 27, 2019

twkrol commented Oct 4, 2019 • edited

lpesyna commented Oct 4, 2019

davidasailor commented Dec 27, 2019

phodina commented Feb 5, 2020

xyxzxyz commented Mar 9, 2020 • edited

jpluimers commented Mar 24, 2020 • edited

dmiller-nmap commented Apr 27, 2020

wgaylord commented Jul 2, 2020 • edited

marcingryska commented Jul 10, 2020 • edited

ItsIgnacioPortal commented Sep 1, 2020

amitai commented Sep 8, 2020

fyodor commented Sep 11, 2020

sandeep22-v commented Apr 29, 2021

leoheck commented Sep 21, 2021

leoheck commented Sep 21, 2021

Saghetti0 commented Oct 20, 2021

leoheck commented Oct 20, 2021

lepe commented Mar 2, 2022

Martyn575 commented Mar 31, 2022 • edited

leoheck commented Mar 31, 2022

nnposter commented Mar 31, 2022

dmak commented Apr 12, 2022 • edited

twkrol commented Oct 4, 2019 •

edited

xyxzxyz commented Mar 9, 2020 •

edited

jpluimers commented Mar 24, 2020 •

edited

wgaylord commented Jul 2, 2020 •

edited

marcingryska commented Jul 10, 2020 •

edited

Martyn575 commented Mar 31, 2022 •

edited

dmak commented Apr 12, 2022 •

edited