Date: Tue, 28 May 1996 07:12:53 +0100 From: "Gary Palmer" <gpalmer@FreeBSD.ORG> To: "Marc G. Fournier" <scrappy@ki.net> Cc: current@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: snmp for FreeBSD... Message-ID: <8798.833263973@palmer.demon.co.uk> In-Reply-To: Your message of "Mon, 27 May 1996 19:53:28 EDT." <Pine.NEB.3.93.960527195129.11370A-100000@ki.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Marc G. Fournier" wrote in message ID
<Pine.NEB.3.93.960527195129.11370A-100000@ki.net>:
> clean sources: ftp.ece.ucdavis.edu:/pub/snmp/ucd-snmp.tar.gz
> diff against: ftp.ki.net:/pub/users/scrappy/ucd-snmp.3.1-diffs.gz
First impressions ... it doesn't work (properly). I couldn't get the
client s/w to work (perhaps I was driving it wrong, I'll look at that
later), so I used the tkined snmp interface to check out the snmpd.
First thing that happened (on a default MIB walk, nothing special at
all) was that the daemon went into an infinite loop trying to figure
out how many TCP connections are open. Not QUITE sure why, as gdb
attaching to the process seems to make the error go away, though it
still doesn't walk to TCP protocol block list right. The ARP querying
code (by the authors own admission) has been disabled (see the example
below, the ifPhysAddress is blank), and several other bits probably
aren't 100% (I would probably convert it to use libkvm if nothing
else).
If this WAS brought in ``officially'' I'd probably like to see some
kernel changes made to better accomodate SNMP queries. The following
output is from a hacked up version of the daemon, patches being sent
to Marc under separate cover.
e.g. (from my machine, captured from tkined) (lines truncated to make
them more readable)
Instance ifDescr ifInOctets ifLastChange [ ... ] ifSpeed ifOutUcastPkts
1 ed0 0 0d 19:09:15.10 [ ... ] 0 1
2 lp0 0 0d 0:00:00.00 [ ... ] 0 0
3 lo0 2939552 0d 0:00:00.01 [ ... ] 0 9642
4 sl0 0 0d 0:00:00.00 [ ... ] 0 0
5 sl1 0 0d 0:00:00.00 [ ... ] 0 0
6 tun0 3629164 0d 0:00:00.00 [ ... ] 115200 12890
7 tun1 0 0d 0:00:00.00 [ ... ] 0 0
Instance ifOutOctets ifType ifPhysAddress
1 308 ethernet-csmacd 00:00:00:00:00:00
2 0 34 00:00:00:00:00:00
3 2965424 softwareLoopback 00:00:00:00:00:00
4 0 slip 00:00:00:00:00:00
5 0 slip 00:00:00:00:00:00
6 3970120 ppp 00:00:00:00:00:00
7 0 0 00:00:00:00:00:00
I would like to see that ifLastChange field filled PROPERLY. The hack
that I have at the minute uses ifnet.iflastchange, which under *BSD
seems the mean the last time the ifnet record was updated, which is
NOT what SNMP wants. From the MIB:
The value of sysUpTime at the time the interface entered its current
operational state. If the current state was entered prior to the last
re- initialization of the local network management subsystem, then
this object contains a zero value.
So this is NOT when the last packet was sent/received (my ether, ed0,
is quiet, hence it actually has a sensible ifLastChange. lo0, on the
other hand, is being used to send/receive the packets for the SNMP
queries, so was last changed now :-( ).
SNMP also seems to make a differentiation between output/input octets
(bytes) for multicast and non-multicast packets. If my understanding
of our kernel is right, all the octets input/ouput are classed into
one category (ibytes and obytes), which sort of spams the SNMP
query. The code actually has a hack which assumes that the average
packet is 308 bytes, and calculates ifInOctets & ifOutOctets by
multiplying ifInPackets and ifOutPackets by 308 ... :-(
The other parameter which seems bogus (at least to me) is the ifSpeed
field. I used the ifnet.baudrate field to give the ifSpeed value,
which works for my PPP link, but not for my ether... Surely my 10b2
ethernet should be 10,000,000? (the comments in /sys/net/if.h just say
``linespeed'' for ifnet.baudrate, which to me, at least, means that
ethernet drivers should fill in that field too).
And I think we should get a FreeBSD vendor ID (if that is the right
term) so we can hook bits into the MIB at an ``official'' level, such
as our sysctl i/f and so on.
Comments?
Gary
P.S. Is type 34 for lp0 (the parallel port TCP/IP i/f) a valid value
in terms of SNMP?
--
Gary Palmer FreeBSD Core Team Member
FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8798.833263973>