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
