I’ve been assigned to implement snmpv3 on a product that is currently using snmpv1 with snmp++v3.2.25. I am new to this and having been having a lot of difficulty all week trying to transform the current GET to get data from a remote system I have snmpv3 set up on. To simplify it even further, i have it set to NoAuthNoPriv.
In the get_integer function we have, we called the snmp get function, passing in the pdu with the oid of the device, a ctarget, a callback function where it checks for errors and then sees which functions to call after. Going off the API documentation for snmp++, I’ve been putting together something I think makes sense but with no luck.
What I’ve done so far is I created a v3MP which also creates a USM. I then set the USM discovery mode on and I add the user that I have set up on the remote device (security name with no authentication and no encryption).I made a constructor for UTarget that assigns the remote device address to it and I hard-coded the same security name as in the USM and remote device. I have the security model parameter set to 1 (not too sure what this is). I have switched to using a UTarget in the snmp get function but I can’t seem to receive a value (when looking at the pdu received in the callback function).
I’m not too sure if I am missing some major component or am completely misunderstanding something. I don’t see how the USM is connected to the snmp get function I call. Does the UTarget get the user from the USM based off the security name?
Using UTarget for SNMPv3 is correct. I guess, the agent responds with a report PDU or with an error status. Because you did not wrote that you updated the VACM of the agent, I assume that this is the root cause.
In the VACM MIB you need to assign a view to the new SNMPv3 user you created.
I have changed the security model to 3 as suggested. I’m a little confused as to how to add the view of the new user to the VACM MIB as I can’t see any classes that relate to this. Is this outside of the cpp application I am writing?
Also I printed out the error message of the the received PDU which is a report PDU. The error is “SNMPv3: USM: Unknown EngineID”. When i created the v3MP I added in the engineid found in my snmp.conf on my computer. I didn’t add an engineid to the UTarget as I have set the USM to discovery mode. Is this error related to not adding the new user view to the VACM MIB or something on its own?
The VACM has to be changed on the agent side. If you are developing the manager (command generator) then the VACM outside of your code. Sorry, I thought you have to setup/configure/develop the agent too.
You are right, if you enabled the discovery mode, SNMP++ should recognise the unknownEngineId report and use the reported engine ID in the REPORT PDU to resend the request to the agent.
A reason for not receiving the payload can then be:
A too low timeout (payload PDU does not arrive in time, but REPORT does)
Security level or model are not set to noAuthNoPriv(1)/snmpv3(3).
Checked again and I am discovering the remote engineid and adding it to the table.
I think the issue might be on setting the local engineid when initializing the v3MP. What is the best way to find out the engineid of a system? This was an issue I had early on but I ended up using an engineid found in a snmpd.conf file on the computer but now I think this is either wrong or not the proper format.
Also, when i try to get the value of the pdu I send and the pdu I get back, the status I get back is -10 which is ‘#define SNMP_CLASS_INVALID -10 //!< snmp::mf called on invalid instance’. Does this happen because a value does not exist on either pdu? What does mf stand for?
Engine IDs need to be defined unique within a domain (or better unique worldwide). There are several strategies for that. Most of them include IP or MAC addresses or any portion thereof plus some vendor ID. See the USM RFC for details.
The SNMP_CLASS_INVALID error refers to some fatal error. Most likely some basic configurations or initialisation is not properly done?
Thank you for all the help, I was able to solve the issue. We’re running snmp++v3.2.25. I looked through the newest changelog and saw that in snmp++v3.3.8 there was this fix: “Fixed: SNMPv3 requests always resulted in an unknown engine id report, if the used SnmpTarget did not contain any port information.”
I did not have any port information, therefore by adding port 161 to the UdpAddress it fixed the issue and I am able to get and set values without any problems.