On 15 September 2011 00:34, Martin T <m4rtn...@gmail.com> wrote: > in case I saw only few generic values, I used following command: > > snmpwalk -v 1 -c public -On I.I.P.P
i.e. no explicit starting point. In this case, snmpwalk will assume .1.3.6.1.2.1 so won't attempt to look under the enterprise tree. > However, if I don't specify the > <enterprise number> and execute: > > snmpwalk -v 1 -c public -On I.I.P.P .1.3.6.1.4.1 > > ..I got no replies. That looks like a bug in the agent. > So the main questions was, are there some sort of > techniques out there to find out OID values under .1.3.6.1.4.1 and the > answer seems to be: > > snmpgetnext -v 1 -c public -On I.I.P.P .1.3.6.1.4.1 > > ..if SNMP agent is implemented properly :) Correct. (There's also a possible issue where the choice of community string may affect what you can see. But if walking a particular enterprise tree works using v1/public, then walking .1.3.6.1.4.1 should too) > In addition, in case of this radio device, it really seems to behave > incorrectly. Check this: > > martint@ibm:~> snmpwalk -v 1 -c public -On 10.10.10.1 .1.3.6.1.4.1 > martint@ibm:~> snmpgetnext -v 1 -c public -On 10.10.10.1 .1.3.6.1.4.1 > .1.3.6.1.2.1.1.1.0 = STRING: SAF microwave radio That's definitely wrong, and explains why snmpwalk is giving you nothing. > Is there some RFC I could point to when contacting the vendor > regarding this odd behaviour where snmpgetnext under > ".iso.org.dod.internet.private.enterprise" gives the value from > ".iso.org.dod.internet.mgmt.mib-2"? It's a fairly clear violation of the basic operation of how GetNext is meant to work. If you want an explicit reference, try the Elements of Procedure for SNMP, as defined in RFC 1157. Section 4.1.3 says (after three numbered bullet points discussing error handling): If none of the foregoing rules apply, then the receiving protocol entity [agent] sends .... [a] GetResponse-PDU [that] represents the name and value of that object whose name is, in the lexicographical ordering of [all supported objects], the immediate successor to that [requested] value. .1.3.6.1.2.1.1.1.0 is not a lexicographic successor to .1.3.6.1.4.1 (immediate or otherwise) > PS thank you for explaining regarding vendor-specific MIB files! > I always thought they have some deeper meaning than only > translating OID's to semi-meaningful names :) They are also a design document for the MIB and application developer. Which is why I alsways shudder when people try to extend the agent without having a MIB to work from. Design your application *before* writing the code - not afterwards! Something many of our students seem congenitally incapable of :-( Dave ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
