From owner-freebsd-current Mon May 27 23:14:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA04253 for current-outgoing; Mon, 27 May 1996 23:14:54 -0700 (PDT) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA04248; Mon, 27 May 1996 23:14:49 -0700 (PDT) Received: from palmer.demon.co.uk (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-1) with ESMTP id HAA08800; Tue, 28 May 1996 07:12:53 +0100 (BST) To: "Marc G. Fournier" cc: current@FreeBSD.ORG, wollman@FreeBSD.ORG From: "Gary Palmer" Subject: Re: snmp for FreeBSD... In-reply-to: Your message of "Mon, 27 May 1996 19:53:28 EDT." Date: Tue, 28 May 1996 07:12:53 +0100 Message-ID: <8798.833263973@palmer.demon.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Marc G. Fournier" wrote in message ID : > 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