Wow, that was amazing! I have been receiving these errors quite
frequently over the past week or so. I had no idea what they meant
until I read this. Thank you, it is relieving to hear that there is
nothing wrong with my hardware!
On Fri, 16 Mar 2001 04:40, Pierre Fortin wrote:
> Hi all,
>
> If this looks familiar, read on...
>
> 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
> wrong data byte #0 should be 0x3b but was 0x3737 da b0 3a 88 9e e 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
>
> See bug summary at bottom if you don't want to wade through all the
> gory details.
>
> Pierre
>
> =================== RACE BUG in PING =================
>
> I was having what appeared to be network problems and was, to say
> the least, SHOCKED to see the above ping putput...
>
> The thought of hardware going bad did not sit well... so, here's
> how I discovered that "ping" has a race bug...
< < S N I P > >
> 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...
--
Sridhar Dhanapalan.
"There are two major products that come from Berkeley:
LSD and UNIX. We don't believe this to be a coincidence."
-- Jeremy S. Anderson
