[SNMP4J] Engine time synchronization question

[Frank Fock]

Hi Kevin,

As Ronald pointed out, it should not be necessary to implement a
CommandResponder in order to be able to do engine ID discovery,
because SNMP4J handles it before a CommandResponder is called.
However, since SNMPv3 traps are sent from the authoritative engine
to the non-authoritative engine, there is no need for engine ID discovery
for SNMPv3 traps.

Please note that there is a need for enigne ID discovery for INFORM
messages, because those are sent from the non-authoritative to the
authoritative engine and back (RESPONSE PDU).

Best regards,
Frank

Kevin J. Schmidt wrote:

>It would appear that the CommandResponder interface does indeed need
>to be implemented, i.e. you provide your own processPdu method. This
>is the only way I was able to respond to engine ID discovery requests.
>It seems you also have to do something like:
>
>snmpObject.setLocalEngine(authoritativeEngineID.getValue(),0,0);
>
>if you want your own engine ID to be discovered, or call
>
>MPv3.createLocalEngineID()
>
>if you want a random one created. But this is speculation on my part.
>
>Can someone in the know comment on this?
>
>Thanks,
>
>
>On Mon, 28 Mar 2005 10:42:03 -0600, Ronald.Madsen at utstar.com
><Ronald.Madsen at utstar.com> wrote:
>  
>
>>I have never written an application to send SNMPv3 traps - mainly because I
>>don't know of any "Manager" ready to accept them.  But here is my
>>understanding of the situation...
>>
>>From a SNMPv3 USM point of view, your application will be considered an
>>"authoritative" SNMP Engine.  As such, the application is required to
>>response to snmpEngine discovery queries - BUT - I believe the SNMP4J stack
>>takes care of all of this for you.
>>
>>I'm not real clear on port usage when just sending traps.  You might need
>>to use port 161 when sending the traps - allowing the manager application
>>to do the engine discovery as necessary.  If the manager application forces
>>engine discovery to port 161 - then you will have to "listen" on 161.
>>
>>Note that all engine discovery transactions are handled by SNMP4J.  You
>>application will never see the queries.  I do not believe you need to
>>actually implement the CommandResponder interface.
>>
>>Best regards,
>>Ron
>>
>>"Kevin J. Schmidt" <kjschmidt at gmail.com> on 03/28/2005 09:37:49 AM
>>
>>Please respond to "Kevin J. Schmidt" <kjschmidt at gmail.com>
>>
>>To:    Ronald Madsen/UTStarcom at UTStarcom
>>cc:    snmp4j at agentpp.org
>>Subject:    Re: [SNMP4J] Engine time synchronization question
>>
>>Hi,
>>
>>This brings up a good question for me. I'm writing an application that
>>can send SNMP v1, v2c, and v3 traps/notifications. It's meant to
>>interface with our product and provide external alerting capabilities
>>to OpenView, et al. I wasn't planning on developing agent-like
>>capabilities, i.e. have a process listen on port 162 and respond to
>>SNMP requests. Can I get away with doing this or do I need to be able
>>to respond to requests for engineID, boots, and time?
>>
>>On Wed, 23 Mar 2005 16:24:04 -0600, Ronald.Madsen at utstar.com
>><Ronald.Madsen at utstar.com> wrote:
>>    
>>
>>>I'm experimenting writing a SNMPv3 Agent using SNMP4j.
>>>
>>>My "Manager" sends a normal Request to discover the authoritative
>>>      
>>>
>>engineID
>>    
>>
>>>- SNMP4j responds with a REPORT with its engineID just fine.
>>>
>>>The Manager then sends an authorative Request to discover the engineBoots
>>>and engineTime - SNMP4j responds with a REPORT with both engineBoots and
>>>engineTime set to zero.
>>>
>>>Subsequent transations eventually Report "not in time window".
>>>
>>>I searched the SNMP4j archives and did not find a similar discussion.
>>>
>>>I may very well be using SNMP4j incorrectly.
>>>
>>>Does anyone have a small snippet fo code that properly initializes Snmp,
>>>USM, etc.  correctly?
>>>
>>>Thanks,
>>>
>>>_______________________________________________
>>>SNMP4J mailing list
>>>SNMP4J at agentpp.org
>>>http://lists.agentpp.org/mailman/listinfo/snmp4j
>>>
>>>      
>>>
>>--
>>Kevin J. Schmidt
>> <kjschmidt at gmail.com>
>>
>>
>>    
>>
>
>
>  
>