> Hi,
>
> Thanks for the patch.
>
> The current version of the SNMP application is 4.10.1 and
> the application is actively maintained, which your resident
> snmp contact (Martin) should know :).
>
> Regards,
> /BMK
>
> Ola Samuelsson wrote:
>> Hi,
>> I've found a few bugs in the SNMP Agent application in OTP.
>> We are running an older OTP release (R10B-10) but
>> I suspect that the SNMP application haven't been updated for a
>> while.
>> Anyway, I've listed the problems I've found below if you're
>> interested.
>> Ola Samuelsson
>> ola
>> ----------------------------------------
>> The MIB-compiler does not suppport a name assignment
>> which is sequence of numbers,
>> only a father object name followed by a sequence of numbers.
>> ----------------------------------------
>> Grammar looked like this:
>> (line 392 in snmpc_mib_gram.yrl)
>> % Returns: {FatherName, SubIndex} (the parent)
>> nameassign -> implies '{' fatherobjectname parentintegers '}'
>> : {'$3', '$4' }.
>> Added another rule to handle case with only numbers:
>> % Returns: {FatherName, SubIndex} (the parent)
>> nameassign -> implies '{' fatherobjectname parentintegers '}'
>> : {'$3', '$4' }.
>> nameassign -> implies '{' parentintegers '}' : { root, '$3'}.
>> ----------------------------------------
>> The MIB-compiler does not recognize well-known-names
>> as top parents.
>> The names 'ccitt' (0) , 'iso' (1) and 'joint-iso-ccitt' (2),
>> should be familiar to the SNMP compiler.
>> ----------------------------------------
>> Quick solution was to fix the import in snmpc_lib.erl and
>> register these names before the imports take place.
>> (line 176 in snmpc_lib.erl)
>> import(ImportList) ->
>> + %% FIX: Added well-known-nodes
>> + WellKnownNodes= [ makeInternalNode(ccitt,[0]),
>> + makeInternalNode(iso, [1]),
>> + makeInternalNode('joint-iso-ccitt',[2])],
>> + lists:foreach(fun(ME) ->
>> + register_oid(undef, ME#me.aliasname, root, ME#me.oid)
>> + end,
>> + WellKnownNodes),
>> lists:foreach(fun import_mib/1, ImportList).
>> ----------------------------------------
>> TRAP sending in SNMP does not give correct order on
>> the varbinds.
>> ----------------------------------------
>> The agent tries to lookup the varbinds for values that
>> are not given by the user, but it reverses the order of
>> the looked up objects.
>> The problem can be solved in many ways, and this is a lazy fix
>> for it.
>> (line 404? snmpa_trap.erl)
>> get_all(VariablesWithType) ->
>> {Order, Varbinds} = extract_order(VariablesWithType, 1),
>> case snmpa_agent:do_get(snmpa_acm:get_root_mib_view(),
>> Varbinds, true) of
>> + {noError, _, NewVarbinds} ->
>> + %% Bug...
>> + %% Can't do contract order on the returned list of
>> + %% Varbinds since it's reversed.
>> + %% It has an org_index on it which tells the varbind order,
>> + %% and if we sort on that first,
>> + %% the contract_order/2 will be correct.
>> + %%
>> + NewVarbinds1 = lists:keysort(#varbind.org_index,NewVarbinds),
>> + contract_order(Order, NewVarbinds1);
>> {ErrorStatus, ErrorIndex, _} ->
>> user_err("snmpa_trap: get operation failed {~w, ~w}"
>> "~n in ~w",
>> [ErrorStatus, ErrorIndex, Varbinds]),
>> throw(error)
>> end.
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches
>>
http://www.erlang.org/mailman/listinfo/erlang-patches>
>
>
>
Locked
