WH> The SNMPv3 specifications say that a running manager should allow its WH> notion of an agents clock values to go forward, but not backward. Thus, WH> we're doing what we're supposed to do: we won't accept *older* values WH> than what we have cached (but would accept newer values). So, we're WH> following the specifications.
After days of painstaking UDP packet captures, I have found that we are having a similar issue. Now, I see that net-snmp is following RFC3414's spec, which is very helpful to us, but now I need to be able to provide for this situation. Currently, most of our customers do not use SNMPv3; however, more and more are. Our polling process polls thousands of SNMP devices, and it is designed to run forever. Is there a way to get back this information from the net-snmp library? I would like to be able to either send a trap or write out a message to a log stating the problem (and the three relevant values: engineId, engineBoots, and engineTime). This way, our customers could pro-actively address a problem that would result in zero SNMP communication. If they cannot repair the problem on their side, is there a way to instruct net-snmp to destroy its beliefs about a certain SNMPv3 engine ID? These two capabilities would make supporting SNMPv3 much easier for both ourselves and our customers. Thanks, Doug ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
