Re: Unexpected agent behaviour when walking a MIB

Dave Shield <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <CAKoMtGZjkRRG93sSW2XhGsxjtx+nOQZxYb3EiuL1O26n=z3n2w@mail.gmail.com>
On 14 September 2011 09:21,  <[email protected]> wrote:
> This doesn't make any sense. The call-back handler should be invoked with a
> mode indicating 'GetNext' and the OID 1.3.6.1.4.1.2257.11.1.1.1. Why is the
> mode being changed from 'GetNext' to 'Get'?

I haven't done much (if anything) with implementing modules in perl,
but this is fairly common with the C handler-based implementations.
A number of the tables helpers have some knowledge about which are
the valid row indexes, and so can convert a GETNEXT request into
the appropriate GET request (amending the OID accordingly).
    This means that the lowest level handler doesn't need to be concerned
about the "lexographical next" processing, and concentrate on GET and
SET handling of exact instances.

Similarly for the scalar object handlers (since again, the valid instances
are known).


I don't know whether there's anything similar for perl-based implementations.
You may need to give a bit more detail about exactly what your code looks like.



> At the very least the agent should not invoke the call-back handler with
> mode 'Get' on an object that is not an instance. This is not allowed in SNMP.

Two comments:
   First - "the agent" doesn't actually know what OIDs are objects, instances
or internal structure.   The only information that it has is a list of handlers
that have registered for particular OID ranges.
   If it received a request for an OID,  this will be passed to the appropriate
handler.   It's up to that handler (chain) to decide what to do with
the request.

   Secondly - it *is* allowed to issue a GET request on an OID that does
not correspond to an instance.   The result will typically be a noSuchInstance
or noSuchObject exception (or noSuchName error with SNMPv1),  but it's
a perfectly valid request.
   The SNMP protocol does not attempt to enforce the MIB structure onto
requests - that's left to the agent.

Remember - a valid instance OID for one agent may be invalid for another,
if they implement different MIBs.   The protocol cannot say anything about this.



Dave

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the 
BlackBerry&reg; mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry&reg; DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1 
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.