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 · 22 comments
Closed

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

lpesyna opened this issue Sep 27, 2019 · 22 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.

@ItsIgnacioPortal
Copy link

@ItsIgnacioPortal ItsIgnacioPortal 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!

@sandeep22-v
Copy link

@sandeep22-v sandeep22-v commented Apr 29, 2021

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

@leoheck
Copy link

@leoheck leoheck commented Sep 21, 2021

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

Screenshot-20210921150645-1225x947

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

@leoheck
Copy link

@leoheck leoheck commented Sep 21, 2021

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

@Saghetti0
Copy link

@Saghetti0 Saghetti0 commented Oct 20, 2021

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
Copy link

@leoheck leoheck commented Oct 20, 2021

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

@lepe
Copy link

@lepe lepe commented Mar 2, 2022

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

@Martyn575
Copy link

@Martyn575 Martyn575 commented Mar 31, 2022

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

@leoheck
Copy link

@leoheck leoheck commented Mar 31, 2022

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
Copy link

@nnposter nnposter commented Mar 31, 2022

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
Copy link

@dmak dmak commented Apr 12, 2022

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

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

No branches or pull requests