CERBERUS/nmap
1
0
Fork 0
mirror of https://github.com/nmap/nmap.git synced 2026-10-21 19:32:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Allow --min-rate to trump the built-in limit of 50 sends per wait.

Browse source
This commit is contained in:
david 2012-01-01 20:26:58 +00:00
parent cb8d701bf4
commit 2461746840
1 changed files with 10 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

20
scan_engine.cc
View file

@ -990,16 +990,6 @@ bool GroupScanStats::sendOK(struct timeval *when) {
return false;
}
/* There are good arguments for limiting the number of probes sent
between waits even when we do get appropriate receive times. For
example, overflowing the pcap receive buffer with responses is no
fun. On one of my Linux boxes, it seems to hold about 113
responses when I scan localhost. And half of those are the @#$#
sends being received. I think I'll put a limit of 50 sends per
wait */
if (recentsends >= 50)
return false;
/* Enforce a maximum scanning rate, if necessary. If it's too early to send,
return false. If not, mark now as a good time to send and allow the
congestion control to override it. */
@ -1029,6 +1019,16 @@ bool GroupScanStats::sendOK(struct timeval *when) {
}
}
/* There are good arguments for limiting the number of probes sent
between waits even when we do get appropriate receive times. For
example, overflowing the pcap receive buffer with responses is no
fun. On one of my Linux boxes, it seems to hold about 113
responses when I scan localhost. And half of those are the @#$#
sends being received. I think I'll put a limit of 50 sends per
wait */
if (recentsends >= 50)
return false;
/* In case the user specifically asked for no group congestion control */
if (o.nogcc) {
if (when)