SNMP Agent bugs

[Ola Samuelsson-2]

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.

[Ola Samuelsson-2]

Your welcome.
Martin suggested me to send these patches.
I did not verify with the OTP R12B release before sending to this forum,
so I'm sorry about that.

I've checked with the OTP R12B release now and the first two problems
is still there at least.
(don't have time to check the third fault right now, could be my own  
fault of
course,  running a hacked SNMP agent...:-)

/ola
ola



On Feb 14, 2008, at 2:36 PM, Micael Karlberg wrote:

> 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
>
>
>
>