ICMP Type 3 Code 13 (and friends), TCP scanning, and scan delays

[Jon Passki <jon.passki () hursk com>]

Hello All,

While TCP SYN scanning, if a port is truly filtered and there won't  
ever be a returned packet, nmap keeps on trucking.  If it's still  
truly filtered and it receives an ICMP type 3 code 0, 1, 2, 3, 9, 10,  
or 13 reply, newstate is set to PORT_FILTERED or PORT_UNKNOWN in  
get_pcap_result().  Why, though, should the scan be penalized for a  
packet that really doesn't tell us anymore than we would have already  
known without it (except for added confirmation in the case of code  
0, 1, 2, 3 or 13)?  I understand the reason for type 3 code 3 during  
a UDP scan possibly slowing down the scan due to a rate limited dst  
host, but I'm not getting it for a TCP scan.

In ultrascan_port_probe_update(), this only affects the scan when  
probe->tryno == 0, so it's not all the time.  It does look like I can  
use -T4 or -T5 to defeat it, which is cool.  Is this the recommended  
way?  If so, I'd recommend a slight change to the man page.  UDP  
scanning explicitly states that rate limiting may affect the scanning  
time.  The --max-retries entry also generally describes rate limiting  
(maybe I just didn't grok this the right way) but I'm assuming these  
don't relate to ICMP type 3 error methods (or maybe they do and I  
need to RTF-RFC's :-)

Again, thanks for the tool and all the work you all put into it!

Cheers,

Jon



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev