[erlang-bugs] SNMP get-request failure

[Raimo Niskanen]

On Mon, Apr 07, 2014 at 10:13:16AM +0200, Stefan Zegenhagen wrote:
> Dear all,
> 
> we have discovered at least one SNMP manager that composes get-requests
> like this:
> 
> {pdu,'get-request',15,noError,0,[{varbind,<OID>,'INTEGER',0,1}]}
> 
> Please note that the get-request does not contain 'NULL', 'NULL' as
> variabletype and value, but contains a valid type/value pair. To my
> knowledge, this is not forbidden.
> 
> When the OID is not accessible (e.g. MAX-ACCESS is not-accessible or
> accessible-for-notify), the following response-PDU is generated:
> 
> {pdu,'get-response',15,noError,0,[{varbind,<OID>,'INTEGER',noSuchInstance,1}
> 
> Please not again that the variabletype is still the one from the
> original requests, e.g. the PDU processing in snmpa_agent:process_pdu/5
> fails to update #varbind.variabletype when detecting errors.
> 
> This response PDU fails to encode because of the ordering of the clauses
> in snmp_pdus:enc_value/2 which checks for basic BER types first, before
> considering known error atoms as values.
> 
> The same problem does not exist when the instrumentation function for
> that object returns {noValue, Error} because the 'noValue' atom is
> copied to #varbind.variabletype in that case.
> 
> 
> A fix should probably:
>       * reorder the clauses in snmp_pdus:enc_value/2,
>       * overwrite #varbind.variabletype with 'NULL' or 'noValue' when
>         detecting errors,
>       * or do both of the above solutions.

I'd say alternative 3: both.

Moving the error atom clauses to the top in snmp_pdus:enc_value/2 should
be sufficient, but the agent should ignore any types and values in
the get-request and the manager should set them to 'NULL'; so pretending
that the get-request contained 'NULL' for type and value ought to be
a safe strategy.

So we need to set #varbind.variabletype to 'NULL' in
snmp_agent:check_all_table_vbs/4, snmp_agent:get_var_value_from_ivb/2
and snmp_agent:next_loop_varbinds/6 for #me.access ==
'not-accessible', 'write-only' and 'accessible-for-notify'
(note the reverse logic in the last function).

I will write an internal ticket for this that will probably result
in a patch for R16B03 and be included in 17.1.

Thank you for an excellent problem report!

> 
> 
> 
> Kind regards,
> 
> -- 
> Dr. Stefan Zegenhagen
> 
> arcutronix GmbH
> Garbsener Landstr. 10
> 30419 Hannover
> Germany
> 
> Tel:   +49 511 277-2734
> Fax:   +49 511 277-2709
> Email: stefan.zegenhagen@REDACTED
> Web:   www.arcutronix.com
> 
> *Synchronize the Ethernet*
> 
> General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer -
> Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht
> Hannover; Ust-Id: DE257551767.
> 
> Please consider the environment before printing this message.
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB