Re: Engine ID discovery
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#174; 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
Re: Engine ID discovery
On Wed, 07 Apr 2010 12:44:07 +0530, sanjaykumar sanjay.ku...@globaledgesoft.com said: s So do I conclude my requirement as follow: s Requirement: As I do the discovery to send the inform request s Conclusion: s 1. I will send the inform request for engine ID probeing s 2. Inform request will be framed as describe in RFC 3414 s This may be accomplished by generating a Request message with a s securityLevel of noAuthNoPriv, s a msgUserName of zero-length, a msgAuthoritativeEngineID value of zero s length, and the varBindList left empty. [as per rfc 3414 section 4] s Please add your comments. Yes, that is exactly what I'd do. -- Wes Hardaker Cobham Analytic Solutions -- Download Intel#174; 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
Re: Engine ID discovery
On Tue, 6 Apr 2010 12:29:58 -0700, Mike Ayers mike_ay...@tva.tvworks.com said: MA Awww... time to dig back into the deep stuff... there may be two MA authoritative entities for these transactions. I'll dig in and see MA what I get. There is two authoritative engines. I wrote a whole tutorial on the confusing aspect of the subject: http://www.net-snmp.org/wiki/index.php/TUT:snmptrap_SNMPv3 -- Wes Hardaker Cobham Analytic Solutions -- Download Intel#174; 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
RE: Engine ID discovery
From: sanjaykumar [mailto:sanjay.ku...@globaledgesoft.com] Sent: Monday, April 05, 2010 11:05 PM I am going through the Engine ID discovery code. Could someone explain me about this concept ?? When does it Required ?? How does Engine ID discovery process take place ? Does it is standard or implementation dependent ??? http://datatracker.ietf.org/doc/rfc3414/ Section 4, Discovery, is what you're looking for. HTH, Mike -- Download Intel#174; 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
Re: Engine ID discovery
On 6 April 2010 07:04, sanjaykumar sanjay.ku...@globaledgesoft.com wrote: I am going through the Engine ID discovery code. Could someone explain me about this concept ?? In order to use SNMPv3, it's necessary to know the engineID of the agent (or strictly speaking, the authoritative SNMP engine - which is the agent for GET* and SET requests). One way to do this is to specify the engine ID explicitly (e.g. via the -e command line option). A number of other SNMP toolkits work this way. But the Net-SNMP code attempts to probe the remote agent to discover this value, by sending a request without the engineID in place.This request will fail, but the response that comes back includes the engine ID (and possibly the boot count/uptime values as well). The client can then re-send the request including this information, and hopefully the request should then succeed. Dave -- Download Intel#174; 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
Re: Engine ID discovery
Dave Shield wrote: On 6 April 2010 07:04, sanjaykumar sanjay.ku...@globaledgesoft.com wrote: I am going through the "Engine ID discovery" code. Could someone explain me about this concept ?? In order to use SNMPv3, it's necessary to know the "engineID" of the agent (or strictly speaking, the "authoritative SNMP engine" - which is the agent for GET* and SET requests). One way to do this is to specify the engine ID explicitly (e.g. via the -e command line option). A number of other SNMP toolkits work this way. But the Net-SNMP code attempts to probe the remote agent to discover this value, by sending a request without the engineID in place.This request will fail, but the response that comes back includes the engine ID (and possibly the boot count/uptime values as well). The client can then re-send the request including this information, and hopefully the request should then succeed. Dave Hi Dave, I am trying to send the snmp-inform to different SNMP-Manager. But initially Engine ID is unavailable. So we are sending the inform with WRONG engine ID, once we receive the REPORT then we update the required data-structure then RESENT the inform request and it is working fine. Does it correct approach ??? or is there any standard violation ?? Or i need to discover the engine ID, first by sending the GET request , Then send the inform request. rgds, Sanjay -- Download Intel#174; 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
Re: Engine ID discovery
On 6 April 2010 10:09, sanjaykumar sanjay.ku...@globaledgesoft.com wrote: So we are sending the inform with WRONG engine ID, once we receive the REPORT then we update the required data-structure then RESENT the inform request and it is working fine. Does it correct approach ??? That's essentially the same approach as I described earlier. Or i need to discover the engine ID, first by sending the GET request , Then send the inform request. It makes no difference whether you send a GET request or an INFORM request - the message will be rejected in either case (because it doesn't have the correct engineID). Each approach will then process the rejection report in exactly the same way (extracting the engineID and boot count/uptime values). So it really doesn't matter whether you send a GET probe or an INFORM probe - either will work, and either is valid. Dave -- Download Intel#174; 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
Re: Engine ID discovery
Hi, I have a real time situation. Suppose I have to send inform to an ip addr. On that ip addr, snmptrapd is not running. 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 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. So my question is, if we follow approach 2, then is it valid as per the SNMP standard ?? Regard's Sanjay Dave Shield wrote: On 6 April 2010 10:09, sanjaykumar sanjay.ku...@globaledgesoft.com wrote: So we are sending the inform with WRONG engine ID, once we receive the REPORT then we update the required data-structure then RESENT the inform request and it is working fine. Does it correct approach ??? That's essentially the same approach as I described earlier. Or i need to discover the engine ID, first by sending the GET request , Then send the inform request. It makes no difference whether you send a GET request or an INFORM request - the message will be rejected in either case (because it doesn't have the correct engineID). Each approach will then process the rejection report in exactly the same way (extracting the engineID and boot count/uptime values). So it really doesn't matter whether you send a GET probe or an INFORM probe - either will work, and either is valid. Dave -- Download Intel#174; 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
Re: Engine ID discovery
On 6 April 2010 11:04, sanjaykumar sanjay.ku...@globaledgesoft.com wrote: Suppose I have to send inform to an ip addr. On that ip addr, snmptrapd is not running. Then there's nothing to accept the notification. 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 Which is reasonable, since there's nothing to accept it. What I'm not 100% sure about is what happens if snmptrapd *is* running. It would reject a GET request anyway, since it's a trap receiver, not an SNMP agent. But you'd need to work through the SNMPv3 Elements of Procedure very carefully to check whether the engineID probe handling is done before the invalid PDU is rejected, or not. My guess is that it probably is, but I don't claim to be an SNMPv3 expert. Check the specs. 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. This feels safer - you're sending a probe request that would be accepted as valid by the receiving engine. So there's no likelihood that it will be dropped before returning the error response. It *probably* makes no difference, but it feels safer to me. So my question is, if we follow approach 2, then is it valid as per the SNMP standard ?? Yes. I believe so. Mike - do you wish to comment further? Dave -- Download Intel#174; 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
Re: Engine ID discovery
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/ -- Wes Hardaker Cobham Analytic Solutions -- Download Intel#174; 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
Re: Engine ID discovery
On 6 April 2010 20:02, Mike Ayers mike_ay...@tva.tvworks.com wrote: The authoritative engine for an inform is the sending engine Is it? I believe that the authoritative engine for an Inform was the notification receiver (just like any other acknowledged request). The authoritative engine for a *trap* is the sender, sure. But not for an inform notification. Dave -- Download Intel#174; 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
RE: Engine ID discovery
From: dave.shi...@googlemail.com [mailto:dave.shi...@googlemail.com] On Behalf Of Dave Shield Sent: Tuesday, April 06, 2010 3:17 AM Mike - do you wish to comment further? I just think the OP should quit screwing around in the dark. RFC3414, section 4 explains how to get an engineId from any engine. A non-engine has no engineID, so that solves itself. There is no need to attempt to invent one's own protocol. The authoritative engine for an inform is the sending engine, so discovery is unnecessary. What problem is OP trying to solve that can't be handled by just using the existing net-snmp code? Mike -- Download Intel#174; 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
RE: Engine ID discovery
From: dave.shi...@googlemail.com [mailto:dave.shi...@googlemail.com] On Behalf Of Dave Shield Sent: Tuesday, April 06, 2010 12:06 PM On 6 April 2010 20:02, Mike Ayers mike_ay...@tva.tvworks.com wrote: The authoritative engine for an inform is the sending engine Is it? I believe that the authoritative engine for an Inform was the notification receiver (just like any other acknowledged request). The authoritative engine for a *trap* is the sender, sure. But not for an inform notification. Awww... time to dig back into the deep stuff... there may be two authoritative entities for these transactions. I'll dig in and see what I get. Mike -- Download Intel#174; 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
