Reading network interface data in linux

[Edvard Majakari]

Suppose one wants to fetch the following data from given network interface,
say, eth0:

Ethinf('eth0'). addr() '192.168.1.42/24' Ethinf('eth0'). route('default' ) '192.168.1.1' Ethinf('eth0'). duplex() 'full' Ethinf('eth0'). speed() 100

Some statistics:
Ethstat('eth0') .rx_bytes() 14325235341223 Ethstat('eth0') .tx_bytes()

2513152423

One could implement modules by installing eg. ethtool and reading speed/duplex
information by parsing ethtool output, but it is ugly way to do it, prone to
errors, requires launching a process as well as installation of ethtool.

As for the byte counts, you could get all information ifconfig show by reading
/proc/net/dev (which is more nice to parse), but it seems like those counters
are 32-bit, and they wrap around quite quickly in a 1000 gbit network (~30
seconds).

I was wondering is there really no module implemented which already does those
things?

I've already implemented a proto by doing exactly as I told (parsing ethtool &
/proc/net/dev), but I strive for more elegant solution. I'm willing to join
the effort with someone else, if possible.

--
#!/usr/bin/perl -w
$h={23,69,28,'6 e',2,64,3,76,7, 20,13,61,8,'4d' ,24,73,10,'6a', 12,'6b',21,68,1 4,
72,16,'2c',17,2 0,9,61,11,61,25 ,74,4,61,1,45,2 9,20,5,72,18,61 ,15,69,20,43,26 ,
69,19,20,6,64,2 7,61,22,72};$_= join'',map{chr hex $h->{$_}}sort{$a<= >$b}
keys%$h;m/(\w).*\s(\w+)/x;$_.=uc substr(crypt(jo in('',60,28,14, 49),join'',
map{lc}($1,subs tr $2,4,1)),2,4)." \n"; print;

[Jorgen Grahn]

On Wed, 13 Jul 2005 11:09:57 +0300, Edvard Majakari <ed*********@ma jakari.net> wrote:

Suppose one wants to fetch the following data from given network interface,
say, eth0:

Ethinf('eth0'). addr() '192.168.1.42/24' ....

Ethstat('eth0') .rx_bytes()

14325235341223

.... One could implement modules by installing eg. ethtool and reading speed/duplex
information by parsing ethtool output, but it is ugly way to do it, prone to
errors, requires launching a process as well as installation of ethtool.

On the other hand, I have a hunch that the interface that ethtool uses is
unstable, changes between major kernel versions, varies with the kind of
hardware you have, etc.

If that is the case, you might want to keep parsing ethtool's output. Letting
/them/ worry about tracking kernel changes would actually be the most stable
solution. The ethtool authors are kernel developers, and probably know all
that stuff.

Or convince the ethtool authors to release future ethtool versions as a
Python module with an optional command-line interface ;-)

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!