Would int32_t or int64_t impact the hashing algorithm in MD5 or SHA as part of authentication? When I try to use security level 2 (sl2, AuthNoPriv, SHA or MD5) I receive Wrong Digest errors. The third check fails (digest does not match).
I am using the SNMP++ console tools (v3.51) with the Agent++ example agent (v4.6) in a linux64 environment (localhost/4700). The v1, v2, and v3 sl1 modes get & set values fine.
I have noticed the SMINT32 appears to be a long and has a cast method to act as a long. Depending upon the environment a long can be 32 or 64 bits. I believe when HP originally developed SNMP++ the I16L32LL64 bits may have been used. Currently Win64 is IL32LLP64 and Linux64 is I32LP64.
I am also trying to reproduce the problem on a Windows 10 environment but have not been able to compile the example agent yet.
Note: This is such a basic feature, I may have something different wrong.
Note: As authentication is not working, I am also unable to use security level 3 (AuthPriv). I am using WolfSSL for privacy protocols. But my current focus is SL2.
Hi,
as you wrote, this is a basic feature and I expect that the cause of the problem is one of the following: incompatible compiler settings for compilation of the crypto library, snmp++ and agent++; Headers used during compilation do not match libraries used when linking.
On the level of Auth and Priv classes in auth_priv.cpp there is no SmiInt32 involved. You could directly use the AuthMD5::password_to_key() and AuthMD5::auth_out_msg() functions to verify that the produced hash values are the same for each application.
And now after writing all above, I notice that you are using WolfSSL: Maybe this library needs some additional initialization that snmp++ is not aware of. So I suggest a repeated test of the two functions above.
Kind regards,
Jochen
Thank you for the reply. I will look into the functions mentioned. The compiler settings were discovered via the autogen make process. I will check if the config files are congruent.
An interesting update: The SNMP++ console tools are able to use security level 3 with a device’s SNMPv3 agent (probably not Agent++). Using SHA and AES128. This appears to limit the issue to the Agent++ example agent.
Well, some wild guess from my side: Are you using the right passwords for the users?
For -sl1 -snunsecuredUser, no passwords (works).
For -sl2 -snSHA, using -uaSHAUserAuthPassword (Wrong digest authentication failure)
For -sl3 -snSHADES, using -uaSHADESUserAuthPassword and -upSHADESUserPrivPassword (Wrong digest authentication failure)
Note: Until there are special characters in a password, I don’t need any quotes or escaped characters on the command line.
Wrong digest authentication failure – displays debug messages “SHA authentication FAILED.” and “usmProcessMsg: Authentication failure.”. The Wrong Digest counter is incremented on both the ATM_MIB/agent and console snmpWalk.
When connecting to an actual device, the snmpWalk and snmpGet both work with -sl3 -authSHA -privAES128, with the device’s credentials.
Update: The issue has been found and resolved.
“The cause of the problem is […] incompatible compiler settings for compilation of the crypto library, snmp++ and agent++;” jkatz
When the agent code is compiled with gcc Sanitize Address and Sanitize Undefined Behavior, the WolfSSL Authentication stops working. WolfSSL’s issue tracker notes issues found when run with sanitizers. Removing the following compiler options, re-enables authentication.
-fsanitize=address -fsanitize=undefined
Thanks for your help.