Problem with sending SNMP V3 Traps using agent++ cpp

I am trying to send SNMP - V3 traps using "Agentpp::MasterAgentXMib::instance->notify ( “”, trapOid, &varBind, 0 ) " But it is not sent.I’m using snmp++,agent++ and agentx++ together.

( agent++ version 4.1.2
agentX++ version 2.1.2
snmp++ version 3.3.11 )

Here is the log!

700101.00:44:02: -1403587504: (1)EVENT : AgentX Master Agent starting
19700101.00:44:02: -1403587504: (1)INFO : AgentX: listening for AgentX requests on UNIX (port): (/var/agentx/master)
19700101.00:44:02: -1403587504: (1)EVENT : AgentXMaster: listening on TCP (socket)(port): (133), (705)
19700101.00:44:53: -1267043248: (5)EVENT : NotificationLog: Logging (target)(oid)(vbs): (), (1.3.6.1.4.1.50565.1.2.0.3), (0)
19700101.00:44:53: -1267043248: (2)EVENT : Notification not sent (reason) (addr) (params): (no access), ( AC 11 02 15 00 A2 …
), (TestTrap)

Hi Rahul,

As the log output explains, the notification is not send because of “no access”. That means, that there is no matching access entry in the VACM (SNMP-VIEW-BASED-ACM-MIB) for the notification OID and all the variable binding OIDs (in your cause there aren’t any).
Thus, you need to modify or add an access entry in the above MIB for OID 1.3.6.1.4.1.50565.1.2.0.3 (or one of its prefixes) to allow the notification to be sent out.

Best regards,
Frank

Hi Frank,
Thanks for the information.I am new to this agentpp framework.
I am adding the access entry in VACM table.
The Code snippet is given below.

m_vacm->addNewContext ( “” );
m_vacm->addNewGroup ( SNMP_SECURITY_MODEL_USM, “user1”,
“defaultGroup”, storageType_nonVolatile );
m_vacm->addNewAccessEntry ( “defaultGroup”, “”, SNMP_SECURITY_MODEL_USM,
SNMP_SECURITY_LEVEL_AUTH_PRIV, match_exact,
kAccessView, kAccessView, kAccessView, storageType_nonVolatile );
m_vacm->addNewView ( kAccessView, “1.3”, “”, view_included, storageType_nonVolatile );
m_vacm->addNewView ( kAccessView, “1.0.8802”, “”, view_included, storageType_nonVolatile );

Is there anything else we need to configure for this? If so can you please give an example!

Hello @AGENTPP , @jkatz ,

Here is the output of snmpwalk command for 1.3.6.1.6.3.16.1.4 ( VacmAccessEntry )

iso.3.6.1.6.3.16.1.1.1.1.0 = “”
iso.3.6.1.6.3.16.1.2.1.3.3.5.97.100.109.105.110 = STRING: “defaultGroup”
iso.3.6.1.6.3.16.1.2.1.4.3.5.97.100.109.105.110 = INTEGER: 3
iso.3.6.1.6.3.16.1.2.1.5.3.5.97.100.109.105.110 = INTEGER: 1
iso.3.6.1.6.3.16.1.4.1.4.12.100.101.102.97.117.108.116.71.114.111.117.112.0.3.3 = INTEGER: 1
iso.3.6.1.6.3.16.1.4.1.5.12.100.101.102.97.117.108.116.71.114.111.117.112.0.3.3 = STRING: “defaultView”
iso.3.6.1.6.3.16.1.4.1.6.12.100.101.102.97.117.108.116.71.114.111.117.112.0.3.3 = STRING: “defaultView”
iso.3.6.1.6.3.16.1.4.1.7.12.100.101.102.97.117.108.116.71.114.111.117.112.0.3.3 = STRING: “defaultView”
iso.3.6.1.6.3.16.1.4.1.8.12.100.101.102.97.117.108.116.71.114.111.117.112.0.3.3 = INTEGER: 3
iso.3.6.1.6.3.16.1.4.1.9.12.100.101.102.97.117.108.116.71.114.111.117.112.0.3.3 = INTEGER: 1
iso.3.6.1.6.3.16.1.5.1.0 = INTEGER: 0

I have checked all the possibilities from our side. But still the issue occurs.
Could you please help me resolving this?

Your access entry is for the context ‘defaultGroup’ with exact match, but the notification is not send on behalf that context. Therefore no access is granted.

Hello @AGENTPP ,

Thanks for the inputs. After checking the code I found that we have two MIB instances in a single process. May be that’s why its not working properly.
Should we need to upgrade the agentpp version, currently we are using 4.1.2?
I have noticed in the latest version the support is available : How to migrate from AGENT++ 4.2.x (or older) to 4.3.0 (or newer) to be able to use multiple agents in a single process? - AGENT++ - AGENTPP

Regards
Rahul

Hi Rahul,

I do not know why you want to have two MIB instances in one process (agent). Maybe you might With AGENT++ 4.3.0 you can easily have two agents (and thus two separate Mib instances) in the same process. But I doubt that this is really what you need.

Best regards,
Frank