Re: Fwd: Re: [expert] Fwd: Ping: "wrong data byte #0" error message
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 <[EMAIL PROTECTED]>, 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. Randy Kramer Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: PING BUG [Was: Re: [expert] Fwd: Ping: "wrong data byte #0" error message]
rsync traffic... my DSL link was maxed out with it. P. On Mon, 9 Sep 2002 15:53:36 -0700 Todd Lyons <[EMAIL PROTECTED]> wrote: > Pierre Fortin wrote on Sat, Sep 07, 2002 at 02:32:23PM -0400 : > > On Sat, 7 Sep 2002 14:01:54 -0400 Randy Kramer <[EMAIL PROTECTED]> > > wrote: > > > > [root@bones pfortin]# ping 64.53.54.1 > > PING 64.53.54.1 (64.53.54.1): 56 octets data > > 64 octets from 64.53.54.1: icmp_seq=0 ttl=253 time=4452.8 ms > > Pierre, what exactly was going on that you consistently got > 4 second > pings? Hardware issue or configuration issue? > > Blue skies... Todd Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: PING BUG [Was: Re: [expert] Fwd: Ping: "wrong data byte #0" error message]
Pierre Fortin wrote on Sat, Sep 07, 2002 at 02:32:23PM -0400 : > On Sat, 7 Sep 2002 14:01:54 -0400 Randy Kramer <[EMAIL PROTECTED]> wrote: > > [root@bones pfortin]# ping 64.53.54.1 > PING 64.53.54.1 (64.53.54.1): 56 octets data > 64 octets from 64.53.54.1: icmp_seq=0 ttl=253 time=4452.8 ms Pierre, what exactly was going on that you consistently got > 4 second pings? Hardware issue or configuration issue? Blue skies... Todd -- ...and I will strike down upon thee with great vengeance and furious anger, those who attempt to poison and destroy my binaries, and you will know my name is root, when I lay my vengeance upon thee. Cooker Version mandrake-release-9.0-0.3mdk Kernel 2.4.19-9mdk msg57638/pgp0.pgp Description: PGP signature
Re: Fwd: Re: [expert] Fwd: Ping: "wrong data byte #0" error message
ping is a part of the iputils pkg.
[narb@narghoul narb]$ rpm -q --whatprovides "/bin/ping"
iputils-20020124-4mdk
On Saturday 07 September 2002 02:29 pm, Randy Kramer wrote:
> Hello matt,
>
> Are you the maintainer of ping? If so, please read this and consider
> implementing a fix. If not do you know who the maintainer is / how to
> contact him?
>
> In response to a problem I mentioned on the Mandrake expert list
> ([EMAIL PROTECTED]), Pierre Fortin sent me the following which
> convinces me (at least) that there is a bug in ping that could be fixed
> (or at least noted in the man page).
>
> Note that the ping I use (on Linux) reports "ping utility,
> iputils-ss001110" in response to ping -V.
>
> regards,
> Randy Kramer
>
> -- Forwarded Message --
>
> > > PING 206.245.176.211 (206.245.176.211): 56 octets data
> > > 64 octets from 206.245.176.211: 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
>
> BUG SUMMARY:
>
>
> 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...
--
Brandon Long
Northern Michigan Online
[EMAIL PROTECTED]
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] Fwd: Ping: "wrong data byte #0" error message
Hi Craig,
On Sat, 07 Sep 2002 10:07:51 -0500 "J. Craig Woods"
<[EMAIL PROTECTED]> wrote:
> > Complete ping response:
>
> > PING 206.245.176.211 (206.245.176.211): 56 octets data
> > 64 octets from 206.245.176.211: 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
BUG SUMMARY:
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...
> It appears, without the benefit of running a sniffer on your network,
> that some of your ICMP packets are getting munged while traversing the
> network. If this happens only occassionally, it might not be a big deal
> but if you see a lot of this, you might be looking at a bad TCP/IP stack
> implementation on your machine or some other machine/router between you
> and your ISP.
>
> Try installing and using Ethereal for a better understanding of what is
> actually taking place on the network. It is a good sniffer, and comes in
> mandrake rpm binary or source.
>
> drjung
>
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] Fwd: Ping: "wrong data byte #0" error message
On Sat, 7 Sep 2002 10:09:27 -0400 Randy Kramer <[EMAIL PROTECTED]> wrote: > I suppose I should run a sniffer on the network, but there really > should not be a lot of traffic. Can anybody recommend a sniffer that > comes with Mandrake 7.2 or 8.2 (i.e., so I can install from an rpm)? Oops... missed this question... I prefer ethereal for tracing... HTH, Pierre Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] Fwd: Ping: "wrong data byte #0" error message
> Complete ping response: > PING 206.245.176.211 (206.245.176.211): 56 octets data > 64 octets from 206.245.176.211: icmp_seq=0 ttl=122 time=1099.4 ms > wrong data byte #0 should be 0x59 but was 0x5858 ff 79 3d 79 6b a 0 >8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f > 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > 64 octets from 206.245.176.211: icmp_seq=1 ttl=122 time=268.4 ms > 64 octets from 206.245.176.211: icmp_seq=2 ttl=122 time=283.4 ms > 64 octets from 206.245.176.211: icmp_seq=3 ttl=122 time=251.6 ms> > In the above case, the wrong data byte occurred for only one of the > pings -- in other cases it occurs for 2, 3, or 4 (all of the) pings, > but usually (always?) for the earliest pings rather than the last > pings. It appears, without the benefit of running a sniffer on your network, that some of your ICMP packets are getting munged while traversing the network. If this happens only occassionally, it might not be a big deal but if you see a lot of this, you might be looking at a bad TCP/IP stack implementation on your machine or some other machine/router between you and your ISP. Try installing and using Ethereal for a better understanding of what is actually taking place on the network. It is a good sniffer, and comes in mandrake rpm binary or source. drjung -- J. Craig Woods UNIX/NT Network/System Administration http://www.trismegistus.net/resume.html Character is built upon the debris of despair --Emerson Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] Fwd: Ping: "wrong data byte #0" error message
Background: In conjunction with running fetchmail every 10 minutes, I ping my ISP before running fetchmail. (My script is set up so that when I get "0% packet loss" on a sequence of 4 pings, it runs fetchmail (and then sendmail -q to kick the queue).) Fairly often (several times a day?), I get one or more pings with an error message like: wrong data byte #0 should be 0x59 but was ... (see complete ping response, below:) Complete ping response: PING 206.245.176.211 (206.245.176.211): 56 octets data 64 octets from 206.245.176.211: icmp_seq=0 ttl=122 time=1099.4 ms wrong data byte #0 should be 0x59 but was 0x5858 ff 79 3d 79 6b a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 64 octets from 206.245.176.211: icmp_seq=1 ttl=122 time=268.4 ms 64 octets from 206.245.176.211: icmp_seq=2 ttl=122 time=283.4 ms 64 octets from 206.245.176.211: icmp_seq=3 ttl=122 time=251.6 ms In the above case, the wrong data byte occurred for only one of the pings -- in other cases it occurs for 2, 3, or 4 (all of the) pings, but usually (always?) for the earliest pings rather than the last pings. Questions: What is this telling me and/or how does it occur? This box is on a coax LAN, so I suppose it could be seeing TCP/IP traffic not meant for it -- is that likely to be the problem, or noise, or ??? What can I do to fix it? (I can't easily convert the LAN to TP as I'd have to run new cable which I prefer not to do in the near future -- maybe in a few years.) I suppose I should run a sniffer on the network, but there really should not be a lot of traffic. Can anybody recommend a sniffer that comes with Mandrake 7.2 or 8.2 (i.e., so I can install from an rpm)? thanks, Randy Kramer Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
