Trap receiver support about snimpy HOT 5 OPEN

I don't have an opinion on this. This doesn't seem an easy fit for Snimpy API style, but if you manage to find a way to integrate into the existing style, why not.

from snimpy.

I looked a bit into it and I think the way it would fit is:

• adding agent or at least in memory table support (like #6 but without serving),
• each trap/notification would create an in memory "agent" from the variable bindings,
• you can browse the trap content as if you were querying the agent, e.g. agent.snmpTrapOID.

With this the notification receiver could be completely separate and would not pollute the API.

from snimpy.

I like this plan. 👍

But I cannot help right now.

from snimpy.

In case somebody would be interested, I found an easier alternative: I use the Net-Snmp smpd server with the snmptrapd receiver as a subagent, and connect to the SNMP server with snimpy.
The notifications can be accessed in the NOTIFICATION-LOG-MIB

I had to use this trick to make it work (or I guess you could configure SNMPv3):
http://freesnmp.com/net-snmp/faqs/#trapdlog

from snimpy.

Didn't know about that. Nice workaround.

from snimpy.