Anyway if it really is returning noSuchName then ...
The scotty walk command uses a multi-varbind GETNEXT request, with one
varbind per variable specified in the argument list. The SNMP agent should
always return the lexi-next successor to each requested variable. As an
extreme example consider an agent which does not implement the ifMtu object
at all, but does implement ifType and ifSpeed objects for all interfaces.
[Note I am off-line while typing this and I am assuming the ifType and
ifSpeed are the objects either side of ifMtu - if they are not then just
pretend that they are :-]
Let's say the agent has at least one interface.
"GETNEXT ifType ifMtu ifSpeed"
Should return the first "row", i.e.
ifType.1 ifMtu.1 ifSpeed.1
but because this agent does not implement ifMtu what you should get is:
ifType.1 ifSpeed.1 ifSpeed.1
Why? Because ifSpeed.1 is the lext-next successor to ifMtu.anything if you
do not implement ifMtu object.
What you should NOT get is:
ifType.1 noSuch ifSpeed.1, which for a V1 implementation maps to a
noSuchName error code, error index set to 2 and all varbinds untouched.
The only time you should get a noSuchName in response to an SNMP GETNEXT
request is when one of the requested varbinds has no successor in the MIB
(view). Typically this is not the case (i.e. there is usually something
else somewhere later on in the MIB to which you would have read access at
least).
I must say, however, that the correct response is not a lot more helpful
than the one you are getting; you will need to unravel the responses and
handle the "holes". I do not think that the scotty walk command will lend
itself to this approach; instead you will need to use a loop and some
getnext commands instead.
Hope this helps,
Robin
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.