On 11/02/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> Response to getnext at netSnmp.1.3 is timeout.
OK - what about
GETNEXT netSnmp.1.5
GETNEXT netSnmp.1.7
GETNEXT netSnmp.1.9
What I'm trying to determine here is exactly *where* the blocking module
is located. If netSnmp.1.3 fails, and netSnmp.2 works, then it must be
somewhere between these two points.
The queries listed above are designed to test particular MIB modules.
> Response to get at
> netSnmp.1.3, netSnmp.1.3.1, etc, is noSuchName
That makes sense.
Those OIDs mark the top of the appropriate subtree, so wouldn't
have a value associated with them. It's only if you tried something
like
snmpget .... netSnmp.1.3.2.1.0
that I'd expect you to get an answer (nsExtendNumEntries.0)
> My guess is that whatever comes immediately
> after netSnmp.1.2.1.1.6.0.12.1.3.6.1.6.3.16.1.5.2.1.6.127
> is where the damage is.
And that's what I'm trying to pinpoint.
> But my question is also more algorithmic: How is it (the agent/subagent
> combination) supposed to do a getnext that jumps out of the subagent's
> subtree?
The subtree is given an OID, and returns the next value that it knows about.
The master agent looks at this result, and decides whether the OID falls within
the block registered by the subagent. If it does, then it returns that result
to the original client application, and everyone is happy.
If the subagent's answer comes *after* the end of the registered block, then
the master agent looks to see whether there's another MIB module which
has registered for a subtree before the returned OID. If there is, then the
master agent will send the query to that module instead.
It'll keep doing this until either it gets an acceptable answer, or it runs
out of MIB modules to ask.
Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
