Does TableUtils handle table holes?

SNMP4J
1

I came across holes in an SNMP table:
https://net-snmp.sourceforge.io/wiki/index.php/TUT:snmptable#Holes_in_Tables
NET-SNMP “snmptable command will handle such holes automatically, filling in any such missing values”.
I don’t see SNMP4J TableUtils handles table holes. We are using SNMP4J v.2.6.3.
Does the newer version step over these missing values and return the value of that column from the next row where it does exist?
Thanks!

2

SNMP4J’s TableUtils support sparse tables (= tables with ‘holes’). A TableEvent object returned for a sparse row (a row with missing columnar object instances) will contain a null VariableBindung for those columns.

  • I do not understand what you are missing?
  • Can you provide more details or an example?
3

When I call SNMPUtils.getTable, the table data (2 columns) looks like this:
7.7.0.27 1.1.27
7.7.0.28 1.1.28
null 1.1.29
7.7.0.29 1.1.29
When I call NET-SNMP’s snmptable, NET-SNMP does not return the row with the missing value:
7.7.0.27 1.1.27
7.7.0.28 1.1.28
7.7.0.29 1.1.29
NET-SNMP sees the hole, steps over to the next row and return the value of that missing column value from the next row.
Thanks, Frank!

4

I think in your specific case, the agent has a severe problem of lexicographic ordering its OIDs. When it would return them in correct order the response pattern would be the following, if there is really a hole in the table:

or in case, there are all values available:

If I understand the NET-SNMP behaviour correctly, it tries to repair misbehaving agents by “guessing” what is going wrong and retrying to get the correct value on different ways.

SNMP4J can do this too, if you set the sparseTableMode to SparseTableMode.denseTableDoubleCheckIncompleteRows. Then SNMP4J will retry to fetch missing columns from the GETBULK/GETNEXT with GET requests.

But this has nothing to do with real “sparse tables”. It is just a method to correct agent failures that are unfortunately rather common. Of course, this error correction has a huge performance impact if the lexicographic ordering bug in the agent affects many column instances of a table and therefore it is not activated by default!