SNMPv3 traps received from IP addresses not managed by openNMS will be (almost) silently discarded because no SNMP session exists for these addresses and the SNMP4J transport mapping therefore does not know which security-name to accept as valid. This is true regardless of whether valid USM credentials are present in snmp-config.xml. On my system, the following message appears in snmp4j-internal.log when such a trap arrives:
2008-12-08 20:34:05,205 WARN [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.MessageDispatcherImpl: 220.127.116.11.18.104.22.168.1.3.0 = 0
While this sounds like a REPORT PDU, I don't see such a PDU actually being sent.
Initializing the SnmpPeerFactory in Trapd.onInit() does not resolve this issue. I think it may take some loving handling of the transport mapping on Trapd startup to get past this issue.
According to the customer reporting this issue, V3 traps at security level authPriv worked in openNMS 1.3.2; probably the much older version of SNMP4J used by that release was less strict about this issue.