Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts

Looking for resources on programming SNMP?

I know I might be asking a lot but I'm looking for some good resources on writing snmp scripts/applications. I have mentioned in my previous posts that I'm working on a Raspberry Pi monitoring project. My goal is to attach dry contacts (door sensor, on battery, rectifier failure, etc) to the Pi. When an event occurs and the dry contact closes/opens, I would like to write an SNMPtrap to our NMS with the details of the event.

I made some progress yesterday by using pass-through within the snmpd.conf file but I'm looking for some good documentation and examples if possible.

74% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1
9 points · 3 months ago

In general, it's best not to use SNMP traps if you can help it, as they are unsolicited, fire-and-forget UDP packets, which means that your NMS does not know whether to expect them or not. This limitation can be offset slightly by using INFORMs instead of TRAPs, which get re-sent if they don't get an explicit acknowledgement from the receiver, but if you have something blocking the network path between the device and the NMS, you'll never know it. Active tests of ICMP or SNMP are not sufficient to validate the return network path for traps either. The only 100% reliable way to use traps is to have them periodically sent whether there's a problem or not, and then besides the conditional event triggers based on the trap contents, you also need to configure your NMS to trigger an event if it doesn't receive the trap within a certain time limit. So overall, a major PITA.

Using active polls has much simpler failure semantics, but doing it properly means getting an IANA enterprise number, learning how to write your own MIB, converting the MIB into a net-snmp module and adding it your agent. Probably overkill for your purposes.

If you just need to implement a couple simple objects, using the net-snmp exec directive is substantially easier, although a bit limited. Example:

Add a line for each sensor you want to create to snmpd.conf:

exec sensor_1 /bin/sh /tmp/
exec sensor_2 /bin/sh /tmp/

Create the corresponding scripts that fetches the sensor value and returns it as textual output, optionally setting a return code that will get put into extResult.


echo sensor1 value=0, all good!
exit 0


echo sensor2 value=1, oh noes!
exit 1

Restart snmpd, walk UCD-SNMP-MIB::extTable:

# snmpwalk -v2c -c public localhost extTable
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extIndex.2 = INTEGER: 2
UCD-SNMP-MIB::extNames.1 = STRING: sensor_1
UCD-SNMP-MIB::extNames.2 = STRING: sensor_2
UCD-SNMP-MIB::extCommand.1 = STRING: /bin/sh /tmp/
UCD-SNMP-MIB::extCommand.2 = STRING: /bin/sh /tmp/
UCD-SNMP-MIB::extResult.1 = INTEGER: 0
UCD-SNMP-MIB::extResult.2 = INTEGER: 1
UCD-SNMP-MIB::extOutput.1 = STRING: sensor1 value=0, all good!
UCD-SNMP-MIB::extOutput.2 = STRING: sensor2 value=1, oh noes!
UCD-SNMP-MIB::extErrFix.1 = INTEGER: noError(0)
UCD-SNMP-MIB::extErrFix.2 = INTEGER: noError(0)
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:
UCD-SNMP-MIB::extErrFixCmd.2 = STRING:

