[erlang-questions] SNMP v3 usmStatsNotInTimeWindows error

Dominik Pawlak <>
Wed Sep 14 22:52:33 CEST 2016


Hi Devangana,

I see that you use AES for encryption. There was a related bug in the 
snmp library:
http://erlang.org/pipermail/erlang-bugs/2014-August/004551.html

I don't know if it's fixed in newer snmp library versions. I attached 
the patch that we used to fix snmp 4.25.1.
Or maybe you can live with DES encryption?

Best
Dominik

On 14.09.2016 20:41, 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: 8a3e7fc633c531d2747782a6fc8d89187c452929426e4b6e...
>             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 
> < <mailto:>> 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"
>     < <mailto:>>
>     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
>>         <
>>         <mailto:>> 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
>>             <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 <tel:2147483647>}]}
>>>                Pdu: {pdu,report,2147483647 <tel: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
>>>             <tel: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
>>>             <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 list
>>>             
>>>             <mailto:>
>>>             http://erlang.org/mailman/listinfo/erlang-questions
>>>             <http://erlang.org/mailman/listinfo/erlang-questions>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160914/f7aabf28/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snmp.patch
Type: text/x-patch
Size: 4555 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160914/f7aabf28/attachment.bin>


More information about the erlang-questions mailing list