Re: max-retries not playing well

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

(Gratuitous self-reply)

On Jun 30, 2006, at 12:56 PM, Jon Passki wrote:

[snipped a lot of good stuff :-) ]

> So, some hosts had 5-11 probes sent to one port, which would seem to
> violate the --max-retries 3 setting on the command line.  I'm
> assuming this is a bug.  Is there any further reporting I can provide?

Okay, ran w/ -d6 and got some good debugging info.  From a quick  
glance, the hosts that had an increased max_successful_tryno greater  
than --max-retries are having ICMP type=3/code=1 errors set back by  
an upstream router.  These seem rate limited, so UltraScan is not  
seeing a 1 to 1 probe/response and starts to up max_successful_tryno  
beyond --max-retries.  On a side, it will also start to increase the  
scan delay, too, which sucks for my current application (also read it  
in scan_engine.cc around line 1926).  I did another test w/ --max- 
scan-delay 120 and that was honored by the forced increase on the  
received ICMP errors.

Looking at the source, I'm gleaming the following

--) In ultra_scan(), waitForResponses() it seems is the routine that  
brought back the ICMP error message for processing via  
get_pcap_results() via ultrascan_port_probe_update() via  
ultrascan_adjust_times()
--) processData() defines "bool tryno_capped = false,  
tryno_mayincrease = false;" at line 3253
--) processData() calls "maxtries = host->allowedTryno(&tryno_capped,  
&tryno_mayincrease);" shortly thereafter

HostScanStats::allowedTryno():
[...]
   maxval = MAX(1, max_successful_tryno + 1);
   if (maxval > (unsigned int) USI->perf.tryno_cap) {
     if (capped) *capped = true;
     maxval = USI->perf.tryno_cap;
     tryno_mayincrease = false; /* It never exceeds the cap */
   } else if (capped) *capped = false;

[went to bed] I threw some debugging code in there and noticed that  
USI->perf.tryno_cap was set to 10, not 3 as I had set it to on the  
command line.  That explains why retransmits were occurring at a  
higher rate.  It gets initialized at init_perf_values() with the  
return of o.getMaxRetransmissions().  Throwing some more debugging  
code in there shows o.getMaxRetransmissions() set to 10 [I really  
could have got here faster just by seeing the output of --version- 
trace, oh well :-) ].  That's odd, since o.setMaxRetransmissions  
should have set it to 3. pre_max_retries does get set to 3 from the  
optargs, so it seems it's getting clobbered somewhere else.  Huh,  
pre_max_retries gets clobbered to "-1" before it reaches:

  if (pre_max_retries != -1) o.setMaxRetransmissions(pre_max_retries);

Ah ha!!!  Found the bug :-)  Scoping issue caused by casting  
pre_max_retries twice in nmap_main()

--- nmap.cc     2006-07-02 11:42:34.000000000 -0500
+++ nmap.cc.orig        2006-07-02 11:31:30.000000000 -0500
@@ -685,7 +685,7 @@
         if (l < 0) fatal("--max-scan-delay cannot be negative.");
         pre_max_scan_delay = l;
        } else if (optcmp(long_options[option_index].name, "max- 
retries") == 0) {
-        pre_max_retries = atoi(optarg);
+        int pre_max_retries = atoi(optarg);
          if (pre_max_retries < 0)
            fatal("max-retransmissions must be positive");
        } else if (optcmp(long_options[option_index].name, "randomize- 
hosts") == 0


begin 644 nmap.cc.patch
M+2TM(&YM87`N8V,),C`P-BTP-RTP,B`Q,3HT,CHS-"XP,#`P,#`P,#`@+3`U
M,#`**RLK(&YM87`N8V,N;W)I9PDR,#`V+3`W+3`R(#$Q.C,Q.C,P+C`P,#`P
M,#`P,"`M,#4P,`I`0"`M-C@U+#<@*S8X-2PW($!`"B`):68@*&P@/"`P*2!F
M871A;"@B+2UM87@M<V-A;BUD96QA>2!C86YN;W0@8F4@;F5G871I=F4N(BD[
M"B`)<')E7VUA>%]S8V%N7V1E;&%Y(#T@;#L*("`@("`@('T@96QS92!I9B`H
M;W!T8VUP*&QO;F=?;W!T:6]N<UMO<'1I;VY?:6YD97A=+FYA;64L(")M87@M
M<F5T<FEE<R(I(#T](#`I('L*+2`@("`@("`@<')E7VUA>%]R971R:65S(#T@
M871O:2AO<'1A<F<I.PHK("`@("`@("!I;G0@<')E7VUA>%]R971R:65S(#T@
M871O:2AO<'1A<F<I.PH@("`@("`@("!I9B`H<')E7VUA>%]R971R:65S(#P@
M,"D*("`@("`@("`@("!F871A;"@B;6%X+7)E=')A;G-M:7-S:6]N<R!M=7-T
M(&)E('!O<VET:79E(BD["B`@("`@("!](&5L<V4@:68@*&]P=&-M<"AL;VYG
M7V]P=&EO;G-;;W!T:6]N7VEN9&5X72YN86UE+"`B<F%N9&]M:7IE+6AO<W1S
((BD@/3T@,`H`
`
end

Thanks for the great tool, guys and girls!  I know a bit more about  
it now :-)

Jon





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