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).

codeScriber · 2022-07-09T16:45:17Z

i'm on ubuntu 22.04 and after the last upgrade the issue appeared, if so many ppl complain and i don't see a resolution or a workaround, how come the issue is closed ? it's a show stopper, the program doesn't run
BTW
Since this an assertion failure run it with NDEBUG=1 stops the system from processing assertsions. So the program can run still something is not right in there.

nnposter · 2022-07-11T19:16:17Z

@codeScriber

if so many ppl complain and i don't see a resolution or a workaround, how come the issue is closed ?

The issue is closed because the originally identified problem is presumed resolved in version 7.90 and no message in this thread indicates otherwise. If you are getting this assertion error in the current version, 7.92, then please open a new issue.

As noted earlier, please note that some distributions are creating their own versions of Nmap, such as 7.91+dfsg1+really7.80+dfsg1-2, which suggests that this is some kind of a hybrid, over which the Nmap project has no control. It is therefore always more useful if the issue can be demonstrated with a binary package downloaded from Nmap.org or compiled from the official source code.

codeScriber · 2022-07-11T21:22:15Z

thanks for the clarification.
ubuntu 22.04 apparently still packs the old version 7.80 so probably compiling from source is the only solution, or building a static distribution which is portable...

Martyn575 · 2022-07-12T12:46:11Z

I am pretty sure i know what causes this bug. If you have a subnet like 10.0.50.X, and you do an nmap outside of the subnet, say you do:

nmap -sP 10.0.50.2-254

You will get this error, but if you do something else like:

nmap -sP 10.0.50.2-150

It will function correctly.

So i suspect this issue is entirely down to being inside or outside of a subnet or some such, because i don't see this issue when you run it on a class C subnet. And this is on nmap 7.80 (the latest with n00000buntu)

codeScriber · 2022-07-12T14:01:13Z

Actually i ran `nmap 192.168.100.0/24 -p 0-1024 --open`

…

On Tue, Jul 12, 2022 at 3:46 PM Martyn575 ***@***.***> wrote: I am pretty sure i know what causes this bug. If you have a subnet like 10.0.50.X, and you do an nmap outside of the subnet, say you do: nmap -sP 10.0.50.2-255 You will get this error, but if you do something else like: nmap -sP 10.0.50.2-150 It will function correctly. So i suspect this issue is entirely down to being inside or outside of a subnet or some such, because i don't see this issue when you run it on a class C subnet. And this is on nmap 7.80 (the latest with n00000buntu) — Reply to this email directly, view it on GitHub <#1764 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMZUIL572C4ZEBDDGXUYN3VTVSJ7ANCNFSM4I3KABBQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

msandy · 2022-08-03T17:15:57Z

please note that some distributions are creating their own versions of Nmap, such as 7.91+dfsg1+really7.80+dfsg1-2, which suggests that this is some kind of a hybrid, over which the Nmap project has no control.

According to https://nmap.org/book/inst-linux.html, these packages are managed by a "LaMont Jones". Assuming this is not the basketball player, searching for "lamont jones linux" results in a debian thread titled LaMont Jones, WTH are you doing? from 2013 which seems to indicate some long-running controversy over this kind of repackaging of other binaries.

In any case, I'd guess that 99.9% of nmap users acquire the binary through a package manager and will probably end up getting the old version currently. This may not be nmap's "fault" but it's still nmap's problem. Not every package in debian/ubuntu gets repackaged like nmap, so what is it about nmap that requires it, and is preventing the adoption of 7.9 into the default apt sources?

kjellarneodegaard · 2022-10-27T10:01:20Z

For anybody else ending up here researching an nmap error message, my solution was to install a new (7.93) nmap version from snap: https://snapcraft.io/nmap

Remember give it access to network-control sudo snap connect nmap:network-control

mivsvit · 2023-03-03T13:31:53Z

This looks like this may be fixed in Ubuntu. See for example:

https://ubuntu.pkgs.org/22.04/ubuntu-updates-universe-amd64/nmap_7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1_amd64.deb.html
and

https://bugs.launchpad.net/ubuntu/+source/nmap/+bug/1908223

According to https://nmap.org/book/inst-linux.html, these packages are managed by a "LaMont Jones".

