SNMP Manager

[shortbloke]

Hey,

I am working on adding the functionality to act as an SNMP Server or Manager. In the meantime, if you need to do this, look at the library here: https://github.com/shortbloke/Arduino_SNMP_Manager

I was going to use your updated agent library to rework the Manager, however, if this is something you're already processing with, there seems little point in me spending time on this. Can you confirm that you plan to release a manager in the near future?

Thanks Martin/Shortbloke

[0neblock]

Hey @shortbloke, I've been working on it slowly over the last couple of weeks, you can find my progress on the 'https://github.com/0neblock/Arduino_SNMP/tree/snmp-manager' branch.

I'm struggling around some specifics of the API to provide for it. I'm trying to setup a "poller" so that you provide a bunch of OIDs, and the library autmatically polls them at a set interval.

I'm programming this while I don't actually have a need for using it, I'd just like to strengthen the library a little bit (and practice a bit more c++ as I go), so coming up with the API is much more dificult than when I had an actual use case. Very happy for your input as you have had a real use for it before.

[shortbloke]

Thanks, I'll take a look at the branch. Some initial thought (before I've looked at the branch, feel free to ignore)

• A poller seems more of an example of implementation of the manager library or even a 3rd derivative project, than being the manager library. A good poller implementation will need to have spread polling (over poll interval) track the last poll time of each and every request to ensure an accurately repeated poll interval. The poller would likely also be responsible for retry logic, if it were added.
• I'm not sure the manager should be part of the agent, it's unlikely most people will want/need both sets of capability at the same time, so having them separate, with some common shared libraries I think would make more sense.
• Ideally, I think the manager should support making calls using GET, GET NEXT and GET-BULK, against more than 1 device, SET calls I suspect are a lower priority requirement.
• WALK might need to handle WALKing devices that only support GET/GET-NEXT, and also support those that support GET-BULK, for better performance.
• GET-BULK support would require strategies to stay within packet size limits, so has some added complexity, especially if the overall packet size is configurable.

Based on the limited amount of knowledge gained from people using my manager implementation, GET support seems key, being able to use an Async implementation is probably next on the list so that responses aren't missed if busy in some other method when the reply comes in.