Negative wait time after scan completion on Kali WSL

[jerryyudev]

Description of the issue

I'm encountering an issue where masscan reports a negative wait time after the scan has apparently completed in Kali WSL. This prevents my scripts from completing normally, as they rely on the wait time to determine when the scan is finished.

Specifically, after masscan finishes scanning, the wait time in the output becomes negative, such as "-1s", "-2s", etc. Even though all the targeted scans have finished, the masscan process does not exit, causing my scripts to hang. This issue specifically occurs within the Windows Subsystem for Linux (WSL) environment using Kali Linux.

Steps to reproduce

1. Operating System: Windows [Windows Version, e.g., 10/11] with Kali WSL
2. WSL Version: [WSL 1 or WSL 2] (Use wsl --list --verbose to check)
3. Kali WSL Version: [Output of lsb_release -a inside Kali WSL]
4. masscan Version: [Output of masscan --version inside Kali WSL]
5. Command used: [The exact command you used, e.g., sudo masscan -p1-65535 192.168.1.0/24 --rate 1000]
6. Network environment: [Any relevant information about your network within WSL, e.g., bridged mode, NAT mode, etc. Also mention if you're using any VPN within WSL or on the Windows host. E.g., "WSL is using NAT mode, no VPN connected on Windows host."]
7. Expected behavior: masscan should exit with a non-negative wait time (or exit immediately) after completing the scan.
8. Actual behavior: masscan reports a negative wait time and the process does not terminate.

Example output

[Paste the complete output of masscan from within Kali WSL, including the negative wait time. Please use code blocks for better readability.]

For example:

masscan -p1-65535 192.168.1.0/24 --rate 1000
Starting masscan 1.3 (http://bit.ly/14tV5HH) at 2024-10-27 10:00:00 GMT
-- rate 1000.00 packets/sec, 256 targets, duration 4 minutes 16 seconds
Starting SYN scan
Scanning 256 hosts [1 port/host]
Discovered open port 80/tcp on 192.168.1.1
Discovered open port 443/tcp on 192.168.1.2
...
Finished SYN scan in 4.2 minutes
Wait time: -2s

[mzpqnxow]

There are at least a half dozen issues (closed) for this as it's a very old bug which seems to have not been patched by various distributions

Building from the latest source (master branch) should resolve this

[Milkshak3s]

Is it possible that's because there hasn't been a release cut on this repo since 2021?

[mzpqnxow]

I think the issue is that the owner(s) of the Kali package don't use the tool or follow its development at all. Would adding a tag to the current point in time get their attention and cause them to update? Maybe, though I sorta doubt it.

Only the package maintainer can resolve this for everyone, so regardless of the cause, they are the person who needs to take action - whether they backport a single change to resolve this issue, choose a commit id to use as a tag for the future, or use master going forward.

I don't own this project, but as a long time contributor/follower I suggest that the best choice is to use master. Unlike many other open source projects, the state of master is functionally akin to what other projects might call "stable". If that's deemed too risky for the Kali userbase, then use the current commit-id of master as of this moment (appears to be b99d433505f942fb384516553442c15322efc472). However, I would point out that the Kali userbase currently has a "broken" version already. So using master wouldn't really be much worse, even if there was some careless commit to master

@robertdavidgraham @p-l- I think this can be resolved, though I wonder if it might be a good idea to have a notice (either in the README or in the Create Issue page) to the effect of "before reporting a bug, please test to see if the latest build from source is impacted" - this specific issue (the negative countdown) has been reported so many times at this point despite being long-fixed; and for other issues, the first guidance is almost always going to be "see if the issue is resolved in master" anyway. Could save a lot of people (both users, contributors, maintainers) a lot of time and grief

[mzpqnxow]

@Milkshak3s if you feel strongly about having tags on releases, the people to ask are those tagged in the previous update. Perhaps a separate issue would be good for that since it is its own "issue" and not really related to this particular behavior