[AGENT++] VACM 3.5.13 problem

Marek Malowidzki malowidz at wil.waw.pl
Fri Dec 19 16:47:27 CET 2003


Sorry for late response. Due to end of the year, we had a bit of mess here.

> Hi Marek,
>
> I assume that you use GETBULK in both cases, when accessing
> table and scalar instances, right? Does the agent really hangs?
> Is it not responding to the single request or to all type of requests?
> Can you send me a trace log of the agent?

Not quite. Scalars are accessed using GET while tables are retrieved with
GET-BULK. It looks like it really hangs, i.e. it is impossible to read
anything else (GET, GETBULK, both do not work anymore). I seem that both
SNMPv1 and v3 are blocked but we will make sure on Monday.

We will try to collect traces on a PC. On our embedded system, it is quite
difficult.

> One last question, what do you mean with "revoking access to a MIB"?
> Do you restrict OID access for a subtree or do you remove a
> securityToGroup mapping?

Hmm.. VACM views are changed - so I believe we restrict the access to the IP
(if it matters) MIB.

Best regards,

Marek

> Thanks,
> Frank
>
> Marek Malowidzki wrote:
>
> >Hi all,
> >
> >I have a (somewhat general) question about possible VACM changes in
Agent++
> >3.5.13. We noticed today the following problem (agent 3.5.13): when an
> >SNMPv3 user is revoked an access to a MIB, scalar variables are handled
> >correctly (with SNMPv2 error) but an attempt to read tables causes the
agent
> >hang (no response is returned within a resonable time frame even if
GET-BULK
> >max-repetitions is set to a low value).
> >
> >We are not sure, of course, that this is agent++ bug - this may be our
> >fault. However, some time ago, before 3.5.13 (which fixed a number of
> >problems with VACM), this phenomenon did not happen.
> >
> >What should we do to provide sufficient information to exmplain this?
> >
> >Best regards,
> >
> >Marek
> >
> >_______________________________________________
> >AGENTPP mailing list
> >AGENTPP at agentpp.org
> >http://agentpp.org/mailman/listinfo/agentpp
> >
> >
> >
>
>
>




More information about the AGENTPP mailing list