Recently I noted that another vendor’s SNMP agent was emitting a usmStatsUnknownUserNames report instead of an authentication failure response when SNMPv3 was misconfigured. Unfortunately (for me), the manager software wasn’t configured to look for those reports and interpret the data properly. In an effort to simulate the behavior in-house, I turned to my subclassed BasicAgent I use for the integration tests. Sadly, no matter what I do (invalid username, empty username, various permutations of ReportSecurityLevelStrategy set on the agent), I always get a PDU.RESPONSE type back with the error status of SNMP_ERROR_AUTHORIZATION_ERROR and never a PDU.REPORT type.
Is there a secret incantation I am missing to alter the behavior of the Agent to emit those reports? I am using SNMP4J 2.8.0, but moving to a slightly newer version didn’t seem to change anything.
The short answer is yes, there is the ReportHandler in the Snmp class that is processing the report and which is then returning the response with an error status to the API.
That handling is needed to process REPORTS that need reprocessing of the request message, like usmNotInTimeWindow report.
You can write your own handler to achieve what you are looking for. I will give further hints later here…
Hmm…I looked over the class in question but I think you may be attempting to answer a different question than the one I was asking. It looks to me that the report (if issued from the agent) would get returned to the manager (after retries are exhausted) in the onResponse() handler. I am pretty sure that I have the manager end now covered, but I can’t seem to test the behavior with a simulated agent. My issue seems more on the agent side on the conversation where it doesn’t seem like my BasicAgent ever emits the report I am looking for.
Before you initialise the USM. It worked for me with SNMP4J 3.4.4 a few seconds ago.
The default setting requires that the security name is know to the agent to return a properly authenticated and optionally encrypted REPORT PDU. Sending noAuthNoPriv reports could impose a security risk. That’s why it isn’t the default.