Re: time computation problem ? .....

[Fyodor <fyodor () insecure org>]

On Wed, Apr 23, 2003 at 04:44:24AM +0200, Diego Casorran wrote:
>    Hello!,
>
> Fyodor, the patch seems ready,, but _sometimes_ running nmap (3.25), 
> I get the follow error:
>
> Serious time computation problem in adjust_timeout ... received =
> (798607545, 853085) sent=(1051071945,849248) delta = 0 srtt =
> -1927369987 rttvar = 5000 to = 300000
>
> I have not see it with the 3.20, some idea of whats the problem?

3.25 uses pcap to obtain packet receive times.  This didn't quite work
on Windows, and maybe that is the problem on Amiga as well?  Note in
tcpip.cc:

#ifdef WIN32
 gettimeofday(&tv_end, NULL);
 *rcvdtime = tv_end;
#else
 *rcvdtime = head.ts;
 assert(head.ts.tv_sec);
#endif

Maybe you need to add Amiga to the ifdef?

By the way, perhaps someone here has an idea about why this fails to
work under Windows?  I found that a gettimeofday() call (compatability
function is in nbase) when a packet is sent (e.g. targets.cc) would
sometimes return a LATER time by a few hundredths of a second than the
pcap time gives me for the response.  So as you can see above, I am
now using gettimeofday() in both cases under Windows.  Does anyone
know where this problem comes from?  Some sort of time caching issue
in Winpcap or functions called by nbase gettimeofday()?  I'm all ears
if anyone has a solution.  Performance should be better using the
libpcap receive time rather than the time Nmap calls pcap_next().

Cheers,
-F

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).