Bug 37485 - Strange warning from ping
Strange warning from ping
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: iputils (Show other bugs)
7.1
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Phil Knirsch
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-24 18:51 EDT by Tim Mann
Modified: 2015-03-04 20:09 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-09 16:40:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Mann 2001-04-24 18:51:10 EDT
Any time I try to ping any nearby host (including localhost), I get this
message:

    Warning: time of day goes back, taking countermeasures.

The message is fairly harmless, but certainly the time of day clock is not
really going backwards on either the local host or the host I'm pinging.

For what it's worth, the -U flag to ping makes the message go away.  The
ping manpage is cryptic about what -U does.  In the example below,
"turquoise" is a machine plugged into the same 100 Mb/s ethernet hub, but I
also see the symptom with machines that are a few routers away.  It goes
away with machines that are much farther away.

[mann@milwaukee kernel]$ ping localhost
PING localhost (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
Warning: time of day goes back, taking countermeasures.
64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=255 time=132 usec
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=255 time=64 usec
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=255 time=56 usec

--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.056/0.084/0.132/0.034 ms

[mann@milwaukee kernel]$ ping -U localhost
PING localhost (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=255 time=104 usec
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=255 time=66 usec
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=255 time=59 usec

--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.059/0.076/0.104/0.021 ms

[mann@milwaukee kernel]$ ping turquoise
PING turquoise.pa.dec.com (16.4.80.155) from 16.4.80.141 : 56(84) bytes of
data.Warning: time of day goes back, taking countermeasures.
64 bytes from turquoise.pa.dec.com (16.4.80.155): icmp_seq=0 ttl=64
time=253 usec
64 bytes from turquoise.pa.dec.com (16.4.80.155): icmp_seq=1 ttl=64
time=134 usec

--- turquoise.pa.dec.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.134/0.193/0.253/0.061 ms

[mann@milwaukee kernel]$ ping -U turquoise
PING turquoise.pa.dec.com (16.4.80.155) from 16.4.80.141 : 56(84) bytes of
data.64 bytes from turquoise.pa.dec.com (16.4.80.155): icmp_seq=0 ttl=64
time=214 usec
64 bytes from turquoise.pa.dec.com (16.4.80.155): icmp_seq=1 ttl=64
time=164 usec

--- turquoise.pa.dec.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.164/0.189/0.214/0.025 ms
Comment 1 Michael Schwendt 2001-06-20 05:42:51 EDT
Hmmm, this is clearly related to the new SO_TIMESTAMP support which is enabled
by default. When "ping" receives an echo reply with a timestamp greater than the
sent timestamp (and it compares seconds and microseconds!), it prints a warning
and enables option -U implicitly which then reverts to old behaviour. That's why
you get a single warning only. So basically, if the clock of the ping'ed system
is back in time, ping will notice that when examing the timestamp of the echo
reply. Under some circumstances, the warning can make sense.

However, when pinging localhost, the behaviour is strange. For the first ping I
often receive a reply approx. 8 ms (!) earlier than it has been sent. Each next
reply arrives 50 /us earlier than sent. Maybe anyone knows whether glibc's
gettimeofday() and kernel's timestamp differ? :)
Comment 2 Phil Knirsch 2001-06-27 07:29:02 EDT
OK, this seems to have been really either a glibc or a kernel bug. Using the
newest rawhide i don't get the warning anymore.

I therefore close the bug with RAWHIDE. If you should encounter this problem
again with the newest kernel/glibc please reopen the bug.

Thanks,

Read ya, Phil
Comment 3 Martin Wilck 2001-08-08 12:05:11 EDT
I would suggest reopening this bug for two reasons:

1. It causes the RedHat-ready Hardware test to fail.
2. I have it on RedHat 7.1 for IA64, too, even with a very recent kernel
(2.4.7).
    From looking at the kernel code, I think that a glibc problem is very
unlikely.
    (Moreover, from ptracing ping and printing the timevals, it seems that the
"wrong"
     receive timeval is not the result of a gettimeofday() call.

So if you don't have the problem with rawhide, it is IMO either a
RedHat-specific kernel patch
or a change in ping that causes the warning to disappear.

Regards
Martin
Comment 4 Martin Wilck 2001-08-08 12:11:02 EDT
I just tested the ping package from Rawhide, it does not change anything.
Comment 5 Martin Wilck 2001-08-09 09:01:34 EDT
Correction - it is likely that what I reproted in my last e 2 e-mails is now
(i.e. with
recent kernels) an architecture-specific problem.

The "RELNOTES" file of the RedHat iputils package says

* By Pekka Savola <pekkas@netcore.fi>
  - SIOCGSTAMP/SO_TIMESTAMP are sensitive to bug in kernel.
    When get_fast_time != gettimeofday (f.e. timestampless x86),
    returned stamp can be out of sync with gettimeofday.
    Workaround is not to use SIOCGSTAMP/SO_TIMESTAMP on such systems.

This seems to be the case on IA64 (and some other architectures), but not on
i386.
Comment 6 Tim Mann 2001-11-09 16:35:00 EST
This bug still occurs, unchanged from my original report, in Red Hat 7.2,
kernel 2.4.7-10, on i686.  I've seen it on every machine I have used
ping on.  So the comment that it is architecture specific and does not
occur on i386 is bogus.

Maybe it's a kernel bug, or maybe it's an invalid assumption that ping
is making about the kernel, but either way, I don't think it should be
marked as closed.
Comment 7 Michael Schwendt 2001-11-09 16:40:05 EST
Have you tried the kernel-2.4.9-13 update from Red Hat yet? I cannot reproduce
it with that one. What about you?
Comment 8 Tim Mann 2001-11-09 23:07:55 EST
Hmm, you're right!  I have access to one machine with the 2.4.9-13 
kernel, and the bug does not show up there.  Sorry I didn't check
there before reopening the bug; I'll close it again.

Note You need to log in before you can comment on or make changes to this bug.