[AGENT++] agentX++ interoperability with NET-SNMP version 5.7.3.rc1

Frank Fock fock at agentpp.com
Sun Nov 23 09:50:11 CET 2014


Hi Claus,

There are several index allocation strategies available in AgentX++. You should choose
the strategy that fits best to your shared table index definition. Using the wrong 
strategy could lead to a duplicate index registration. 

Best regards,
Frank

> On 22 Nov 2014, at 21:51, Claus Klein <claus.klein at arcormail.de> wrote:
> 
> Hi Frank,
> 
> First of all, without a shared table, the example works.
> 
> I posted the Problem to the net-snmp-coders.
> 
> Begin forwarded message:
> 
>> From: Bill Fenner <fenner at gmail.com>
>> Subject: Re: agentX++ interoperability with NET-SNMP version 5.7.3.rc1
>> Date: 22. November 2014 16:55:04 MEZ
>> To: Claus Klein <claus.klein at arcormail.de>
>> Cc: net-snmp-coders <net-snmp-coders at lists.sourceforge.net>
>> 
>> On Sat, Nov 22, 2014 at 5:34 AM, Claus Klein <claus.klein at arcormail.de> wrote:
>> Hi,
>> 
>> I have tested net-snmp as master agent with current agentpp subagent.
>> The most important problem I found is:
>> 
>> 
>> The row destroy at subagent does not work together with net-snmp master agent!
>> 
>> 
>> The agentX++ subagent send the (Index Deallocate) command before it send the response to
>> the (Commit Set) command.
>> 
>> This seems a Protocol error and the master agent (net-snmp) sends
>> a response with errstat=261 after receiving the (Index Deallocate) message.
>> 
>> 261 is "Index not allocated".  This seems like a perfectly normal response to Index Deallocate.  Do you have earlier traces showing that the subagent had allocated that index?
>> 
>> 
>> I think that this is a valid exchange - the spec says "After carrying out the management operation, the subagent sends ..." -- and in this case, the management operation included sending an Index-Deallocate PDU, which the master agent parsed and responded to (with an indication that the index being deallocated was not allocated).  The subagent then failed to respond to retransmissions of the CommitSet, so the master agent closed the session since there's not much else to do.
>> 
>> There is definitely a bug in the subagent here, since it should not go silent like this - once it gets the response to the Index-Deallocate it should continue processing of the CommitSet. There may or may not be a bug in the master agent here -- if the subagent had properly allocated the index, and then got the error that the index wasn't allocated when it tried to deallocate it, that's a master agent bug.  You need to capture the tracing where the subagent sends the IndexAllocate PDU to find that out.
>> 
>>  Bill
>> 
>> 
> 
> 
> I did not explicit allocate an index. But why is this necessary?
> I simple created a row with:
> 
> snmpset -r0 -t10 -v3 -u unsecureUser -n subagent localhost:4700 'netSnmpHostRowStatus."nmsv6"' = createAndWait
> 
> I know that a shared Table make no sense with a RowStatus.
> (It was only a sample without really shared at master agent site)
> But I would expect, that the generated shared table code works as it is.
> 
> Is it possible to make the code more robust and ignore the AGENTX_INDEX_NOT_ALLOCATED error?
> I did not found a reason, why the (row destroy) agentx-CommitSet-PDU is not replied.
> (the error is only logged)
> 
> If not, where can I found a sample how do it right?
> Where do I find a guide to work with a shared table and the agentx_index_strategy?
> 
> ================================================================
> The implementation is not symmetric:
> 
> MibTableRow* AgentXSharedTable::add_row(const Oidx& ind)
> {
> 	if ((ind.len() == 0) || (generator.size() == 0)) return 0;
> 
> 	// check whether row exists
> 	MibTableRow* new_row = find_index(ind);
> 	bool existing = (new_row != 0);
> 	if (!new_row) {
> 		new_row = new MibTableRow(generator);
> 		new_row->set_index(ind);			// <<<<<<<<<<<<<<<<<<<<<<<<<<< not allocated?
> 	}
> 	// register row
> 	Oidx subtree(new_row->get_nth(0)->get_oid());
> 	unsigned int u = (*(generator.last()->key()))[0];
> 	AgentXRegion r(subtree, (unsigned char)(key()->len()+1), u);
> 	backReference->register_region(myContext, r, timeout, TRUE, this); 
> 	//below event is fired when confirmation of registration is received
> 	//fire_row_changed(rowCreateAndGo, new_row, ind);
> 	if (existing)
> 		return new_row;
> 	return content.add(new_row);	
> }
> 
> void AgentXSharedTable::remove_row(const Oidx& ind)
> {
> 	Oidx o(ind);
> 	MibTableRow* r = content.find(&o);
> 	// deallocate index
> 	Vbx* vbs = create_index_vbs(ind);
> 	if (vbs) {
> 	  backReference->deallocate_index(myContext, vbs, index_len, this, new Oidx(ind)); 	// >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 	  delete[] vbs;
> 	}
> 	// unregister row
> 	Oidx subtree(r->get_nth(0)->get_oid());
> 	unsigned int u = r->last()->get_oid()[key()->len()];
> 	AgentXRegion reg(subtree, (unsigned char)(key()->len()+1), u);
> 	backReference->register_region(myContext, reg, 0, FALSE); 
> 
> 	fire_row_changed(rowDestroy, r, ind);
> 
> 	if (r) notready_rows.remove(r);
> 	content.remove(&o);
> }
> ======================================================
> 
> With regards,
> Claus
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> https://oosnmp.net/mailman/listinfo/agentpp



More information about the AGENTPP mailing list