2009/2/28 EYRE Bernadette <bernadette.e...@alcatel-lucent.com>:
> One of my original problem was that when using snmpwalk command
OK - so you are using "snmpwalk".
That's definitely relevant here....
> on say a column (without any instance index) of one of the tables,
<grin>
That's pretty much what I expected, but you hadn't given sufficient
detail to confirm this.
> my subagent handler was getting called
> once with getnext and next with get mode.
That is the designed behaviour.
Think about what things look like from the user point of view.
If I run "snmpwalk ... system", I see everything within the system group
If I run "snmpwalk ... sysLocation", I see the (sole) sysLocation
value (sysLocation.0)
If I run "snmpwalk ... sysLocation.0", I would most naturally also expect to
see the sysLocation value (sysLocation.0)
Now think about what "snmpwalk" actually does (basically sends a sequence of
GETNEXT requests), and what this will look like from the agent side:
Leaving "snmpwalk ... system" to one side, consider the other two cases:
"snmpwalk ... sysLocation" sends a request "GETNEXT sysLocation"
which will return sysLocation.0
The app will display this result, and send a request "GETNEXT
sysLocation.0"
(since it doesn't know whether there are any more relevant
results to come)
which will return sysServices.0
This is outside the requested subtree, so snmpwalk discards it, and stops.
"snmpwalk ... sysLocation.0" sends a request "GETNEXT sysLocation.0"
which will return sysServices.0
This is outside the requested subtree, so snmpwalk discards it, and stops
**without** displaying any results.
Eh? But we were expecting to see the "sysLocation.0" value???
Missing this value makes sense in terms of the SNMP protocol operations,
but not from the point of view of the person actually using this tool.
(Which is rather more important!)
So snmpwalk explicitly checks for an "out-of-range" response from the
very first request, and follows this up with a GET request on the original
starting point. So this last example now becomes:
"snmpwalk ... sysLocation.0" sends a request "GETNEXT sysLocation.0"
which will return sysServices.0
This is outside the requested subtree, so snmpwalk discards it,
and sends a request "GET sysLocation"
which will return sysLocation.0
The app will display this result, and stops.
As expected.
Now apply this to your own situation:
"snmpwalk ... myColumn" sends a request "GETNEXT myColumn"
The agent conglomeration recognises that "myColumn" is empty,
so returns the next valid instance (say "myNextScalar.0")
This is outside the requested subtree, so snmpwalk discards it,
and sends a request "GET myColumn"
which will return noSuchInstance
The app will report this failure, and stops.
So yes - this is the expected behaviour in this case.
But the important factorhere is that the requested subtree was empty
(which is the information you hadn't provided before)
Dave
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
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
