Re: Crazy congestion control behavior after r33195

[David Fifield <david () bamsoftware com>]

On Tue, Jul 08, 2014 at 11:17:15PM +0200, Jacek Wielemborek wrote:
> List,
>
> Today I discovered that -p- scanning both scanme.nmap.org and 8.8.8.8 on
> the latest SVN trunk can lead to quickly finishing the scanning of
> 8.8.8.8 and sending one probe per second to scanme.nmap.org, which makes
> the scan last for several hours. I didn't have the patience to wait for
> the scan to complete, so here's a -d4 log - you can see that
> active_probes keeps between 1 and 0 while cwnd is 300:
>
> https://svn.nmap.org/!svn/bc/33201/nmap-exp/d33tah/uploads/r33198-incomplete-nmap_-p-_--unprivileged_-sT_-n_-Pn_-d4_scanme.nmap.org_8.8.8.8_stderr_to_stdout.log.lzma
>
> (Short URL: https://tinyurl.com/mln7o6b )
>
> Could somebody look at this? It could be nice to at least have a simpler
> testcase to reproduce this. I tried things like --top-ports=40000 and
> -p-40000, but only -p- (not even --top-ports=65535 and -p-65535!) lead
> to the result - though this could be just bad luck.

It looks like somewhere scan delay must have kicked in. As soon as you
get a non-zero scan delay, you can have only one outstanding probe at a
time. The log should have lines like

Increasing send delay for 74.207.244.221 from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for 74.207.244.221 from 5 to 10 due to max_successful_tryno increase to 5
Increasing send delay for 74.207.244.221 from 10 to 20 due to max_successful_tryno increase to 6

David Fifield
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/