Nmap 7.8 Assertion failed: htn.toclock_running == true #1764
Comments
|
Same on my Windows 10 with freshly instaled nmap 7.8 |
|
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>.
|
|
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. |
|
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 |
|
Same issue here on Win 10 |
|
On Windows 10, this simple case already fails (similar to the Mac OS case above) some of the times:
The suggested workaround to add
Note that :
|
|
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. |
|
@bonsaiviking @dmiller-nmap new release for Windows pls |
big same my friends |
|
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! |
|
Internet might be very slow..That might be the reason |
|
Max My command The output My version
My internet is not that bad, I should not have this problem, I think. It has to be something else. |
|
Now, some seconds after making the comment before, it worked. This issue is pretty hard to understand. |
|
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. |
|
Intereseting. But it takes more time to see if the issue persists since for me this comes and goes sporadically. |
|
Same issue, same version. After rebooting the server it worked again. |
|
After consistently failing, it now consistently works. :) |
|
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? |
|
As far as I know, it is up to the individual distros to decide what version they are going to ship. |
|
Same issue with nmap 7.91+dfsg1+really7.80+dfsg1-2 from Debian x64 Bullseye: Sometimes (about 1 per 5 runs) nmap fails with the following error: Core dump: I never faced the issue in Debian Buster (nmap v7.70). |
|
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 |
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. |
|
thanks for the clarification. |
|
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) |
|
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:
***@***.***>
|
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? |
|
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 |
|
This looks like this may be fixed in Ubuntu. See for example: https://bugs.launchpad.net/ubuntu/+source/nmap/+bug/1908223
I don't believe that is the case any more. Debian maintainers listed at As discussed in both the changelog and the Ubuntu bug, there seem to be concerns about the licensing terms for newer versions of nmap. |
|
uname -a: cat /etc/os-release 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 |
|
Any solution to this for Ubuntu 20.04? |
|
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: ***@***.***>
|
|
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? |
and others
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,
The text was updated successfully, but these errors were encountered: