On 01/02/2008, yuchen lu <[EMAIL PROTECTED]> wrote: > "snmpgetnext -v2c -c amail 4.4.4.3 hrStorageUsed.3" > "HOST-RESOURCES-MIB::hrStorageUsed.10 = INTEGER: 93208" > > again, the index 6,7,8 seems to be jump over.
That's correct. The "used" value is not available for these three storage areas. (though I haven't traced through the code to check exactly why). It is perfectly reasonable for a table to contain "holes", where a particular column doesn't have a value in a given row. An application that works with tables has to be ready for this. Note that 'snmpgetbulk' is a general purpose tool, so doesn't make any assumptions about the relationship between the MIB objects that you specify. They don't necessarily all refer to rows with the same index values. If you try querying this table with the "snmptable" tool (which *is* designed to handle MIB instances with a common index), you'll see that it displays '?' instead of these missing values. > It looks like that it couldn't get the usage information for the > device type "hrStorageOther", Correct. > but I suppose "null" or "0" should be returned instead No. The agent can't return a value of '0', because that isn't the right value for this object. If the agent doesn't know the correct value, then it shouldn't lie. If you issue a GET request for any of these instances, then the agent will indeed return a "null"-style value (more strictly a 'noSuchInstance' exception, assuming SNMPv2c/3). But the behaviour of GETNEXT is defined as returning the "next available value" - so it must skip over any missing values (which is exactly what is happening here). There have been suggestions to amend the SNMP protocol to fill in such holes with "noSuchInstance" exceptions (or similar). But nothing actually came of such suggestions, and we can't really change Internet standards unilaterally! :-) > ... or "hrStorageOther" devices should be filtered out. Well, the agent filters out the information that isn't available (hrStorageUsed). It seems a bit drastic to filter out the *whole* row, just because one column isn't available! (Particularly given that every single row is missing the final column). Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
