snmp Mibcontext

SNMP++/AGENT++
1

Hi frank ,
This is my first post here :slight_smile:

Thanks in advance.

Is there any way to add multiple community strings with multiple mibcontext??

I am using snmp++,agent++ and agentx++ together.

2

Hi,
I probably do not completely understand the purpose of your question, but the answer is:
“yes, you can do that”.

However, you seem to have problems with that? So where are you stuck?
You need to use SNMPv3 SNMP-COMMUNITY-MIB together with the VACM MIB.

Best regards,
Frank

3

Thanks.
You can forget about previous question. I can explain my current situation.

  • I want to add agentX++ support for my existing SNMP agent(built using agent++ and snmp++).
  • I had modified my SNMP agent by refering sample master agent application which came along with agentx++ sdk.
  • While connecting an SNMP sub agent( I have to use a sub agent which built using net snmp library) master agent got crashed.
  • Seems like crash is due to some conflicts related with snmp-v2-mib which is altready loaded in master agent.
  • After loading snmp-v2-mib bya specifying a context name, crash issue got solved( i don’t know whether it a right way of doing or not).
  • My sub agent is using default context while communicationg with master agent. I can query this mib informations. Seems working fine.
  • But I can not query snmp-v2-mib information. Its responding with “no such object error”. Seems like master agent still looks in default context.

Hope you got a brief idea.

4

With “crash” do you mean a segmentation fault?
That should not happen in any case! Do you have the DEBUG log output of the agent before that happens?

With AgentX you cannot register a MIB subtree at a node in the tree where already the master agent has registered a MIB object (a MibEntry subclass in case of AGENT++).

If a subagent tries that, the request will be rejected with an appropriate error status. The subagent should then continue registering other objects.

The other option is (as you found out), moving the conflicting MIB objects in the master to a different SNMPv3 context. But then:

  1. You need to use that context in your SNMPv3 requests to access those objects of the master.
  2. The VACM needs to be configured to allow access to that new context.
  3. The SNMP-COMMUNITY-MIB needs to be configured to map a community to that new context, if you want to access those objects with SNMPv1/v2c too.

Hope this helps.

5

Thanks for your reply. Here is the debug logs.

19700102.00:06:22: -1225478144: (5)INFO : saveBootCounter: Saved counter (file) (engine id) (boot): (/camsettings/application/snmp/SNMP_Engine_Boots), ( 80 00 13 70 05 30 30 3A 30 39 3A 66 32 3A 30 30 …p.00:09:f2:00
3A 34 64 3A 36 38 :4d:68
), (299)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added auth protocol (id): (3)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added auth protocol (id): (4)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added auth protocol (id): (5)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added auth protocol (id): (6)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added auth protocol (id): (7)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added auth protocol (id): (2)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added priv protocol (id): (2)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added priv protocol (id): (4)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added priv protocol (id): (20)
19700102.00:06:22: -1225478144: (6)INFO : AuthPriv: Added priv protocol (id): (21)
19700102.00:06:22: -1225478144: (3)INFO : AuthPriv: Added default Auth and Priv protocols.
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.4.1.4976.3.1.2.2.2.1), (11.115.117.98.97.103.101.110.116.32.105.112), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (11.115.117.98.97.103.101.110.116.32.105.112)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.4.1.4976.3.3.1.3.1.1), (7.112.114.105.109.97.114.121), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (7.112.114.105.109.97.114.121)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.12.1.2.1), (48.46.48.46.48.46.48.47.48), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (48.46.48.46.48.46.48.47.48)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.12.1.3.1), (67.111.104.117.72.68.84.114.97.112), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (67.111.104.117.72.68.84.114.97.112)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.13.1.1.1), (67.111.104.117.72.68.84.114.97.112), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (67.111.104.117.72.68.84.114.97.112)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.16.1.1.1), (0), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (0)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.16.1.2.1), (1.6.112.117.98.108.105.99), (142)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (1.6.112.117.98.108.105.99)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.16.1.2.1), (2.6.112.117.98.108.105.99), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (2.6.112.117.98.108.105.99)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.16.1.4.1), (9.118.49.118.50.71.114.111.117.112.0.1.1), (303)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (9.118.49.118.50.71.114.111.117.112.0.1.1)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.16.1.4.1), (9.118.49.118.50.71.114.111.117.112.0.2.1), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (9.118.49.118.50.71.114.111.117.112.0.2.1)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.16.1.5.2.1), (11.100.101.102.97.117.108.116.86.105.101.119.1.1), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (11.100.101.102.97.117.108.116.86.105.101.119.1.1)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.18.1.1.1), (112.117.98.108.105.99), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (112.117.98.108.105.99)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.18.1.2.1), (48.46.48.46.48.46.48.47.48), (62)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (48.46.48.46.48.46.48.47.48)
19700102.00:06:22: -1225478144: (4)EVENT : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.18.1.2.1), (65.103.101.110.116.88.45.73.80), (0)
19700102.00:06:22: -1225478144: (3)INFO : MibTable: deserialize: row exists -> not loaded (index): (65.103.101.110.116.88.45.73.80)
19700102.00:06:22: -1403042736: (1)EVENT : AgentX Master Agent starting
19700102.00:06:22: -1403042736: (1)INFO : AgentX: listening for AgentX requests on UNIX (port): (/var/agentx/master)
19700102.00:06:22: -1403042736: (1)EVENT : AgentXMaster: listening on TCP (socket)(port): (118), (705)

