From owner-freebsd-hackers Mon Nov 18 15:11:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20072 for hackers-outgoing; Mon, 18 Nov 1996 15:11:00 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA20047 for ; Mon, 18 Nov 1996 15:10:47 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.3/8.7.3) id QAA13632; Mon, 18 Nov 1996 16:10:39 -0700 (MST) From: Ade Barkah Message-Id: <199611182310.QAA13632@hemi.com> Subject: Re: Help: ucd-snmpd w/freebsd To: jc@irbs.com (John Capo) Date: Mon, 18 Nov 1996 16:10:39 -0700 (MST) Cc: hackers@freebsd.org, wesley.hardaker@sphys.unil.ch In-Reply-To: from "John Capo" at Nov 18, 96 06:03:24 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The result of the last request is cached by snmpd. I haven't looked > at the code to see if this is a feature or not. Query another > variable then query ifInOctets.1 again and you should see that it > has changed. John, Thanks for the reply. You're indeed correct... if I query the entire series with snmpwalk, the counters get changed as expected. I think this is a bug (other variables such as system.sysUpTime.0 do not exhibit the caching 'feature', nor do any other smtpd servers I have access to, such as Cisco and Xylogics boxes, cache these counters.) It doesn't make sense anyway to do so. Thanks again, -Ade Barkah ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - -------------------------------------------------------------------