The kernel maintains, for each network device, the total number of bytes and packets that were transmitted and sent. These counters are apparently only 32bit long, and thus wrap in common circumsntaces such as transmitting more than 4GB on an Ethernet device. The counters can be read using "cat /proc/net/dev", "ifconfig" and (presumably) various system monitoring tools. Since the kernel currently reports false data without warning, this can have unfortunate consequences. Consider, for instance, web colocation services that bill you by the gigabyte transferred -- you really want your statistics to be reliable. How reproducible: Always Steps to Reproduce: While I observed this happening on Ethernet interfaces, it's easiest to reproduce with the "lo" interface. Here's a sample transcript, obtained on my RedHat 7.3 box. I used NetCat to pump /dev/zero data over the "lo" interface, stopping it manually after a few seconds. As you can see, the byte counters rolled over. $ cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo:4162190490 633694 0 0 0 0 0 0 $ nc -v -l -p 1234 > /dev/null & sleep 1; nc -v 127.0.0.1 1234 < /dev/zero [1] 31365 listening on [any] 1234 ... connect to [127.0.0.1] from localhost [127.0.0.1] 37222 localhost [127.0.0.1] 1234 (?) open punt! [1]+ Done nc -v -l -p 1234 >/dev/null $ cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo:75993510 665305 0 0 0 0 0 0
Counters *will* wrap no matter how big. That's why the ip traffic accounting program takes that into account...
> Counters *will* wrap no matter how big. That's why the ip traffic accounting > program takes that into account... Uhm, sorry to nag, but -- which accounting program are you referring to, and how does it take that into account, if the information is long lost? Also, indeed all counter eventually wrap, but a 64bit counter will take about 2000 years to wrap on fully utilized OC48 channel (2.48Gbit), while a 32bit counter may wrap within a couple of hours on a 10Mbit ethernet!
iptraf
iptraf starts all its statistics gathering from 0. It "solves" the wrap around problem by sampling the counter very often, so it needs to be running continuously. It thus cannot answer the simple yet useful question "how many bytes did this interface transmit since it went up", unless it happened to be running all along.
iptraf doesn't wrap the counters -> works for me