[AGENT++] All rows in mib table are deleted when snmpd is restarted

[Frank Fock]

Hi,

This is unfortunately a limitation of the AgentX protocol. See section
7.1.4.2.2 of RFC 2741 for details. The only workaround for your
problem is, to disable index allocation for this table (only using
region registration).

Best regards,
Frank

Am 17.12.2012 13:06, schrieb Efrat Lefeber:
> I found the problem:
>
>
>
> I have a mib table with two integer indexes.
>
> When I run two subagents, one which inserts a row to the table with index 1.1 and the other inserts a row to the table with index 1.2, the index registration of the second subagent  fails at the master agent.
>
> I don't understand why the master agent doesn't treat my two indexes as an index combined together. Because both indexes contain 1, the index allocation fails.
>
> This is the way I create the table and the index:
>
>
>
> const Agentpp::index_info myindexInfo[2] = {{sNMP_SYNTAX_INT, FALSE, 1, 1}, {sNMP_SYNTAX_INT, FALSE, 1, 1}}; const Agentpp::Oidx myOidx[2] = {"1.3.6.1.4.1.6790.1.1.50.1.1.1","1.3.6.1.4.1.6790.1.1.50.1.1.2"};
>
>
>
> const Agentpp::index_info myindexInfo[2] = {{sNMP_SYNTAX_INT, FALSE, 1, 1}, {sNMP_SYNTAX_INT, FALSE, 1, 1}}; const Agentpp::Oidx myOidx[2] = {"1.3.6.1.4.1.6790.1.1.50.1.1.1","1.3.6.1.4.1.6790.1.1.50.1.1.2"};
>
>
>
> finjan::SubAgentProxy::TableEntry::TableEntry()
>
>          : Agentpp::AgentXSharedTable("1.3.6.1.4.1.6790.1.1.50.1.1", myindexInfo, 2, myOidx, mib, "") {
>
>          add_col..
>
> }
>
>
>
> .........
>
>
>
>
>
> if (tableEntry->allocate_index(oidxIndex) == false( }
>
>          std::cerr << "ERROR: error allocating index " << oidxIndex.get_printable() << std::endl;
>
>          return 1;
>
> }
>
> Nicolas replied to this problem:
>
> "I saw that when we try to register an index, the subagent check for the unicity of that index. But it check the unicity on each index individually, not on the whole key if there's several index like your case.
>
> And for example if you use the function any_index() from the table class (probably SharedXTable) you'll see that the key is always incremented in this manner for a 2 index key : 1.1, 2.2, 3.3, ...
>
>  From my point of view, that's an issue. If it is not, there's something I'm completely missing about that snmp protocol ;)
>
> I "solved" my problem by not registering the index of the rows before adding them. But I could do that because my shared tables were in fact not shared at all."
>
>
>
>
> ________________________________
>
> This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/agentpp

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231