Dave, thank you for information!
regards, martin 2011/9/15 Dave Shield <d.t.shi...@liverpool.ac.uk>: > 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
