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
