| Author |
Message |
|
| Guest |
 Posted: Wed Feb 13, 2008 3:29 pm |
 |
|
|
Guest
|
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@tail-f.com
----------------------------------------
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@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-patches
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 14, 2008 3:21 pm |
|
|
|
Guest
|
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@tail-f.com
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@tail-f.com
>> ----------------------------------------
>> 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@erlang.org
>> http://www.erlang.org/mailman/listinfo/erlang-patches
>
>
>
>
_______________________________________________
erlang-patches mailing list
erlang-patches@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-patches
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