I don't believe that is the case any more. Debian maintainers listed at
https://packages.debian.org/stable/nmap

As discussed in both the changelog and the Ubuntu bug, there seem to be concerns about the licensing terms for newer versions of nmap.

ghost · 2023-04-26T22:04:11Z

uname -a:
Linux ubuntu 5.10.104-tegra #1 SMP PREEMPT Sun Mar 19 07:55:28 PDT 2023 aarch64 aarch64 aarch64 GNU/Linux

cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

The solutions don't work. I am still getting error when I run nmap

Starting Nmap 7.80 ( https://nmap.org ) at 2023-04-26 18:00 EDT
nmap: Target.cc:503: void Target::stopTimeOutClock(const timeval*): Assertion `htn.toclock_running == true' failed.
Aborted

rgaufman · 2023-07-10T10:47:44Z

Any solution to this for Ubuntu 20.04?

ghost · 2023-07-11T19:37:47Z

I dont remember if I fixed this but check if your system's clock is up to date.

…

________________________________ From: Roman Gaufman ***@***.***> Sent: Monday, July 10, 2023 6:47 AM To: nmap/nmap ***@***.***> Cc: Safa Bacanli ***@***.***>; Comment ***@***.***> Subject: Re: [nmap/nmap] Nmap 7.8 Assertion failed: htn.toclock_running == true (#1764) Any solution to this? — Reply to this email directly, view it on GitHub<#1764 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXVR7O53T7O6R3ZLOLYF6UDXPPMV5ANCNFSM4I3KABBQ>. You are receiving this because you commented.Message ID: ***@***.***>

rgaufman · 2023-07-11T22:50:22Z

It is up to date using and using ntp to ensure it stays up to date. Compiling the latest version from source fixes this, but are there any precompiled packages for 20.04?

zcattacz · 2024-07-03T00:35:04Z

Last time I didn't realize the rtl8168 driver crashed. And I tried some -PA/PE/sP scan on one LAN with both /24 and .* pattern. I was given this same error, meanwhile tcpdump did show some rare ARP replies from that network interface around the moment nmap crashed, it was a very confusing troubleshoot.

dmiller-nmap closed this as completed Apr 27, 2020

tomaxuser mentioned this issue Sep 1, 2020

Assertion failure in HostOsScan::processTUdpResp #2114

Open

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 Loading

lpesyna commented Oct 4, 2019 via email

davidasailor commented Dec 27, 2019

phodina commented Feb 5, 2020

xyxzxyz commented Mar 9, 2020 • edited Loading

jpluimers commented Mar 24, 2020 • edited Loading

dmiller-nmap commented Apr 27, 2020

wgaylord commented Jul 2, 2020 • edited Loading

marcingryska commented Jul 10, 2020 • edited Loading

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 Loading

leoheck commented Mar 31, 2022

nnposter commented Mar 31, 2022

dmak commented Apr 12, 2022 • edited Loading

codeScriber commented Jul 9, 2022 • edited Loading

nnposter commented Jul 11, 2022

codeScriber commented Jul 11, 2022

Martyn575 commented Jul 12, 2022 • edited Loading

codeScriber commented Jul 12, 2022 via email

msandy commented Aug 3, 2022

kjellarneodegaard commented Oct 27, 2022

mivsvit commented Mar 3, 2023

ghost commented Apr 26, 2023

rgaufman commented Jul 10, 2023 • edited Loading

ghost commented Jul 11, 2023 via email

rgaufman commented Jul 11, 2023

zcattacz commented Jul 3, 2024

twkrol commented Oct 4, 2019 •

edited

Loading

xyxzxyz commented Mar 9, 2020 •

edited

Loading

jpluimers commented Mar 24, 2020 •

edited

Loading

wgaylord commented Jul 2, 2020 •

edited

Loading

marcingryska commented Jul 10, 2020 •

edited

Loading

Martyn575 commented Mar 31, 2022 •

edited

Loading

dmak commented Apr 12, 2022 •

edited

Loading

codeScriber commented Jul 9, 2022 •

edited

Loading

Martyn575 commented Jul 12, 2022 •

edited

Loading

rgaufman commented Jul 10, 2023 •

edited

Loading