[erlang-questions] SNMP v3 usmStatsNotInTimeWindows error
Daniel Goertzen
daniel.goertzen@REDACTED
Thu Sep 15 17:52:26 CEST 2016
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 <devangana@REDACTED>
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 <devangana@REDACTED>
> 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" <dominik_pawlak@REDACTED>
>> 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 <
>>> dominik_pawlak@REDACTED> 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 listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160915/d1ae7916/attachment.htm>
More information about the erlang-questions
mailing list