lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 29 Jun 2007 11:21:54 -0700
From:	David Stevens <>
To:	Andi Kleen <>
Cc:, Chris Snook <>,
	Linux Network Development list <>,
	Rick Jones <>
Subject: Re: a maze of twisty stats, most different wrote on 06/29/2007 10:30:23 AM:

> David Stevens <> writes:
> > I think there's a more general problem that's a huge hassle. There are 

> > lots of
> > new SNMP MIB's, but no conventions (that I'm aware of, at least) to 
> > for
> > changes to the /proc entries that get them to applications. 
> Actually /proc/net/snmp and netstat -s are extensible. If you add a new
> MIB or field there it should just show up in netstat -s. It won't know 
> the text decoding that is done for the early traditional MIBs, but that
> is already not there for most of the newer fields.

That works ok for some things, like new global counters, but some
items really fit best in existing files and the concern there is about
other uses of them beyond the standard tools.
-addition of route age in /proc/net/route and /proc/net/ipv6_route
-per-group data in /proc/net/igmp & igmp6
-per-interface MLD MIB info, which ought to go with other per-interface 

        I think everything that uses this kind of interface ought to do
label matching, so additional columns in a row (anywhere in the row)
would just be skipped/ignored by things that don't understand them,
and similarlarly for single-row tagged items. You can do that in scripts
with awk, but if existing items don't, they'll break.
        On the other hand, we don't want to create a new instance for
every addition or modification, so it seems the middle ground is to
go with new entries now and state that scripts and code that don't
match tags and handle changes in the format in the future are broken.
        We could dump everything in /proc/net/snmp{,6}, of course,
but I'm not sure it's a good idea to replicate all the routing and 
data that is not there now just to get a few additional fields for those


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists