On 16 March 2012 22:03, Charlie Martin <crmar...@sgi.com> wrote:
> Now I try an snmpwalk
>
> 1006 $ snmpwalk -On -v 2c -c copan psmdev1 1.3.6.1.4.1.59.1.5.3.1.1.2
> .1.3.6.1.4.1.59.1.5.3.1.1.2 = STRING: "91"
>
> Observe that it gets back only one reply
Yes - that is correct.
Snmpwalk says "give me everything starting with .1.3.6.1.4.1.59.1.5.3.1.1.2"
The only valid instance within this tree is .1.3.6.1.4.1.59.1.5.3.1.1.2
itself - so that's what snmpwalk reports.
As Vincent points out, walking the slightly shorter starting OID
.1.3.6.1.4.1.59.1.5.3.1.1 will give you everything within this subtree.
Though I'm not convinced that the MIB you are walking is valid.
If these are a series of scalar objects, then the OIDs should all end in .0
If they are part of a table, then all the values for a particular column
object should be of the same type.
So results like
.1.3.6.1.4.1.59.1.5.3.1.1.1 = INTEGER: 1
.1.3.6.1.4.1.59.1.5.3.1.1.2 = STRING: "91"
.1.3.6.1.4.1.59.1.5.3.1.1.3 = STRING: "42"
look bogus to me.
What is the definition of the MIB tree based under {sgi}.1.5.3.1 ?
> Let's assume that 1.3.6.1.4.1.59.1.5.3.1.1.10 is the numerically
> (as opposed to lexicographically) highest OID in the
> 1.3.6.1.4.1.59.1.5.3.1.1 subgroup.
Err... what do you mean by that?
The numerically highest OID *is* the lexicographically highest.
>How should the agent respond to
>
> $ snmpwalk /*args*/ 1.3.6.1.4.1.59.1.5.3.1.1.10
Vincent's answer is basically correct - with one minor tweak
VB> Just 1.3.6.1.4.1.59.1.5.3.1.1.10 = somevalue
VB> (and this is because snmpwalk do a GET request
VB> before starting doing GETNEXT requests).
snmpwalk actually issues the GET request *after* the
sequence of GETNEXT requests - and then only if the
first (and hence only) such request returns an answer
that's outside the desired range.
For example
"snmpwalk ... .1.3.6.1.4.1.59.1.5.3.1.1"
might expand to
GETNEXT ...59.1.5.3.1.1 -> ...59.1.5.3.1.1.1
GETNEXT ...59.1.5.3.1.1.1 -> ...59.1.5.3.1.1.2
GETNEXT ...59.1.5.3.1.1.2 -> ...59.1.5.3.1.1.3
:
GETNEXT ...59.1.5.3.1.1.9 -> ...59.1.5.3.1.1.10
GETNEXT ...59.1.5.3.1.1.10 -> ...59.1.5.3.1.2.1
<stop>
while
"snmpwalk ... .1.3.6.1.4.1.59.1.5.3.1.1.10"
would expand to
GETNEXT ...59.1.5.3.1.1.10 -> ...59.1.5.3.1.2.1
GET ...59.1.5.3.1.1.10 -> ...59.1.5.3.1.1.10
<stop>
Dave
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