Keep in mind that this table will be populated in the order that you specify the exec commands in, so if you add additional ones later, you should append them, otherwise your NMS will be referencing the wrong index (assuming you're just using simple fixed gets).

Hope this helps!

level 2

Second that, even on Ent grade equipment (Cisco,HP etc) this thing is never reliable, I prefer pulling SNMP params every second to relying on SNMP traps that you have no assurance it will work as expected when needed.

level 1
obsessed with NetKAT3 points · 3 months ago

don't use SNMP for this. there are many better methods and protocols to use to get telemetry data than SNMP.

don't use SNMP. please.

level 2
Systems Engineer5 points · 3 months ago

Eh, there aren't any that are as widely supported as SNMP.

level 3
obsessed with NetKAT1 point · 3 months ago

huh? the only place SNMP is widely supported is in networking, and that's for historical reasons not technical superiority.

if you're doing something greenfield, don't waste time implementing a fucking SNMP agent. do literally anything else. there are a bazillion ways to push, stream, or pull telemetry data that don't involve ASN.1

level 2
3 points · 3 months ago

Then how about you provide concrete implementation examples for what OP is trying to accomplish? This nonsense is usually just parroted by people who don't actually have any significant experience with SNMP. There's very good reasons why it still dominates in networking.

level 3
Comment deleted3 months ago
level 4

SNMP agents and managers are almost universally supported, both on general purpose and embedded platforms, the protocol has extremely simple semantics, and a fairly compact encoding.

Message queuing protocols are great for the internal bus of an application operating at scale, but are an absurd level of complexity for a project like this.

level 5
obsessed with NetKAT1 point · 3 months ago

where is this compact, secure ASN.1 encoding library you speak of?

level 6

I said the protocol has a relatively compact encoding, which obviously means on the wire.

As you're implying, most of the exploits relating to SNMP agents have been inside their ASN.1 library, however I suspect that's largely because they're using full blown generic implementations, which tend to be quite complex, and therefore have a large attack surface. Furthermore, many of the agents currently in use were written long before exploit hunting was gamified, and simply don't have the same number of concerned third-parties auditing their code that all the new protocols currently in vogue have. That doesn't mean SNMP as a protocol is inherently insecure or unsuitable for any purpose, just that some implementations may have vulnerabilities, which is no different from any specification that has multiple independent implementations.

SNMP only requires a small subset of ASN.1 BER for encoding, and on top of that its PDU specification has a very limited sequence depth and overall format. It doesn't need the power or features of a generic ASN.1 library, those just end up being used for convenience. A scaled back implementation with a declarative parser restricted to just the scope that SNMP requires could easily nullify most or all this class of exploits.

level 3
obsessed with NetKAT1 point · 3 months ago

There's very good reasons why it still dominates in networking

yeah, poor historical decisions. I'm not going to do the OPs googling for them. doing a greenfield implementation of an SNMP agent is lunacy in 2018. if you need to get data off an agent, use any number of popular, well documented, well used push, pull, or streaming open source solutions. prometheus is the first that comes to mind. there are so many more.

level 4

You were the one who was adamant that OP not use SNMP. The relevant quote here would be "if you're not part of the solution, you're part of the problem", the corollary to which would be "if your solution involves 10x the effort in order to accomplish the same outcome, you're still part of the problem".

Also, if you think popular and well documented automatically means a correct and secure implementation, you're just plain delusional.

level 3

Not really. SNMP is udp based, and udp based is best effort. messages get lost, dropped. There is not also an easy way to resync state.

I have seen a few building management solutions leaving blinds half open, 1/3rd open, 3/4ths open, and they all think they are in sync because they use udp to raise and lower. udp get's lost and no mechanism to get state.

Not saying the implementation could not be better designed, but relying on the transport leads to some interesting problems.

level 4

I specifically addressed the issue of UDP unreliability in my response to OP.

SNMP intentionally does not rely on the transport protocol for reliability. That's what client timeout/retry logic is for. By changing from an OOB notification (trap/inform) to an explicit measurement (get/walk/bulk), the impact of transport reliability is greatly diminished.

This isn't to say that SNMP polling doesn't have its limitations, just that these mostly only come into play at very small intervals between queries, dense object hierarchies, or high network round trip time.

level 1

The Python package PySNMP has some pretty good example code. We were able to almost copy-and-paste to get our own SNMP client up and running. I'd start there.

The SNMPTools Unix package also has some great tools for tinkering,

level 2
Original Poster1 point · 3 months ago

Thank you, I will take a look at that again

Community Details





###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post
r/networking Rules
Rule #1: No Home Networking.
Rule #2: No Certification Brain Dumps / Cheating.
Rule #3: No BlogSpam / Traffic re-direction.
Rule #4: No Low Quality Posts.
Rule #5: No Early Career Advice.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.