On 2004-12-06 15:32, Gerald Heinig <[EMAIL PROTECTED]> wrote: > Hi all, > > I've run into a possible bug in ping(8) while investigating a strange > duplicate packet effect in our driver. > The effect shows up on other drivers and I believe it's due to a counter > overflow in ping. > Basically, leave ping -f on a gigabit link for a few days (for medium to > large values of "a few", ie. at least 3 or 4). Stop the ping and get > lots of duplicate packets. > I changed the 5 counter variables (nmissedmax, npackets, nreceived, > nrepeats, ntransmitted) to short (from long) to reduce the time taken to > overflow and managed to get the effect very easily - it takes about 3 > seconds on a gigabit link. > Changing these variables to their unsigned counterparts solved the problem. > My question: shouldn't these counters be unsigned? (ie. unsigned long, > instead of long)
They can probably be switched to uint64_t too. I'm not sure how much time this will buy us though on links with so very high speeds. A quick calculation with a link that can push 8 Mpps indicates it will take a few dozen thousands of years to overflow a 64-bit counter, unless my Python-foo has failed me: >>> (2**64) / (365*24*3600*8000000) 73117L _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
