--===============0761683080==
Content-Type: multipart/alternative;
boundary="----=_Part_7024_18260919.1201128510972"

------=_Part_7024_18260919.1201128510972
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,

I'm new at this and using a variant of version 5.2.1 (ca 2005-05-26). I'm
using iReasoning mib browser and/or snmpwalk and friends. Attempts to do
getnext at end of a subtree get inconsistent results. In the MIB
files, ucdavis = .1.3.6.1.4.1.2021 and netSnmp=.1.3.6.1.4.1.8072 - and given
that ucdavis subtree ends at ucdavis.101.101, the getnext of
ucdavis.102correctly is
netSnmp.1.2.1.1.4.0.1.0.0. But 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.12 7 and trying a
getnext on this oid also times out. But a getnext on netSnmp.2 works
correctly and goes to my company's enterprises subtree, which is handled by
an agentx subagent, at .1.3.6.1.4.1.22782. 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.

I looked at the Changelog for 5.4.1 and nothing seemed to speak to this
problem. RFC 2257 (AgentX) seems to expect it to be handled a priori by the
agent's registry, in sections 7.1.6 and 7.2.1.2 of the RFC for example, but
the net-snmp call to register a subagent does not seem to offer any way to
set an ending oid. Is this all well-known stuff to everyone but me? Surely
it can't be our subagent's fault - we don't touch ucdavis or netSnmp. TIA
for any hints, please!

Larry

------=_Part_7024_18260919.1201128510972
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,

 

I'm new at this and using a variant of version 5.2.1 (ca 2005-05-26). I'm using iReasoning mib browser and/or snmpwalk and friends. Attempts to do getnext at end of a subtree get inconsistent results. In the MIB files, ucdavis = .1.3.6.1.4.1.2021 and netSnmp=.1.3.6.1.4.1.8072 - and given that ucdavis subtree ends at
ucdavis.101.101, the getnext of ucdavis.102 correctly is netSnmp.1.2.1.1.4.0.1.0.0. But 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.12 7 and trying a getnext on this oid also times out. But a getnext on
netSnmp.2 works correctly and goes to my company's enterprises subtree, which is handled by an agentx subagent, at .1.3.6.1.4.1.22782. 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.

 

I looked at the Changelog for 5.4.1 and nothing seemed to speak to this problem. RFC 2257 (AgentX) seems to expect it to be handled a priori by the agent's registry, in sections 7.1.6 and
7.2.1.2
of the RFC for example, but the net-snmp call to register a subagent does not seem to offer any way to set an ending oid. Is this all well-known stuff to everyone but me? Surely it can't be our subagent's fault - we don't touch ucdavis or netSnmp. TIA for any hints, please!

 

Larry


------=_Part_7024_18260919.1201128510972--


--===============0761683080==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
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/
--===============0761683080==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

--===============0761683080==--