Date: Tue, 16 Apr 1996 08:19:20 -0400 From: Peter Berger <peterb@hoopoe.psc.edu> To: netbsd-bug@netbsd.org Cc: freebsd-hackers@freebsd.org Subject: NetBSD Kernel not RFC compliant. Message-ID: <199604161219.IAA05533@hoopoe.psc.edu>
next in thread | raw e-mail | index | archive | help
Actually, this is a bug in 4.4 BSD; BSDi has the same problem. I would guess that it affects FreeBSD also. I originally thought this was a bug in ISODE, but they point the finger at the kernel, and looking at the code (for example in net/if_ethersubr.c, among others,) I see that they are right -- if_lastchange is given the value of "time" as each packet comes in (or goes out!), which is just wrong, as the mere arrival or sending of a packet shouldn't count as a state change for purposes of this variable. We encountered this non-compliance when setting up automated monitoring of our network. I look forward to this being fixed in the next release! Peter > > Dear ISODE folks: > > > > Unless I am mistaken, the Isode-8.0 snmpd does not properly handle the > > ifLastChange variable. > > > > Regarding the ifLastChange variable, RFC 1156 says: > > > > OBJECT: > > ------- > > ifLastChange { ifEntry 9 } > > > > Syntax: > > TimeTicks > > > > Definition: > > 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. > > > > Access: > > read-only. > > > > Status: > > mandatory. > > > > As you can see, the RFC calls for the variable to contain the value of > > sysUpTime, in timeticks, -at the time the interface became > > operational-. Currently, the ISODE-8.0 snmpd seems to assign this > > variable the number of timeticks SINCE the interface became > > operational. Although the difference is subtle, this has an extremely > > negative effect on SNMP monitors which depend on the value of > > ifLastChange being RFC-compliant in order to perform traffic analysis > > or decide when to clear their counters. > > > > If there has been an update to RFC 1156 that changes this requirement, > > or a patch to ISODE that fixes this problem, I would be very glad to > > know about it. > > > > Thanks very much, > > > > Pete Berger > > Coordinator, Regional Information Infrastructure > > Pittsburgh Supercomputing Center > > Thank you for this report. > > I don't have ISODE 8.0 sources available (it is very old now). > > The current IC release has the following code for ifLastChange, in > interfaces.c: > > #ifdef ifLastChange > case ifLastChange: > if ((diff = (ifn -> if_lastchange.tv_sec - my_boottime.tv_sec) > * 100 > + ((ifn -> if_lastchange.tv_usec - > my_boottime.tv_usec) > / 10000)) > < 0) > diff = 0; > return o_number (oi, v, (caddr_t) &diff); > #endif > > This code is only included if ifLastChange is defined, and it is only defined > if BSD44 is defined. As the Reference Platform (SunOS 5) is not compatible > with this, our reference platform does not have this feature. > > I also note that the if_lastchange time is not set anywhere in the snmp code. > It must therefore be provided by the system code. not having a BSD44 system. > I don't know what the semantics of if_lastchange are, i.e. what time it > returns, > but if the result of this operation does give the difference between the > interface's 'lastchange' time and the 'my_boottime', which seems to fit the > definition you give from the RFC. I.e. the code just reports back from the > interface the difference between this timer and the boot time. If this timer > is not what you expect, this is not a result of the snmp code. > > regards >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604161219.IAA05533>