I have and SNMPv3/USM user with noAuthNoPriv. If I browse the MIB tree I don’t receive any data. In Wireshark I can see that MIB Explorer sends a request and the agent sends its response. But MIB explorer does not show any data received but prints ‘SET request timed out’ on the status bar. It works if I enable the ‘Principal’ checkbox. But the ‘Principal’ checkbox’s description tells me that it enables this user to receive traps.
If the USM user’s security level is set to authNoPriv, it works even if the ‘Principal’ checkbox is unchecked.
The principal checkbox allows localisation of auth and priv keys with the remote engine ID on incoming PDUs in order to be able to receive so called “unconfirmed PDUs” (i.e., traps) from that target when such a PDU arrives and the localisation has not been done yet. Without “Principal” being activated, localisation is only allowed for outgoing requests.
For noAuthNoPriv users, this setting should not have any impact.
I cannot image why a noAuthNoPriv RESPONSE PDU should not be accepted because localisation is not needed at all for such a packet. Nevertheless, I will investigate it.
Are you sure that the remote agent is using a different engine ID than your MIB Explorer?
Have you tried to inspect the response using the Packets tab?
Sorry for the late response. I haven’t got any notification. This happens only with SNMPv3/USM target, not with SNPv3/direct targets. I’ve captured the packets:
The first two request are with ‘Principal’ disabled (MIB Explorer re-sends the request). The last request is with ‘Principal’ enabled. The content seems to be identical, but MIB Explorer shows nothing on the tree or browse tab. It prints ‘SET request timed out’ although it’s not a SET request but a GET request (GETBULK to be precise).
OK, thank you. I have found the bug in SNMP4J 3.8.0-3.9.0. SNMP4J 3.9.1 will fix it and that fix will be included in the next MIB Explorer Pro version which should be available in about two weeks (or less).