This is a follow-up to my previous question about not being able to walk the notification log mib. I now believe there is an actual problem related to the 5.3.1 code and its internal table walking.
The notification log mib as specified in the RFC and as implemented in the code does not fully populate all columns. If I populate each of the columns in the nlmLogTable row, I can then walk the nlmLogTable. By careful interpretation of the RFC I believe this is still compliant. However, the RFC specifically states that for the nlmLogVariableTable that only the object identified by nlmLogVariableType should exist - none of the other columns should be instantiated. This means that the same trick I did for nlmLogTable can not be applied to the nlmLogVariableTable because it would result in a non-conformant implementation.
So the question is, is the internal handling of tables in the 5.3.1 code busted because the GETNEXT processing does not cross non-existent columns or is the notification log mib implementation busted because it uses the internal data handlers for data that is too complex for that codes GETNEXT processing?
Does anybody have any clues/opinions on this?
Jeff
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ 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
