Here is another minor patch which get rid of some confusion when debugging this. A log message in get_v3_info() only printed the community, even though the header was listing that community and security name were printed:
--- a/src/snmp_community_mib.cpp
+++ b/src/snmp_community_mib.cpp
@@ -201,6 +201,7 @@ bool snmpCommunityEntry::get_v3_info(OctetStr& security_name,
LOG_BEGIN(loggerModuleName, INFO_LOG | 2);
LOG("snmpCommunityEntry: found v3 info for (community)(security_name)(tag)");
LOG(community.get_printable());
+ LOG(security_name.get_printable());
LOG(transport_tag.get_printable());
LOG_END;
Ok, thanks for the clarification. Then it is like I guessed. My fix should work - at last in theory. Bt yours cannot work for proxy applications, because the mapping to the proxy target is done based on the security-name from the coexistence info (by definition of RFC).
I had created my own runtime configured test scenario. I and not using the example for that.
I will check if I missed a case with the fix or what is still going wrong here…
SNMP++3.6.2 contains the necessary fixes (coexistence_security_name was not copied by =-operator and copy constructor which lead to losing its value in multi-threaded agent.
AGENT++ 4.7.1 has been released too.