After getting SNMPv2 traps working from external devices in Check_MK, our users decided they wanted to use SNMPv3. In tcpdump I see the traps coming in to the server’s port 162 and I can send an SNMPv3 trap from the localhost to the localhost and see it in the Event Console’s Recent Event History. But the SNMPv3 traps coming in from external devices don’t show up at all.
Does the Linux server’s snmptrapd play a part in this process? Or is there some extra snmpd config that’s required. Or does anyone know what the problem might be.
Yes, they are configured, and they work when I send a trap on the command line to localhost from the Centos 7 server that CMK is installed on. We’ve also got auth and encryption turned off for the testing phase. So something is broken between the 162 port on the server and the Check_MK application. Just for SNMPv3 though - SNMPv2 works.
Since there don’t seem to be many reports or posts on problems with SNMPv3 traps, figured that the problem must be something simple we got wrong. A tcpdump showed that our devices are adding 12 zeros to the end of the engine id and /var/log/mkevent.log with SNMP trap processing in debug mode revealed the same issue. Adding those zeros to the engine IDs in our Check_MK config fixed this issue.