------- Forwarded Message

Date: Tue, 16 Apr 1996 08:20:27 -0400 (EDT)
From: Mail Delivery Subsystem <MAILER-DAEMON>
Subject: Returned mail: User unknown
Message-Id: <199604161220.IAA05535@hoopoe.psc.edu>
To: <peterb@hoopoe.psc.edu>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
	boundary="IAA05535.829657227/hoopoe.psc.edu"
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

- --IAA05535.829657227/hoopoe.psc.edu

The original message was received at Tue, 16 Apr 1996 08:19:20 -0400 (EDT)
from peterb@LOCALHOST [127.0.0.1]

   ----- The following addresses have delivery notifications -----
<netbsd-bug@netbsd.org>  (unrecoverable error)

   ----- Transcript of session follows -----
... while talking to pain.lcs.mit.edu.:
>>> RCPT To:<netbsd-bug@netbsd.org>
<<< 550 <netbsd-bug@netbsd.org>... User unknown
550 <netbsd-bug@netbsd.org>... User unknown

- --IAA05535.829657227/hoopoe.psc.edu
Content-Type: message/delivery-status

Reporting-MTA: dns; hoopoe.psc.edu
Received-From-MTA: dns; LOCALHOST
Arrival-Date: Tue, 16 Apr 1996 08:19:20 -0400 (EDT)

Final-Recipient: rfc822; netbsd-bug@netbsd.org
Action: failed
Status: 5.2.0
Remote-MTA: dns; pain.lcs.mit.edu
Diagnostic-Code: smtp; 550 <netbsd-bug@netbsd.org>... User unknown
Last-Attempt-Date: Tue, 16 Apr 1996 08:19:55 -0400 (EDT)

- --IAA05535.829657227/hoopoe.psc.edu
Content-Type: message/rfc822

Message-Id: <199604161219.IAA05533@hoopoe.psc.edu>
To: netbsd-bug@netbsd.org
Cc: freebsd-hackers@freebsd.org
Subject: NetBSD Kernel not RFC compliant.
Reply-To: peterb@psc.edu
Date: Tue, 16 Apr 1996 08:19:20 -0400
From: Peter Berger <peterb@hoopoe.psc.edu>


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
> 

- --IAA05535.829657227/hoopoe.psc.edu--


------- End of Forwarded Message