Besides secName and secLevel=3, do we need to set-up anything for security authentication and security privacy separately like we add a user to the table and to USM?
Hi, please have a look at the code of add_v3_trap_destination(). This function only offers a small part of the configuration possibilities. If you can live with the limitations of the function, call it for each agent (addr, secName, secLevel) with unique values of name and tag.
You will have to add the needed users to the USM (through the USM user table).
Hi,
I could use examples\multi_agent\src\agent.cpp USM user table and add_v3_trap_destination() to send out multi_agent trap snmpv3 including msgAuthoritativeEngineID, msgUserName, msgAuthenticationParameters, and msgPrivacyParameters.
vacm->addNewGroup(SNMP_SECURITY_MODEL_USM, “SHADES”,
“testGroup”, storageType_nonVolatile);
vacm->addNewAccessEntry(“testGroup”, “”,
SNMP_SECURITY_MODEL_USM,
SNMP_SECURITY_LEVEL_AUTH_PRIV,
match_prefix,
“testView”, “testView”,
“testView”, storageType_nonVolatile);
vacm->addNewView(“testView”, “1.3.6”, “”,
view_included, storageType_nonVolatile);
I also could snmpGet OID=1.3.6.1.6.3.10.2.1.1.0 of all 16 agent ports to verify the SNMP-FRAMEWORK-MIB::snmpEngineID.0 (iso.3.6.1.6.3.10.2.1.1.0) string values to make sure I could initialize correctly (they end in 5C/5D/5E/5F/60/61/…).
// add non persistent SNMPv3 engine object
mib.add(new V3SnmpEngine(v3mp));
However, the last byte of the trap msgAuthoritativeEngineID does not match with snmpEngineID. They are the same (example 0x5F/0x62) randomly for all the trap output ports.
I tried to increase the debug level and could see the incoming request context engine id was correct (they end in 5C/5D/5E/5F/60/61/… for multi-agents)
(2)EVENT : RequestList: request received: (secmod)(seclev)(cid)(cname):
Then, it went through the VACM.
(7)DEBUG : Vacm: getViewName for: (model) (name) (level) (type) (context)
(7)DEBUG : Vacm: getGroupName: (model) (name):
(7)DEBUG : Vacm: getViewName:
(7)DEBUG : Vacm: Access requested for: (viewName) (oid):
(8)DEBUG : VacmViewTreeFamilyTable: isInMibView:
Then, it went to v3MP building message with a random SecurityEngineID.
5)DEBUG : v3MP: Building message with (SecurityEngineID) (securityName) (securityLevel) (contextEngineID) (contextName):
Why do we receive the correct incoming engine ID but send out another engine ID? Do we need to do some extra steps to correct engine ID before add_v3_trap_destination() or mib->notify()? How do we troubleshoot the v3MP: Building message with (SecurityEngineID)?
the NotificationOriginator does not pass its Mib pointer to the SnmpRequestV3::send() function and therefore it falls back to the static Mib::instance pointer. This will be fixed for the next release.
The needed patch is below. Best Regards,
Jochen
----------------------- src/notification_originator.cpp -----------------------
index e08f0a1..9e736e0 100644
@@ -445,7 +445,7 @@ int NotificationOriginator::send_notify(ListCursor<MibTableRow>& cur,
target->set_version(version1);
#ifdef _SNMPv3
- status = SnmpRequestV3::send(*target, pdu);
+ status = SnmpRequestV3::send(mib, *target, pdu);
nlmLogEntry* logEntry = get_nlm_log_entry();
if (logEntry) {
logEntry->add_notification(target, id, vbs, size, contextName,
@@ -486,7 +486,7 @@ int NotificationOriginator::send_notify(ListCursor<MibTableRow>& cur,
}
#ifdef _SNMPv3
- status = SnmpRequestV3::send(*target, pdu);
+ status = SnmpRequestV3::send(mib, *target, pdu);
nlmLogEntry* logEntry = get_nlm_log_entry();
if (logEntry) {
OctetStr ceid;