Age | Commit message (Collapse) | Author |
|
Adresses problems desciribed in
http://erlang.org/pipermail/erlang-bugs/2015-April/004891.html
http://erlang.org/pipermail/erlang-patches/2015-April/004766.html
The original patch also suggested the following fix.
However we need more information to be able to understand if
this is correct or not, and it does not have priority at the moment
for us to investigate.
@@ -816,7 +816,7 @@ next_node(D, {tree, Tree, {table_entry, _MibName}},
"~n RevOidSoFar: ~p"
"~n MibView: ~p", [size(Tree), Oid, RevOidSoFar, MibView]),
OidSoFar = lists:reverse(RevOidSoFar),
- case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar, MibView) of
+ case snmpa_acm:is_definitely_not_in_mib_view(OidSoFar ++ Oid, MibView) of
true ->
?vdebug("next_node(tree,table_entry) -> not in mib view",[]),
false;
|
|
|
|
|
|
|
|
Add utility functions for checking view masks.
Code cleanup, function renaming and comment fix (%% instead of %).
Also updated the mask check in the vacm config file check function.
Finally, release notes and some cosmetic changes to the agent
config-file(s) user guide chapter.
|
|
Dear all,
it's almost a year since I sent the patch attached to this e-mail, and I
just found out that I have not yet gotten a response to it.
I would consider this patch important because it fixes an issue with the
interpretation of data that might be critical for SNMPv3 operation. I
confirmed at that time that erlangs interpretation of
vacmViewTreeFamilyMask is indeed not interoperable with other SNMP
stacks.
Kind regards,
> > > the implementation of SNMP-VIEW-BASED-ACM.mib assumes that the input for
> > > vacmViewTreeFamilyMask is an OID consisting of 1's and 0's only to form
> > > the mask. However, the MIB states that the input should be a bitstring.
> > >
> > > The OID representation of the mask is useful in the code as it speeds up
> > > time-critical code paths when checking access permissions for EACH SNMP
> > > access. Reading/writing the view mask objects is less time-critical.
> > >
> > > Therefore, to fix the issue, convert between OID representation and
> > > bitstring when the vacmViewTreeFamilyMask objects are accessed. This is
> > > done by the patch attached to this e-mail.
>
>
> I'm very sorry for the troubles that I am causing but it seems that the
> previous version of the patch did more than it should: the OID-bitstring
> conversion was also applied to other tables in the same MIB on
> get/get-next requests.
>
> The version of the patch that is attached to this e-mail restricts the
> OID-bitstring conversion to vacmViewTreeFamilyMask alone.
--
Dr. Stefan Zegenhagen
arcutronix GmbH
Garbsener Landstr. 10
30419 Hannover
Germany
Tel: +49 511 277-2734
Fax: +49 511 277-2709
Email: [email protected]
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.
>From aa2acfb8a0b5ae05fc5ba982d78ee5607384a2be Mon Sep 17 00:00:00 2001
From: Stefan Zegenhagen <[email protected]>
Date: Wed, 1 Aug 2012 09:56:15 +0200
Subject: [PATCH] bugfix for vacmViewTreeFamilyMask
The vacmViewTreeFamilyMask is defined to be a bit string in the MIB, not
an OID. However, the MIB implementation assumed the latter, effectively
rendering all attempts to read/set masks via SNMP unsuccessful.
Since the mask is used in hot paths (e.g. access permission checks for
each SNMP operation, the OID representation of the mask has benefits
(e.g. faster processing). Therefore, convert the bitstring to/from its
OID representation when reading/setting any mask object.
|
|
|
|
The get_next implementation of vacmAccessTable did not return all
available table data. Instead, it only returned the first column for
each row, and all columns for the last row available.
Fix the get_next implementation of vacmAccessTable to return all table
entries.
|
|
|
|
There are problems with the handling of vacmAccessTableStatus that cause
some SNMP test suites to report errors.
Most notably, errorneous set operations frequently cause "genErr" errors
to be returned which usually is a sign for bad coding. These "genErr"
errors are usually caused by badmatch exceptions coming from
{ok, Row} = snmpa_vacm:get_row(RowIndex)
if the row does not exist.
This patch fixes the badmatch errors and adjusts the semantic of the
RowStatus handling in that table to be compliant with the RowStatus
textual description of SNPMv2-TC MIB.
|
|
Improve error handling while reading agent config files.
OTP-9943
|
|
Removed the use synchronization mechanism during vacm table dumping.
This could not be placed in the master agent since it was sometimes
used from the master agent. Also is was credated and used from the
top agent supervisor, befor the master agent process was created...
OTP-9851
|
|
changes where made to the VACM security-to-group, access and
view-tree-family tables.
OTP-9367
|
|
|
|
snmp_view_based_acm_mib:snmp_view_based_acm_mib:reconfigure/1 on a
running node, the table vacmAccessTable was not properly cleaned.
This meant that if some entries in the vacm.conf file was removed
(compared to the "current" config), while others where modified
and/or added, the removed entrie(s) would still exist in the
vacmAccessTable table.
Merge branch 'bmk/snmp/vacmAccessTable_cleanup/OTP-8981' into bmk/snmp/snmp419_integration/OTP-9068
Conflicts:
lib/snmp/doc/src/notes.xml
lib/snmp/src/app/snmp.appup.src
lib/snmp/vsn.mk
|
|
is_set_ok and set operation(s), all values of the
vacmAccessSecurityModel column was incorrectly translated
to *any*.
Merge branch 'bmk/snmp/verify_vacm_security_model/OTP-8980' into bmk/snmp/snmp419_integration/OTP-9068
Conflicts:
lib/snmp/doc/src/notes.xml
lib/snmp/src/app/snmp.appup.src
lib/snmp/test/snmp_appup_test.erl
lib/snmp/vsn.mk
|
|
|
|
Also added config file for usm.
And more sed'ing...
|
|
|
|
|
|
the vacmAccessTable whas not properly cleaned.
This means that if some entries in the vacm.conf file was removed
compared to the "current" config), while others where modified
and/or added, the removed entrie(s) would still exist in the vacmAccessTable.
|
|
is_set_ok and set opteration(s), all values of the
vacmAccessSecurityModel column was incorrectly
translated to *any*.
|
|
|
|
opteration(s), all values of the vacmAccessSecurityModel column was
incorrectly translated to "any".
|
|
vacmViewTreeFamilyTable.
There is still vacmAccessTable and vacmContextTable.
|
|
|
|
|