[AGENT++] GetNext behaviour for Non-Accessible OIDs

Rajesh Semwal rsemwal at sta.samsung.com
Tue Oct 28 17:36:01 CET 2003


Hi Frank,

Thanks for your response.

Actually in my previous mail, I had guessed that agentpp does not skip the
non-accessible oid for SNMPv2c simply looking at the code. The find_next()
function in MIB class does not check for the access rights when returning
the mib leaf/table. After running the code I made following observations.

1. We cannot add a non-accessible mib leaf into the MIB. The agentpp does
not let us add any such node. I am not an expert in MIB, but I guess that
it's a reasonable restriction. 

2. However I was able to add non accessible mib leaf in a MibTable as a
column. I expected it as some index can be columnar object too in a table.
But when I tried to snmpwalk such a Mib using SNMPv2c, the agentpp did not
skip the non-accessible column in the table. It returned accessDenied after
which the
snmpwalk aborted.

Following is the piece of code that adds the table with two rows.

   MibTable *table = new MibTable("1.3.6.1.4.1.4982.1");
   table->add_col(new MibLeaf("1", READONLY, new SnmpInt32(5678)));
   table->add_col(new MibLeaf("2", NOACCESS, new OctetStr("Rajesh"))); 
   table->add_col(new snmpRowStatus("3"));
   table->add_row("120");
   table->add_row("130");
   mib.add(table);

The snmpwalk result was following:


snmp.snmpInPkts.0 : Counter: 38
snmp.snmpOutPkts.0 : Counter: 39
snmp.snmpInBadVersions.0 : Counter: 0
snmp.snmpInBadCommunityNames.0 : Counter: 0
snmp.snmpInBadCommunityUses.0 : Counter: 0
snmp.snmpInASNParseErrs.0 : Counter: 0
snmp.snmpInTooBigs.0 : Counter: 0
snmp.snmpInNoSuchNames.0 : Counter: 0
snmp.snmpInBadValues.0 : Counter: 0
snmp.snmpInReadOnlys.0 : Counter: 0
snmp.snmpInGenErrs.0 : Counter: 0
snmp.snmpInTotalReqVars.0 : Counter: 48
snmp.snmpInTotalSetVars.0 : Counter: 0
snmp.snmpInGetRequests.0 : Counter: 0
snmp.snmpInGetNexts.0 : Counter: 51
snmp.snmpInSetRequests.0 : Counter: 0
snmp.snmpInGetResponses.0 : Counter: 0
snmp.snmpInTraps.0 : Counter: 0
snmp.snmpOutTooBigs.0 : Counter: 0
snmp.snmpOutNoSuchNames.0 : Counter: 0
snmp.snmpOutBadValues.0 : Counter: 0
snmp.snmpOutGenErrs.0 : Counter: 1
snmp.snmpOutGetRequests.0 : Counter: 0
snmp.snmpOutGetNexts.0 : Counter: 0
snmp.snmpOutSetRequests.0 : Counter: 0
snmp.snmpOutGetResponses.0 : Counter: 62
snmp.snmpOutTraps.0 : Counter: 1
snmp.snmpEnableAuthenTraps.0 : INTEGER: disabled
snmp.snmpSilentDrops.0 : Counter: 0
snmp.snmpProxyDrops.0 : Counter: 0
4980.1.0 : INTEGER: 1234
4980.2.0 : OCTET STRING- (ascii):       How are you?
4980.3.0 : Unsigned32: 4567
4980.4.0 : Counter: 7890
4982.1.1.120 : INTEGER: 5678
4982.1.1.130 : INTEGER: 5678
snmpwalk: SNMPv2: Access is denied for variable.


Please let me know if it's the expected behavior or I am doing something
wrong.

Thanks,
Rajesh


-----Original Message-----
From: fock at agentpp.com [mailto:fock at agentpp.com] 
Sent: Thursday, October 23, 2003 5:26 AM
To: Rajesh Semwal
Cc: "'agentpp at agentpp.org'"; 'Frank Fock'
Subject: Re: [AGENT++] GetNext behaviour for Non-Accessible OIDs


Hi Rajesh,

A GETNEXT should never return an error (in SNMPv2c/SNMPv3)
in the error status field. Thus, the agent should
skip all not-accessible and all objects that are not in
the view of an user on GETNEXT or GETBULK.

I am pretty much sure that AGENT++ behaves this way. Why
do you think that it does not? Do you have an example?

Thanks,
Frank

Rajesh Semwal <rsemwal at sta.samsung.com> schrieb am 23.10.2003, 00:28:47:
> 
> 
> Hi,
> 
> Can someone please tell how an agent is supposed to behave when it
receives
> a get_next request from the manager for an OID that is not accessible.
> Should the agent get the next valid read-permissible OID in the MIB? 
It
> seems like that Agentpp agent returns an error indication if the OID is
not
> accessible. Any opinion?
> 
> Thanks,
> Rajesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.agentpp.org/pipermail/agentpp/attachments/20031028/abf880d9/attachment.htm 


More information about the AGENTPP mailing list