We used to work with PySNMP version 4.3.1 to receive SNMP V3 traps, and it worked perfectly. Recently, we upgraded to version 4.4.12, and the traps were not received anymore.
I debugged the issue and found that the call to __getUserInfo at service.py line 759 throws an exception:
# 3.2.4
try:
(usmUserName,
usmUserSecurityName,
usmUserAuthProtocol,
usmUserAuthKeyLocalized,
usmUserPrivProtocol,
usmUserPrivKeyLocalized) = self.__getUserInfo(
snmpEngine.msgAndPduDsp.mibInstrumController,
msgAuthoritativeEngineId, msgUserName
)
I think it happens because the engine ID in the trap is not the same as the engine ID of the user I created for receiving the traps.
In this question the answer was to use the same engine ID for the receiving user and the trap sender.
If this is the case, why did it work in PySNMP version 4.3.1? Was it a bug in the library? Is engine ID matching not really mandatory?
With SNMPv3 security model, SNMP engine ID of SNMP entity issuing SNMP TRAP (so called authoritative engine ID) must be known to the receiving part. That's because the one-way nature of TRAP communication leaves no opportunity to exchange SNMP engine ID between talking SNMP entities.
Unfortunately, there was a bug in pysnmp in that regard - that probably explains why it worked for you before.