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

[Frank Fock]

Hi Marek,

Thanks for your bug report. AGENT++ v3.5.13 is now available
for download from http://www.agentpp.com which should fix
all the problems you listed.

Best regards,
Frank Fock

Marek Malowidzki wrote:

>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
>
>
>  
>