Scanning multiple ports - incorrect estimate and coverage details?

[lynch-a]

Hi, I might just be misunderstanding something and I know multi-port scans are fairly new, but when I enter a command like:

zmap -M tcp_synscan -w my-targets.txt -p 1,2,3,4,5,6,7,8,9,10 --rate=2000 -o my-output.txt

I expect that for each of my targets, at least 10 packets need to be sent (1 for each port). If I am scanning 5 million IP's, I expect to send 50 million packets.

However, the time estimate that is shown by zmap seems to be showing the IP coverage instead of total scan coverage. for example, here is a line of status output at "100%" coverage and "0s left" for my scan after only an hour, when I know the scan should take about 5 hours at 2k pps:

1:03:59 100% (0s left); send: 5677488 2.00 Kp/s (2.00 Kp/s avg); recv: 51404 14 p/s (13 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.67%

I expect to send (5 million IP's * 10 ports each) 50 million packets, but zmap output says it is 100% done at only 5,677,488 packets sent.

Even more confusingly, zmap continued to scan past "100%". here is the next line of output from this same scan:

1:04:00 100% (136 years left); send: 5679487 2.00 Kp/s (2.00 Kp/s avg); recv: 51414 10 p/s (13 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.67%

Maybe it is listed somewhere that the default behavior is to just continue repeatedly or something...? sorry I am not really sure why this would be the default behavior, but I want to prevent it.

I found the -n 100% in the docs afterwards to stop my scan at "100%" coverage, but I want to stop at 100% port coverage. will my scan stop at 100% IP coverage instead of 100% port coverage if I include -n 100%? can I change the output to show me port coverage? thanks for any insight.

[zakird]

Can you confirm that you're running this on the master branch? If it is, we can go ahead and create a bug to track this. This certainly doesn't sound like the behavior we'd expect. There have however been some recent changes to the codebase that could have affected this, so want to make sure you're looking at the same code we are.

[lynch-a]

I meant to include my exact version but this is the output I got:

zmap --version
...omitted default annoying [INFO] banner telling me about the defaults...
zmap Development Build. Commit UNKNOWN

I can tell you that this behavior was observed by compiling the code from the 4.0 release RC1: https://github.com/zmap/zmap/archive/refs/tags/v4.0.0-RC1.zip

I did also compile and install the 4.1 RC and it appeared to give me the same incorrect estimate of time as per above, though I did not let it run for long. I'll check out what happens if I compile from master and file a bug if I see the same thing

[zakird]

4.1-RC1 was tagged yesterday, so it's inline with master at the moment. Sounds like a bug.

[zakird]

-> #832

[lynch-a]

Thanks for the quick fix, @phillip-stephens - my command is now now showing the right time estimates on my end!