Hi Dave and Wes, So do I conclude my requirement as follow: Requirement: As I do the discovery to send the inform request Conclusion: 1. I will send the inform request for engine ID probeing 2. Inform request will be framed as describe in RFC 3414 "This may be accomplished by generating a Request message with a securityLevel of noAuthNoPriv, a msgUserName of zero-length, a msgAuthoritativeEngineID value of zero length, and the varBindList left empty." [as per rfc 3414 section 4] Please add your comments. Rgds, Sanjay Wes Hardaker wrote: On Tue, 6 Apr 2010 11:17:21 +0100, Dave Shield <d.t.shi...@liverpool.ac.uk> said:Approach 1. If we send get request with engine id NULL(engine id discovery process) , then no response will come. Lets assume our retry is 3, then we will send 3 get request for engine id discovery. As response has not come, we will not send the snmp informIf you read RFC3414 section 4 you'll see, by the way, that an empty engineID is indeed the right thing to send. The agent should respond to any incorrect engineID the same way, but I'd stick with the empty value as the "correct" way just to be sure.DS> What I'm not 100% sure about is what happens if snmptrapd *is* running. DS> It would reject a GET request anyway, since it's a trap receiver, not an DS> SNMP agent. But you'd need to work through the SNMPv3 Elements of DS> Procedure very carefully to check whether the engineID probe handling DS> is done before the invalid PDU is rejected, or not. It's supposed to be handled in the SNMP engine itself and, again, RFC3414 says to use "a Request message" which could be either a trap or an inform. Within Net-SNMP we'll accept either as it's caught long before the application is hit. That being said, it might be safest to send the type of packet you expect to eventually send to ensure other trap receiving implementations that behave differently don't throw out the packet because it's a GET (they shouldn't be, but.....)Approach 2: If we send snmp inform with wrong engine id(complete snmp inform with all varbinds like device status, time etc), then also no response will come. Lets assume our retry is 3, then we will send snmp inform(with wrong engine id and complete varbinds details) 3 times.DS> This feels safer - you're sending a probe request that would be DS> accepted as valid by the receiving engine. If there is an implementation out there that is being very strict about engineID probing it could drop this message because it wasn't following the letter of the text which says "and the varBindList left empty". It'd be safest to send *ONLY* what RFC3414 section 4 describes if you want to talk to any SNMPv3 implementations that exist. I would use an INFORM instead of a GET as discussed above, but both should be legal. Some other things to note: 1) make sure you understand the difference in engineIDs for traps vs informs ( http://www.net-snmp.org/wiki/index.php/TUT:snmptrap_SNMPv3) 2) make sure you understand the security ramifications of even using engineID discovery in the first place: http://pontifications.hardakers.net/computers/limitations-of-snmpv3usm-when-combined-with-engineid-discovery/ |
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ 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