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 inform
If 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
