Various issues with AGENT++


We would like to use AGENT++ in one of our products, but as it is currently it seems like there are many nullptrs passed around at multiple places, resulting in segfaults, even with the examples.

This can be reproduced on Ubuntu 20.04 with SNMP++/AGENT++ installed into a prefix in /opt, using the iReasoning MibBrowser.

  1. Agentpp::Counter32MibLeaf::get_instance() (mib.cpp:407) gets passed mib=0x0 when a request comes in, without there being a check whether mib is actually valid or not.
  2. Same with Agentpp::snmpCommunityEntry::get_instance() (snmp_community_mib.h:220)
  3. And with Agentpp::snmpEnableAuthenTraps::get_instance() (snmp_group.h:308)

I tried to fix these accesses to invalid pointers by returning the respective instances when mib is 0x0.
After that the static_table example can be successfully walked through in MibBrowser, but in our multithreaded application this results in the RequestLists returning a nullptr when receiving a request, due to being unable to find a valid snmpCommunityEntry in request.cpp:1345.


sorry for the trouble. Not all of the examples have been updated to pass the mib pointer to the constructor of RequestList:

reqList = new RequestList(mib);

Could you please retry with this modification?

Kind regards,

An Update release of AGENT++ with all examples fixed to use the new initialisation scheme will be released 2020-06-10T22:00:00Z.

In addition to using the new RequestList constructor RequestList(Mib*) it is very important to include to following code line before accepting requests:


For more details see:

BTW, AGENT++ 4.3.1 and SNMP++ 3.4.1 are now available. Nevertheless, the above code line needs to be added to existing agent main code if SNMPv3 is enabled.

I’ve not had the time to adapt SNMP++/AGENT++ to their newer versions, but I fixed the startup issues by implementing the missing v3-isms. Works well! Will try the suggested changes to initialization when I have the time and report back in case of issues. Thanks!

Hello again!

We’ve successfully made use of AGENT++ & SNMP++ for our use case, though there is one missing piece or open question that has come up.

It doesn’t seem to be possible to have both SNMPv3 support as well as filter SNMP requests based on their community name.
Our goal is to runtime-switch between being able to use SNMPv3 with authentication as well as have support for v2c walks based on whether the community name matches the runtime configuration. Currently only the “public” community is supported, which we would like to change.
If there’s no way to enable this at the moment this would mean patching of AGENT++, but we would like to hear from you whether there’s a supported approach we could take.


You can of course change communities at runtime using the VACM MIB. Using v1, v2c, and v3 concurrently in arbitrary combination changed at runtime is possible too.
Just study the capabilities of the VACM MIB and the SNMP-COMMUNITY-MIB.

Hope this helps.