19700102.00:06:42: -1403042736: (1)EVENT : AgentXMaster: accepting new connections
19700102.00:06:42: -1403042736: (1)EVENT : AgentXMaster: new subagent connection on UNIX port
19700102.00:06:42: -1403042736: (1)WARNING: AgentXMaster: unable to stat unix domain (socket): ()
19700102.00:06:42: -1403042736: (4)EVENT : AgentXMaster: new peer added (sd)(name)(connecttime)(timeout): (119), (86802), (5)
19700102.00:06:42: -1403042736: (5)EVENT : MasterAgentXMib: opened new session (id)(peer)(sessionCount): (1), (119), (1)
19700102.00:06:42: -1403042736: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389153), (0), (0)
19700102.00:06:42: -1403042736: (2)EVENT : MasterAgentXMib: sent response (tid)(peer)(uptime): (0), (119), (8680254)
19700102.00:06:42: -1403108272: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389154), (0), (0)
19700102.00:06:42: -1403108272: (2)EVENT : MasterAgentXMib: sent response (tid)(peer)(uptime): (0), (119), (8680254)
19700102.00:06:42: -1403108272: (2)EVENT : MasterAgentXMib: registered new (context)(lower)(upper): (), (1.0.8802.1.1.2.1.1.1), (1.0.8802.1.1.2.1.1.2)
19700102.00:06:42: -1403108272: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389155), (0), (0)
19700102.00:06:42: -1403108272: (2)EVENT : MasterAgentXMib: sent response (tid)(peer)(uptime): (0), (119), (8680255)
19700102.00:06:42: -1403108272: (2)EVENT : MasterAgentXMib: registered new (context)(lower)(upper): (), (1.0.8802.1.1.2.1.1.2), (1.0.8802.1.1.2.1.1.3)
19700102.00:06:42: -1403108272: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389156), (0), (0)
19700102.00:06:42: -1403108272: (2)EVENT : MasterAgentXMib: sent response (tid)(peer)(uptime): (0), (119), (8680255)
/*
removed some registering logs due to max chars supported in replay reached :slight_smile:
*/
19700102.00:06:43: -1403108272: (2)EVENT : MasterAgentXMib: registered new (context)(lower)(upper): (), (1.0.8802.1.1.2.1.5.32962.1.3.1.1.1), (1.0.8802.1.1.2.1.5.32962.1.3.1.1.2)
19700102.00:06:43: -1403108272: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389283), (0), (0)
19700102.00:06:43: -1403108272: (2)EVENT : MasterAgentXMib: sent response (tid)(peer)(uptime): (0), (119), (8680316)
19700102.00:06:43: -1403108272: (2)EVENT : MasterAgentXMib: registered new (context)(lower)(upper): (), (1.0.8802.1.1.2.1.5.32962.1.3.2.1.2), (1.0.8802.1.1.2.1.5.32962.1.3.2.1.3)
19700102.00:06:43: -1403108272: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389284), (0), (0)
19700102.00:06:43: -1403108272: (2)EVENT : MasterAgentXMib: sent response (tid)(peer)(uptime): (0), (119), (8680317)
19700102.00:06:43: -1403108272: (2)EVENT : MasterAgentXMib: registered new (context)(lower)(upper): (), (1.0.8802.1.1.2.1.5.32962.1.3.2.1.3), (1.0.8802.1.1.2.1.5.32962.1.3.2.1.4)
19700102.00:06:43: -1403108272: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389285), (0), (0)
19700102.00:06:43: -1403108272: (2)EVENT : MasterAgentXMib: sent response (tid)(peer)(uptime): (0), (119), (8680317)
19700102.00:06:43: -1403108272: (2)EVENT : MasterAgentXMib: registered new (context)(lower)(upper): (), (1.0.8802.1.1.2.1.5.32962.1.3.3.1.2), (1.0.8802.1.1.2.1.5.32962.1.3.3.1.3)
19700102.00:06:43: -1403108272: (3)EVENT : AgentX: sending agentx pdu (sd)(type)(sid)(tid)(pid)(err)(errind): (119), (18), (1), (0), (1690389286), (0), (0)
19700102.00:06:43: -1403042736: (3)EVENT : MasterAgentXMib: adding agent caps from (sid)(id)(descr): (1), (1.0.8802.1.1.2), (lldpMIB implementation by lldpd)
Aborted

