Nmap Development mailing list archives

Re: Timing related problem with nmap > 3.20?


From: Fyodor <fyodor () insecure org>
Date: Tue, 10 Jun 2003 22:37:42 -0700

On Wed, Jun 04, 2003 at 10:22:24AM +0100, Richard Moore wrote:
Hi all,

I recently upgraded to nmap 3.27 and I seem to be hitting a problem - I 
get the message:

Serious time computation problem in adjust_timeout ... received = 
(1054717924, 348069) sent=(1054717924,350690) delta = 0 srtt = -2621 
rttvar = 5000 to = 300000
QUITTING!

Thanks for the report.  This is a strange problem dealing with clock
inconsistencies of some sort.  I have implemented a workaround for the
next version of Nmap.  Here is a description which will be in the
CHANGELOG:

o Fixed (I hope) an issue that would cause Nmap to print "Serious time
  computation problem in adjust_timeout ..." and quit.  The ultimate
  cause was demonstrated by this --packet_trace snippet that Russel
  Miller (rmiller(a)duskglow.com) sent me:
  SENT (0.0500s) ICMP 0.0.0.0 > 127.0.0.1 Echo request (type=8/code=0) ...
  RCVD (0.0450s) ICMP 127.0.0.1 > 127.0.0.1 Echo reply (type=0/code=0) ...
  As you can see, the ping reply appears to come BEFORE the request
  was sent(!).  This sort of thing happens on at least Linux and
  Windows.  The send time is obtained from gettimeofday(NULL), while
  receive time libpcap packet header.  If anyone knows why this
  occurs, or (even better) knows a good way to fix it, let me know.
  For now, I am allowing the response to come up to .05s "before" the
  request.  That is gross.

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).



Current thread: