[AGENT++] Problems with 3.5.12 (VACM and authorization failure)

[Marek Malowidzki]

Hi,

We have found a number of problems in Agent++ v. 3.5.12 and would like to ask you to explain possible reasons. The problems concern mainly VACM but at the bottom of this post there is another problem.

1.  Agent++ v. 3.5.12g, Snmp++ v. 3.2.9a

Recent changes in usmUserPrivProtocol::prepare_set_request() probably cause problem in the following scenario: We create a new user with authentication and privacy (by cloning). Then we want to disable privacy through sending userSetRequestusmUserPrivProtocol=usmNoPrivProtocol). And it returns INCONSISTENT VALUE, which seems to be wrong. In v. 3.5.12c, it worked correctly.
 
2. VACM views. We observed in a few last releases that VACM views work correctly only if they have been configured at startup time. When we modify views later, at agent runtime, they do not work. That is, views created at runtime do not work while views prepared at startup can be successfully included or removed from access rights for a user group (newly created or existing).

3. The last problem - v. 3.5.12c (currently we cannot easily check it with 3.5.12g). This problem may also be related to VACM (but we cannot be sure).

An SNMPv3 user called "Tomek" is created in an agent with no security (noAuthNoPriv) and is given access to the system branch only. Then, the following message getting 4 scalar variables:

Sending a message to 10.1.0.11:161
Message is:
version  : SNMPv3(3)
---- HeaderData ----
msgID    : 1543495611
msgMxSize: 65535
secLevel : noAuthNoPriv(0),reportable
secModel : USM(3)
---- SecParams  ----
authEngId: %80%00%13p%0510.1.0.11%00%a1
authBoots: 305
authTime : 71192
userName : Tomek
authPars : <none>
privPars : <none>
---- ScopedPDU  ----
ctxEngId : %80%00%13p%0510.1.0.11%00%a1
ctxName  : <none>
---- PDU ----
PDU type : GetRequestPDU(0)
requestId: 616780863
errorStat: 0
errorIdx : 0
variable bindings (4):
[0] object: sysDescr.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysDescr(1)@0]
 value : NULL
[1] object: ifNumber.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).interfaces(2).ifNumber(1)@0]
 value : NULL
[2] object: ifTableLastChange.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).ifMIB(31).ifMIBObjects(1).ifTableLastChange(5)@0]
 value : NULL
[3] object: sysUpTime.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3)@0]
 value : NULL

returns the following:

Received a response from 10.1.0.11:161
Message is:
version  : SNMPv3(3)
---- HeaderData ----
msgID    : 1543495611
msgMxSize: 4096
secLevel : noAuthNoPriv(0)
secModel : USM(3)
---- SecParams  ----
authEngId: %80%00%13p%0510.1.0.11%00%a1
authBoots: 305
authTime : 71192
userName : Tomek
authPars : <none>
privPars : <none>
---- ScopedPDU  ----
ctxEngId : %80%00%13p%0510.1.0.11%00%a1
ctxName  : <none>
---- PDU ----
PDU type : ResponsePDU(2)
requestId: 616780863
errorStat: authorizationError(16)
errorIdx : 0
variable bindings (4):
[0] object: sysDescr.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysDescr(1)@0]
 syntax: OCTET STRING (SIZE(0..255)) DISPLAY-HINT 255a
 value : "SNMP Agent v1.0"
[1] object: ifNumber.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).interfaces(2).ifNumber(1)@0]
 value : NULL
[2] object: ifTableLastChange.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).ifMIB(31).ifMIBObjects(1).ifTableLastChange(5)@0]
 value : NULL
[3] object: sysUpTime.0 [.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3)@0]
 value : NULL

As it can be seen, the content is quite unusual. First, error is set for the whole message (errorStatus) - rather than for the individual variables. errorIndex seems to be invalid (0), as well. Additionally, a value for sysDescr is provided (despite the error - I am not sure if this behavior is ok but usually variable bindings contain nulls in such a case). (It looks like sysDescr was correctly handled but then, for an unknown reason, an error indended for ifNumber propagated for the whole message.) I would expect that values be provided for sysDescr and sysUpTime while the two unavailable variables should have authorizationErrors set in their variable bindings. Is my reasoning correct?

Regards,

Marek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.agentpp.org/pipermail/agentpp/attachments/20030925/acde4a32/attachment.htm