6

The other option is (as you found out), moving the conflicting MIB objects in the master to a different SNMPv3 context. But then:

  1. You need to use that context in your SNMPv3 requests to access those objects of the master.

Could you please help me to specify context names in SNMPv3 requests? I am using PoweSNMP tool as manager.

  1. The VACM needs to be configured to allow access to that new context.

    mib->add ( “testcontext”, new SnmpV2Mib ( ) );
    Vacm* vacm = new Vacm ( *mib );
    reqList->set_vacm ( vacm );
    vacm->addNewContext ( “” );
    vacm->addNewContext ( “testcontext” );
    vacm->addNewGroup ( SecurityModel_USM, “unsecureUser”, “newGroup”, storageType_volatile );
    vacm->addNewAccessEntry ( “newGroup”,
    “”, // context- sub agent using default context
    SecurityModel_USM,
    SecurityLevel_noAuthNoPriv,
    match_exact, // context must mach exactly
    // alternatively: match_prefix
    “newView”, // readView
    “newView”, // writeView
    “newView”, // notifyView
    storageType_nonVolatile );

     vacm->addNewAccessEntry ( "newGroup",
                           "testcontext",        // new context
                           SecurityModel_USM,
                           SecurityLevel_noAuthNoPriv,
                           match_exact,  // context must mach exactly
                           // alternatively: match_prefix  
                           "newView2", // readView
                           "newView2", // writeView
                           "newView2", // notifyView
                           storageType_nonVolatile );

 vacm->addNewView ( "newView", "1.0.8802", "",
                    view_included, storageType_nonVolatile );
 vacm->addNewView ( "newView2", "1.3", "",
                    view_included, storageType_nonVolatile );

// Still I am getting no such object error for the oids in newView2. Seems working fine for other view - newVeiw2.

  1. The SNMP-COMMUNITY-MIB needs to be configured to map a community to that new context, if you want to access those objects with SNMPv1/v2c too.
    // I don’t know how to do this. Could you please help?
7

Do you have the DEBUG log output when of the master agent for us, when you try to GET something at the 1.3 subtree using the “testcontext” SNMPv3 context? That will help analysing why the request is rejected.

