Just had an interesting time testing TRAP and INFORM handling with SNMP version 3 using net-snmp snmptrap utility.
Here is the summary of what I have learned over the last week and what the testing has confirmed.
SNMP Traps are handled like a response to a query. You get a packet, parse it using USM information for the specific agent and presto, you’ve got the notification information.
In the Trap packet, engineId, engineBoots, engineTime and securityName are set by the agent sending the trap so handling is relatively easy with the only difference being that you have to locally store engineId and securityName mappings to the correct authentication digest, privacy protocol and related secrets. Then, when the packet arrives, parse the USM header information, find the appropriate information for the authoritative engine that sent you the trap, apply the authentication and privacy parameters to the SnmpV3Packet class and call SnmpV3Packet.decode method.
While this is not as easy as request/response operation, it is not too hard.
SNMP version 3 Inform is a whole different game. In the Inform packet, engineId, engineBoots and engineTime are set to the manager values. This means that your application has to be able to respond to discovery packets.
This took a little while to figure out. With the use of SnmpV3Packet.GetUSM (and the unintended consequence of how I implemented this method) you can get all the values needed to generate a Discovery response. New SnmpV3Packet methods like IsDiscoveryPacket and DiscoveryResponse should help with implementing this functionality.
Only thing remaining to finish before version 0.5 is released is SNMP version 2 inform handling and testing. I’m planning to have it done and tested enough for release by the end of next week.
Keep checking the project page for news…