create new tag
, view all tags
Thought I should summarize what I found out about this problem. (Will also update http://twiki.org/cgi-bin/view/Wikilearn/PingWrongDataByte0Bug.)

RESOLUTION: Turns out that the ping I was / am using is "obsolete" and it seems the bug does not exist in recent versions of ping (AFAIK).

DISCUSSION: I am using Mandrake 7.2 (UpdateFreq) for my mail server, and use ping to confirm my connection is up. The ping provided with Mandrake 7.2 comes from the "netkit" package. It has (or at least had, as of version 0.17), the bug described below.

Mandrake 8.2 (and possibly earlier versions, after 7.2) uses a ping that comes with the iputils package, and it seems that it does not have the problem. The difference -- netkit assigns a number to each outgoing ping and checks for that number on the return ping -- iputils just includes a date stamp, and apparently confirms the ping based on the return date stamp (or maybe doesn't confirm that the return ping matches the incoming ping -- I read some of the code (poorly) and corresponded with Alexey Kuznetsov <kuznet@SPAMSTOPms2.inr.ac.ru>, who is apparently the maintainer. This is quoted from the last correspondence (of four or five) I had from him:

> Thanks! I suspect that you are saying that your version of
> ping does not increment the message on subsequent pings?
Not quite.

A. Message is never "incremented".
B. Any ping _modifies_ the first 8-16 bytes filling them with current wall time.
C. This timestamp is used to calculate RTT.
D. It is not used to validate data

There is a different maintainer for netkit.

ORIGINAL REPORT: Turns out that there is a bug in ping which causes me to see the "wrong data byte #0 should be" 0x59 (0xhh?) "but was" error message, if the ping response takes longer than 1 second. Thanks to Pierre Fortin for pointing this out -- and, in fact, he's got the fix practically written -- see his post under #Notes).

I'd like to try to get this fixed in ping or noted on the ping manpage, but don't know how to contact the ping maintainers at this point in time. If you have any clues, let me know. Hmm, might be something in the source code, huh? -- I'll have to look for it.

See AboutThesePages.



I'm trying to find the maintainer of ping and then get the bug or man page fixed. So far:

  • I found matt@ping127001PLEASENOSPAM.com who is not the maintainer, but volunteered to put a notice on his web site describing the bug (or something like that).
  • I found Alexey Kuznetsov <kuznet@SPAMSTOPms2.inr.ac.ru> in the readme from the "original" sources. At first (and currently, AFAIK), he did not think his code could generate such an error and suspected that a downstream maintainer (someone at Mandrake) had added something. I downloaded his source and found code in ping_common.c which can generate the error message and wrote back to him (late last night) and am awaiting a reply. In one of his emails, he gave the address to the ftp site where the source is available, ftp://ftp.inr.ac.ru/ip-routing/iputils-<the latest> (iputils-ss020124.tar.gz) -- I had to fool around a little to get a listing of files and find the latest. The rpm for the latest mandrake srpm is iputils-20020124-4mdk.src.rpm -- I downloaded it from somewhere (Google for it) and it contains the same files (plus some patches). I suspect it is the "cooker" version so destined for Mandrake 9.0 (or higher).
  • Next step -- waiting -- spent a little time looking at the code -- there is some chance that I could make a fix, but here's hoping Alexey comes through!


Re: [expert] Fwd: Ping: "wrong data byte #0" error message
Date: Sat, 7 Sep 2002 11:42:58 -0400
From: Pierre Fortin <SPAMBLOCKED>
 To: expert@linux-mandrake.com
Reply to: expert@linux-mandrake.com

On Sat, 07 Sep 2002 10:07:51 -0500 "J. Craig Woods"
<drjung@trismegistus.net> wrote:

> > Complete ping response:
> > PING ( 56 octets data
> > 64 octets from icmp_seq=0 ttl=122 time=1099.4 ms
This is the "clue"...  ping response arrives AFTER 1 second timer pops....

Here's part of my post back on Thu Mar 15 15:13:48 2001


Linux's "ping" waits (default= 1 sec) for a reply and proceeds to the next ping after INCREMENTING "data byte #0". If a reply is seen before the timeout, or not at all, then ping does the right thing.

If a reply is delayed and the timer expires, ping increments "data byte #0" for the next packet to send. Again, no problem here per se... HOWEVER... ping fails to take into account the possibility of delayed replies. When such a reply finally shows up, ping compares "data byte #0" to the UPDATED value. No need to maintain a list of sent counters; a simple algorithm works...

Ping SHOULD compare "data byte #0" after first adjusting for the delay this way:

- save starting"data byte #0"
- when reply arrives:
    if "data byte #0" == starting"data byte #0" + icmp_seq:
       OK                                       ^^^^^^^^^^
    else: error()

Any fix should also take into account "wrapping" of the random "data byte #0" counter.

Also, the output:

wrong data byte #0 should be 0x3b but was 0x3737 da b0 3a 88 9e e 0

probably should be reformatted to read:

wrong data byte #0 should be 0x3b but was 0x37 37 da b0 3a 88 9e e 0

Note that this false-problem output also confirms the bug:

  expecting: 0x3b
  got:  0x37
  proper check:  0x37 + ("time=4452.8 ms" * wait_timer)
              =  0x37 + (int(4.4528) * 1)  # seconds
              =  0x37 + (4 * 1)
              =  0x3b      # Gee....!

By fixing this bug, we'll be able to eliminate the "I'm getting this..." and the "you have a hardware problem" emails, and the resulting wasted time and $$ trying to fix hardware which is really OK...


  • () RandyKramer - 07 Sep 2002
  • <If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.>

Page Ratings

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2002-09-10 - RandyKramer
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look