The “Aborted” signal does indeed point to a memory fault. Could you please run the master in a debugger to get the stack trace when the signal is being caught? That would be very helpful. Are you using the latest version of AgentX++?

8

Versions -
Agent++ : agent+±4.2.0
Agentx++: agentx+±2.1.2
SNMP++: snmp+±3.3.13

This is bt output from gdb.

Thread 22 “LegacyServer” received signal SIGSEGV, Segmentation fault.
[Switching to LWP 8412]
Agentpp::ListAgentpp::MibTable::clear (this=0x1216358)
at …/include/agent_pp/List.h:248
248 …/include/agent_pp/List.h: No such file or directory.
(gdb) bt
#0 Agentpp::ListAgentpp::MibTable::clear (this=0x1216358)
at …/include/agent_pp/List.h:248
#1 Agentpp::MibTable::~MibTable (this=0x1216244, __in_chrg=)
at mib.cpp:1159
#2 0x004186e8 in Agentpp::snmpv2MibSysOREntry::~snmpv2MibSysOREntry (
this=0x1216244, __in_chrg=)
at agent++/AutogeneratedClasses/snmpv2_mib.cpp:1738
#3 0xb65b290c in Agentpp::Mib::add_agent_caps (this=, context=
…, sysORID=…, sysORDescr=…) at mib.cpp:2959
#4 0xb647fd68 in Agentpp::MasterAgentXMib::add_ax_agent_caps (
this=, context=…, sysORID=…, sysORDescr=…, session=…)
at agentx_master.cpp:336
#5 0xb6488570 in Agentpp::MasterAgentXMib::process_ax_addagentcaps (
this=0x11e41e8, req=…) at agentx_master.cpp:1185
#6 0xb6480494 in Agentpp::MasterAgentXMib::process_ax_request (this=0x11e41e8,
req=…) at agentx_master.cpp:934
#7 0xb6487d8c in Agentpp::MasterAgentXMib::process_ax_master_request (
this=0x11e41e8,
fds=0xb6487d8c <Agentpp::MasterAgentXMib::process_ax_master_request(fd_set*, int*)+748>, nfds=0xad81ad10) at agentx_master.cpp:855
#8 0xb647e560 in Agentpp::MasterAgentXMib::process_agentx (this=0x11e41e8)
at agentx_master.cpp:780
#9 0xb648070c in Agentpp::AgentXThread::run (this=0x121a530)
at agentx_master.cpp:153
#10 0xb65f2c44 in Agentpp::TaskManager::run (this=0x121cf10) at threads.cpp:996
#11 0xb65f3db8 in Agentpp::thread_starter (t=0x121cf70) at threads.cpp:705
#12 0xb6fad0c0 in ?? () from /lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Do you have the DEBUG log output when of the master agent for us, when you try to GET something at the 1.3 subtree using the “testcontext” SNMPv3 context? That will help analysing why the request is rejected.
// As I said , I was testing using PowerSNMP manager tool. There wasn’t any option to provide context name in this tool. That’s why I got confused. Now I had tried using snmpget tool from netsnmp. Now it seems fine. Thanks for your advice. :slight_smile: . Could you please help me to do the same in V2?

9

Thank you for providing the stack trace. With that the issue is clear:

  • You are using a self generated snmpv2_mib.cpp which does not match the sysOREntry table implementation AGENT++ expects to store the SysOREntry rows it receives from the subagent.
  • Because, that object is being looked up by context and OID, the agent fetches the “wrong” one and the casting then causes the segmentation violation.

How to fix this issue cleanly?

  1. Do not generate your own SNMPv2-MIB and add it to the master in any context. (Theoretically it would be possible though, but that would need to reimplement/overwrite a lot of code)
  2. At least do not use add any object with the sysOREntry OID to the Mib in any context to avoid this memory error by wrong casting. You can however, subclass the existing sysOREntry and then add such an instance, that would not be any problem.

Regarding SNMPv1/v2c context setup for communities, please refer to the corresponding RFC: