Greetings,
We have written a subagent based on snmpd_5.4.3-dfsg-2+squeeze1_xxx.deb on both
i386 and armel systems.
We are having a problem that appears to be caused by the order in which we
register handlers using:
netsnmp_handler_registration* reginfo =
netsnmp_create_handler_registration(name,
generic_snmp_access_method,
(oid*)snmpOid.getOid(),
snmpOid.getLength(),
accessLevel);
reginfo->handler->myvoid = NULL;
netsnmp_register_scalar(reginfo);
If the order of calls is wrong, then we cannot snmpwalk the entire tree. We
believe that there may be a bug in 5.4.3 that doesn't properly track the
correct MODE_GETNEXT entry. We do not experience the issue on 5.7.2 for example.
The trouble is that we do not know apriori which handlers will be available at
runtime, so we register them only as they become available.
Our hope is to work around the issue by keeping track of which handlers are
available and then deregistering and reregistering handlers as necessary so
that we can ensure that we can walk the entire tree.
What I need to know is the names of the functions that I can use to reverse
netsnmp_register_scalar(), and netsnmp_create_handler_registration()? A
netsnmp_deregister_scalar() and netsnmp_destroy_handler_registration() if you
will.
Peter.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
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