[erlang-questions] SNMP v3 usmStatsNotInTimeWindows error

Devangana Tarafdar <>
Fri Sep 23 18:47:27 CEST 2016


Hi,

Thanks so much !

It worked.

I applied the patch to 17.1 as well as 19, since the file snmpm_usm.erl
 had not changed,  (would you recommend doing that, applying it to 19 when
it was written for 17.1 ? ) and they both worked.

Also thanks for your patience, I realize that I have not been too prompt in
replying to your suggestions, (getting pulled into other projects and can
only come back to this for some hours in a week :-( ).

Best,
Devangana

On Mon, Sep 19, 2016 at 8:46 AM, Devangana Tarafdar <>
wrote:

> Sorry about the late reply Daniel, I missed the email.
>
> Yes the engine id was correct in the wireshark trace.   That was the first
> thing I had to correct. I had to convert the engine id string to an
> explicit list of decimals for the id.
>
> On Sep 15, 2016 10:52 AM, "Daniel Goertzen" <>
> wrote:
>
>> Check that the engine ids are what you expect them to be.  You've
>> redacted all the engine ids from the trace, so I can't check them.
>>
>> The SNMP config files have trouble storing non-ascii engine ids; not sure
>> if this affect you.  This should be fixed agent-side for 19.1, not sure
>> about manager-side.
>>
>> On Wed, Sep 14, 2016 at 1:42 PM Devangana Tarafdar <>
>> wrote:
>>
>>> Hi Dominik,
>>>
>>> So I was able look at the wireshark stream decoded after entering snmp
>>> credentials  (that was very helpful, thanks !) and compared the 2 streams :
>>> One from the snmp get tool and the other from the erlang script.
>>>
>>> Wireshark is not able to decode the encrypted pdu  in the erlang stream
>>> but it can decode the snmpget stream.
>>>
>>> The message is clear enough I suppose but I don't know what I am doing
>>> wrong with the key.
>>>
>>> I changed my local key generation to :
>>>
>>>  %Priv_key_local = snmp:passwd2localized_key(sha, Priv_key ,
>>> Agent_engine_id),
>>>
>>>  % since auth protocol is SHA
>>>   Priv_key_local = lists:sublist(snmp:passwd2localized_key(sha,
>>> Priv_key , Agent_engine_id),16),
>>>
>>> but it did not help.
>>>
>>>
>>> msgData: encryptedPDU (1)
>>>         encryptedPDU: 8a3e7fc633c531d2747782a6fc8d89
>>> 187c452929426e4b6e...
>>>             Decrypted data not formatted as expected, wrong key?
>>>                 [Expert Info (Warn/Malformed): Decrypted data not
>>> formatted as expected]
>>>                     [Message: Decrypted data not formatted as expected]
>>>                     [Severity level: Warn]
>>>                     [Group: Malformed]
>>>
>>>
>>> Attaching  good wireshark trace from snmpget and a bad one from erlang.
>>>
>>> Also tried putting a context name but did not work but snmpget does not
>>> put one and it works.
>>>
>>> Thanks,
>>> Devangana
>>>
>>>
>>>
>>> On Sun, Sep 11, 2016 at 4:09 PM, Devangana Tarafdar <
>>> > wrote:
>>>
>>>> Hi Dominik,
>>>>
>>>> I have not looked into the context. Will check all the items that you
>>>> mention.  I have been able to connect to the agent using snmpwalk and
>>>> snmpget though I have not studied the wireshark output of those in detail.
>>>> Thanks again for all these tips and I will get back to you .
>>>>
>>>> Devangana
>>>>
>>>> On Sep 11, 2016 3:08 PM, "Dominik Pawlak" <>
>>>> wrote:
>>>>
>>>>> Hello Devangana,
>>>>> Hard to tell, but I see that you haven't specified any context in your
>>>>> sync_get. Are you sure it is not needed? I would also double check the
>>>>> engine id and security configuration.
>>>>> Have you managed to connect to that agent from something other than
>>>>> OTP (say snmpb, snmpget)?
>>>>> If so, you can compare in Wireshark, the snmp requests from erlang and
>>>>> from that tool. You can even enter your snmp credentials in Wireshark and
>>>>> it will decode encrypted messages.
>>>>> I hope any of this helps.
>>>>>
>>>>> Best
>>>>> Dominik
>>>>>
>>>>> On 11.09.2016 16:46, Devangana Tarafdar wrote:
>>>>>
>>>>> Hello Dominik,
>>>>>
>>>>> Thanks you for the reply.
>>>>>
>>>>> I  sent another sync_get after the first as you suggested. The
>>>>> wireshark trace shows the manager has updated the
>>>>> 'msgAuthoritativeEngineBoots' and 'msgAuthoritativeEngineTime' to the
>>>>> values sent by the Agent as you pointed out. But now the agent does not
>>>>> respond at all and the sync_get fails with a timeout. I tried adding a
>>>>> second's sleep between the 2 gets as well. I don't have access currently to
>>>>> the agent's logs or configuration but have you seen this before ?
>>>>>
>>>>> Thanks !
>>>>> Devangana
>>>>>
>>>>>
>>>>> On Sat, Sep 10, 2016 at 6:09 PM, Dominik Pawlak <
>>>>> > wrote:
>>>>>
>>>>>> Hello Devangana,
>>>>>> Basically, you just have to perform the sync_get once more. I
>>>>>> observed similar behavior in OTP 17.1 (snmp 4.25.1). The first request will
>>>>>> always fail because the manager is not fully configured to communicate with
>>>>>> the agent (more on that below).
>>>>>>
>>>>>> A longer explanation:
>>>>>>
>>>>>> In snmp v3 there is a process called 'discovery', which should be
>>>>>> performed before secure communication with the agent can be established. It
>>>>>> is described here:
>>>>>>
>>>>>> https://tools.ietf.org/html/rfc3414#section-4
>>>>>>
>>>>>> The snmp library in OTP does not implement that process (at least not
>>>>>> as described in the RFC).
>>>>>> This process has two steps: 'snmpEngineID discovery' and 'time
>>>>>> synchronization'.
>>>>>> The first step is skipped altogether in OTP - you have to provide
>>>>>> engine id upfront.
>>>>>> The second step is performed by the first request - it will always
>>>>>> fail with the 'usmStatsNotInTimeWindows' error report message, but it will
>>>>>> set the required 'msgAuthoritativeEngineBoots' and
>>>>>> 'msgAuthoritativeEngineTime' in the manager.
>>>>>>
>>>>>> Best,
>>>>>> Dominik
>>>>>>
>>>>>>
>>>>>> On 10.09.2016 06:48, Devangana Tarafdar wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am trying to connect to a third party SNMP agent, using snmp
>>>>>> manager (snmp v3) ( in the erlang 19 release snmp 5.2.3) and I am running
>>>>>> into a problem where the agent is returning this error on the manager
>>>>>> calling sync_get:
>>>>>>
>>>>>>
>>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE ***
>>>>>>    handle_snmp_report -> entry with
>>>>>>    Domain:  snmpUDPDomain
>>>>>>    Addr:    {{xx,xxx,xxx,xxx},161}
>>>>>>    ReqId:   37078226
>>>>>>    Rep:     {invalid_sec_info,[{sec_level,3,1},
>>>>>>                                {request_id,37078226,2147483647}]}
>>>>>>    Pdu:     {pdu,report,2147483647,noError,0,
>>>>>>                  [{varbind,[1,3,6,1,6,3,15,1,1
>>>>>> ,2,0],'Counter32',33,1}]}
>>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER DEBUG ***
>>>>>>    handle_snmp_report -> found corresponding request:
>>>>>>    reply to sync request
>>>>>>    Ref:    #Ref<0.0.4.210>
>>>>>>    ModRef: #Ref<0.0.4.211>
>>>>>>    From:   {<0.3.0>,#Ref<0.0.4.202>}
>>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE ***
>>>>>>    handle_snmp_pdu(get-response) -> Remaining: 4979
>>>>>> *** [2016:09:08 21:26:00 830] SNMP M-SERVER TRACE ***
>>>>>>    handle_snmp_report -> deliver reply
>>>>>>
>>>>>> {error,{invalid_sec_info,[{sec_level,3,1},{request_id,37078226,
>>>>>> 2147483647}],{noError,0,[{varbind,[1,3,6,1,6,3,15,1,1,2,
>>>>>> 0],'Counter32',33,1}]}}}
>>>>>>
>>>>>> *** [2016:09:08 21:26:00 831]
>>>>>>
>>>>>> Where [1,3,6,1,6,3,15,1,1,2,0]  maps to "usmStatsNotInTimeWindows"
>>>>>> (from http://www.oid-info.com/)
>>>>>>
>>>>>> I have attached a  wireshark trace for the snmp part of this exchange.
>>>>>>
>>>>>> I am invoking the snmpm module functions through a basic script as
>>>>>> follows (using tips from the tutorial at
>>>>>> https://erlangcentral.org/wiki/index.php?title=SNMP_Quick_Start )
>>>>>> .........
>>>>>> ..........
>>>>>>
>>>>>>   ok = application:start(crypto),
>>>>>>   ok = application:start(snmp),
>>>>>>
>>>>>>   Userid = "snmp3user",
>>>>>>   Agent_target = "testagent",
>>>>>>   Agent_engine_id = [128,0,0,8,2,0,0,26,84,40,108,176],
>>>>>>   Agent_ip = {xx,xxx,xxx,xxx},
>>>>>>   Agent_port = 161 ,
>>>>>>   Secure_name= Userid,
>>>>>>
>>>>>>   Security_level = 'authPriv',
>>>>>>   Security_model = 'usm',
>>>>>>   Agent_version = 'v3',
>>>>>>   Auth_protocol = 'usmHMACSHAAuthProtocol',
>>>>>>   Priv_protocol = 'usmAesCfb128Protocol',
>>>>>>
>>>>>>   % this is 16 in length
>>>>>>   Priv_key_local = snmp:passwd2localized_key(md5, Priv_key , Agent_engine_id),
>>>>>>
>>>>>>   % this is 20 in length
>>>>>>   Auth_key_local = snmp:passwd2localized_key(sha, Auth_key , Agent_engine_id),
>>>>>>
>>>>>>   ok = snmpm:register_user(Userid,snmpm_user_default,[]),
>>>>>>
>>>>>>   ok = snmpm:register_usm_user(Agent_engine_id, Userid, [
>>>>>>                               {auth, Auth_protocol},
>>>>>>                               {auth_key,Auth_key_local},
>>>>>>                               {priv, Priv_protocol},
>>>>>>                               {priv_key,Priv_key_local },
>>>>>>                               {sec_name, Secure_name}
>>>>>>                         ]),
>>>>>>   ok = snmpm:register_agent(Userid, Agent_target ,[
>>>>>>                                                    {engine_id,Agent_engine_id},
>>>>>>                                                    {address, Agent_ip},
>>>>>>                                                    {port, Agent_port},
>>>>>>                                                    {version,Agent_version},
>>>>>>                                                    {sec_model,Security_model},
>>>>>>                                                    {sec_name,Secure_name},
>>>>>>                                                    {sec_level, Security_level}
>>>>>>
>>>>>>                                ]),
>>>>>>   Res0 = snmpm:sync_get(Userid, Agent_target, [[1,3,6,1,4,1,9,10,19,1,1,9,1,3,7,2]]),   ........................
>>>>>>
>>>>>>   ........................
>>>>>>
>>>>>> Can anyone please tell me what I am doing wrong here ? Any tips would be appreciated !
>>>>>>
>>>>>> Thanks, Devangana
>>>>>>
>>>>>> _______________________________________________
>>>>>> erlang-questions mailing ://erlang.org/mailman/listinfo/erlang-questions
>>>>>>
>>>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160923/89c0a145/attachment-0001.html>


More information about the erlang-questions mailing list