[erlang-bugs] SNMP usm agent doesn't work properly in case of mask =/= null

[Heizenberg John]

I faced with this problem on snmp-4.25. Then I cloned otp commit 545890576542e4be630df8772654b99bd0306f62 Author: Erlang/OTP <otp@REDACTED> Date:   Tue Mar 31 12:24:06 2015 +0200 and I still have the same trouble.
The reason is the some optimisation code in snmpa_mib_data_tttn (ttln).  In fact there are two reasons:

Reason 1.

-module(snmpa_mib_data_tttn).

811   next_node(D, {tree, Tree, {table_entry, _MibName}},
        ....
819   case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of

%%------------------------------------------------------------------------------------

-module(snmpa_acm).

346   is_definitely_not_in_mib_view(Oid, [{SubTree, Mask,?view_included}|T]) ->
347       case check_maybe_mask(Oid, SubTree, Mask) of
348	    true -> false;
349	    false -> is_definitely_not_in_mib_view(Oid, T)
350       end;

%%------------------------------------------------------------------------------------

But as I saw while debugging the Mask variable is type of emask (the list of bytes, not the list of bits) and check_maybe_mask(Oid, SubTree, Mask) always return false. This cause that every Oid will be dropped as inapropriate:

%%-----------------------------------------------------------------
%% As check_mask, BUT if Oid < SubTree and sofar good, we
%% return true. As Oid get larger we may decide.
%%-----------------------------------------------------------------
check_maybe_mask(_Oid, [], _Mask) -> true;
check_maybe_mask([X | Xs], [X | Ys], [1 | Ms]) ->
    check_maybe_mask(Xs, Ys, Ms);
check_maybe_mask([X | Xs], [X | Ys], []) ->
    check_maybe_mask(Xs, Ys, []);
check_maybe_mask([_X | Xs], [_Y | Ys], [0 | Ms]) ->
    check_maybe_mask(Xs, Ys, Ms);
check_maybe_mask([_X | _Xs], [_Y | _Ys], _) ->
    false;   <-------------------------------------------------------------------------- we always fall here
check_maybe_mask(_, _, _) -> 
    true.
%%------------------------------------------------------------------------------------

I have changed the line 347 to "case check_maybe_mask(Oid, SubTree, snmp_view_based_acm_mib:emask2imask(Mask)) of" and this problem was gone


Reason 2.

My vacm.conf:

{vacmSecurityToGroup, usm, "domainSecurity", "domainGroup"}.
{vacmAccess, "domainGroup", "", usm, authPriv, exact, "domainOwnerView", "domainOwnerView", "domainOwnerView"}.
{vacmViewTreeFamily, "domainOwnerView", [1,3,6,1,4,1,<My organization oid>,1,2,1,1,2], included, [1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1]}.
%%------------------------------------------------------------------------------------

The oid of my table is [1,3,6,1,4,1,<My organization oid>,1,2,1,1,2]

But this code tries to optimize working with tables, and it always decide that my oid is shorter than oid of subtree specified in the vacm.conf. So oid of my table is dropped as inappropriate.

-module(snmpa_mib_data_tttn).

811    next_node(D, {tree, Tree, {table_entry, _MibName}},
812 	  Oid, RevOidSoFar, MibView) ->
813    ?vtrace("next_node(tree,table_entry) -> entry when"
814	"~n   size(Tree):  ~p"
815	"~n   Oid:         ~p"
816	"~n   RevOidSoFar: ~p"
817	"~n   MibView:     ~p", [size(Tree), Oid, RevOidSoFar, MibView]),
818    OidSoFar = lists:reverse(RevOidSoFar),
819    case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of
%%------------------------------------------------------------------------------------

So, this code always return false as OidSoFar is shorter than MibView. I have changed the code at line 818 to "OidSoFar = lists:reverse(RevOidSoFar) ++ Oid," and all works well.
%%------------------------------------------------------------------------------------


Unfortunately I cannot know if this changes broke functionality somewhere else. Moreover I've tried to use mask with wildcard applied to table column like this [1,3,6,1,4,1,<My organization oid>,1,2,1,1,2,<RowNum>] [1,1,1,1,1,1,1,1, 1,1,1,0,1,0,0,0] and it's is not working for my table.

I have already sended patch on another problem related to masks: http://erlang.org/pipermail/erlang-patches/2015-April/004766.html. 
Did anybody tested this feature last years? It is totally not works) 

Best regards, Dmitry