Closed YasminWagenfeld closed 5 years ago
Hi, @YasminWagenfeld! Thank you for the extensive information. I apologize for the wait, but I'll review this later today and let you know what I find.
Just to be clear, @YasminWagenfeld, are you working with :snmp_ex
0.2.3?
It appears to me that USM engineID discovery INFORM
s sent to 192.168.0.251 did, indeed, time out, as the SNMPv3 agent should have replied with the initial REPORT
much sooner.
In your trace output, we have three notable loop-wait events corresponding to each of the three initial INFORM
s:
*** [2019-07-17 14:11:00.103] SNMP A-NET-IF DEBUG ***
loop({state,<0.424.0>,<0.442.0>,<0.441.0>,
(omitted for brevity)
*** [2019-07-17 14:11:01.092] SNMP A-NET-IF DEBUG ***
loop({state,<0.424.0>,<0.442.0>,<0.441.0>,
(omitted for brevity)
*** [2019-07-17 14:11:03.092] SNMP A-NET-IF DEBUG ***
loop({state,<0.424.0>,<0.442.0>,<0.441.0>,
(omitted for brevity)
*** [2019-07-17 14:11:07.090] SNMP MASTER-AGENT DEBUG ***
handle_info(discovery_response) -> entry with
Response: {error,timeout}
Note the exponential backoff being performed, whereby we wait in 1-, 2-, and 4-second intervals, respectively.
After seven seconds and two retries, :snmpa
finally times out. Alas, the client never observes the agent's engineId, as can be observed in the "get-request with OID" figure, which contains only the reserved localEngineId, 0x8000000006
, rather than the agent's authoritativeEngineId, 0x8000001100300094fb2d182
.
Unfortunately, it isn't at all clear to me why your agent is failing to respond in a timely fashion. Is it an HP device? That engineId doesn't quite follow the textual convention for engineIds, but it does contain an SNMP enterprise ID belonging to Hewlett-Packard. If you're working with a Procurve device, you may be able to increase logging sensitivity/verbosity for additional information.
Let me know what you think. Also, for reference, RFC3414 describes the SNMPv3 USM engineId discovery procedure.
I'm closing this issue due to lack of activity. We can alway reopen, if necessary.
When running
It returns
{:error, :etimedout}
, which comes fromSNMP.DiscoveryAgent
where it comes from:snmpa.discovery()
.However, a get-request is sent and a report with a proper EngineID is sent back in response, which seems to be ignored by the agent. As a result the actual get-request (with the OID) is sent with the wrong EngineID and doesn't receive a reply.
Using the command line, this works:
I would think that this is a bug in Erlang's snmpa, but the comments in #6 indicate that the authNoPriv discovery should work by now.
Am I missing something?
I enabled SNMP trace logging:
:snmpa.verbosity(:all, :trace)
. Here is the log:Click to expand
Here are Wireshark screenshots of the packets sent by snmp-elixir:
get-request
report
get-request with OID