snmp v3 authentication problem

[fbettag]

Hi again, sorry for putting up yet another issue.

So the last thing i am currently having problems with is SNMP v3 authentication. While OpenBSD's snmp utility works with these credentials, i am only able to get the following timeout error out of this library:

[error] Timeout!
{:error, :etimedout}

On OpenBSD i used the following flags for a successful walk: snmp get -A "M3ekvc5oscYvUuO309+IQ" -a sha -X "A+3E5DFE+CWaqCoRFQu" -x aes -v 3 -l authPriv -u mytest <ip.of.device>

The code to produce my credentials object looks like this:

  def credentials do
    SNMP.credential(%{
      auth: :sha,
      auth_pass: "M3ekvc5oscYvUuO309+IQ",
      priv: :aes,
      priv_pass: "A+3E5DFE+CWaqCoRFQu",
      sec_level: :authPriv,
      sec_model: :usm,
      sec_name: "mytest",
      version: :v3
    })
    #SNMP.credential(%{
    #  community: "mytest",
    #})
  end

SNMP v1 works perfectly, but i rather not use it due to security concerns.

Thank you very much in advance.

[jonnystorm]

Unfortunately, Erlang does not currently support AES for privacy. Please see #36 and #6 for more information.

Maybe, one day, I'll get around to writing the requisite test suite and completing the patch process for fixing this bug in OTP. For now, it is still entirely possible to patch and compile one's own OTP to deal with the problem.

[fbettag]

Ah. I just read the code and assumed it was working :)

I changed it to SHA/DES, but still keep getting timeouts. I also tried disabling privacy and set sec_level to :authNoPriv, with the result being:

[info] SNMPM default user callback received handle_error:
   ReqId:    -1
   Reason:   {:failed_processing_message, {:securityError, :usmStatsUnknownEngineIDs}}
   UserData: :undefined

[info] SNMPM default user callback received handle_error:
   ReqId:    -1
   Reason:   {:failed_processing_message, {:securityError, :usmStatsUnknownEngineIDs}}
   UserData: :undefined

In case you are wondering, these are standard APC PDUs.

[jonnystorm]

Timeouts are normally a clear indication of an unresponsive agent, whereas persistent engine ID errors may suggest engine discovery failure.

Was there a specific error result associated with the given logs? As it stands, my own testing indicates DES privacy and authNoPriv succeed without incident.