Response to getnext at netSnmp.1.3 is timeout. Response to get at
netSnmp.1.3, netSnmp.1.3.1, etc, is noSuchName (though it does give a name
for the first couple of them). 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.
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?
Larry Dickson
On 2/11/08, Dave Shield <[EMAIL PROTECTED]> wrote:
>
> On 23/01/2008, Larry Dickson <[EMAIL PROTECTED]> wrote:
> > attempting a subtree at netSnmp times out after
> > netSnmp.1.2.1.1.6.0.12.1.3.6.1.6.3.16.1.5.2.1.6.127 and
> > trying a getnext on this oid also times out.
>
> That's part of the nsModuleTable
> (in particular, an instance of the nsModuleTimeout column).
>
> > But a getnext on netSnmp.2 works correctly
>
> There's typically quite a lot of information between the nsModuleTable
> and netSnmp.2.
>
> What does GETNEXT on netSnmp.1.3 show?
>
> > However, there seems
> > to be no way to tell it to find later oids after the end of our subtree.
> I
> > could have sworn I once got .1.3.6.1.6.something but I can't seem to get
> > there now.
>
> You should be able to see .1.3.6.1.6.3.1.1.6.1.0
> (SNMPv2-MIB::snmpSetSerialNo.0)
>
> plus various other information under .1.3.6.1.6.3
> (e.g. the authentication and access control settings).
>
> 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
