Comments (21)
I just haven't had the time, energy, or access to v1 devices at home to implement anything
JFYI: you could experiment/test against the publicly available SNMP agent simulator.
from puresnmp.
A new version of puresnmp has been released today. Support for SNMPv1 is still experimental but should be working for basic requests. To enable SNMPv1, you have to pass in a V1() credential instance into the client.
Let me know if this works for you.
from puresnmp.
This was incidentally what led me to implement this. To make it easy to use. The new versions is ever so slightly more complicated because I decided to introduce the "Client" and "PyWrapper" classes. But I feel confident that it is still an acceptable compromise between ease-of-use, proper decoupling and flexibility.
If you find something that feels "unnatural", cumbersome or annoying, let me know and I will see if I can come up with an improvment.
from puresnmp.
Hi,
It would not shock me to have support for SNMPv1. But implementation may need some refactoring of existing code. I don't like what I did with the external API. I am talking about the fact that you simply do:
from puresnmp import get
get(...)
The idea behind this was making it as simple as possible to use. However, this not causes problems with the other protocol versions (v1 and v3). Especially v3 takes a complete different set of arguments aside from the OIDs. So the signature or puresnmp.get
would become quite messy.
I was thinking about having some kind of factory returning a "client" instance with the .get
, .walk
, ... methods. Something along the lines of this:
from puresnmp import Client
client = Client.create(Client.V2C, 'community')
result = client.get(ip, oid)
There are some open questions in my mind though about this:
- Which arguments do you pass to
Client.create
(ip, community, timeout, ...)? - Is the factory method a good idea? Why not have separate classes? Or move the existing functions to separate modules and completely forego classes?
- ...?
I have not really put much thought into it yet as SNMPv3 is planned, yes, but it is currently low-priority. All devices I am querying are in a secure and isolated network and would only suffer from the SNMPv3 overhead. So migration to v3 is not yet really planned, and as long as that's not the case I am leaving this on the backlog.
If you would like I would more than welcome a proposal for a SNMPv1 implementation!
My primary concerns about the end-result are:
- Is the external API simple?
- Does the external API not force any arguments on the end-user which are unnecessary?
- Is the external API not overly repetitive. The choice of classes, factories and which arguments will be specified where would have a big impact on this point.
- Are the in/out arguments "pythonic"?
from puresnmp.
Thanks for the quick reply.
Yeah, I see the issues with the external API. As far as I know, v1 is similar to v2 in terms of configuration (ip, oid, port, community, timeout). So to add v1 support, you could add a "version" argument, and have the public functions just call the proper version for v1 or v2.
The problem is, as you said, that doesn't work for v3 without contaminating the version-agnostic API calls with a bunch of v3-specific arguments.
The class approach would work well I think. It's a common idiom I've seen in other projects, and of course brings the benefits of using classes.
Another option I've seen is having separate sub-modules for each version. An example of this would be:
from puresnmp.v1 import get
get(ip, community, oid)
from puresnmp.v2 import get
get(ip, community, oid)
It's somewhat ugly, but it does have the advantage of providing the same API with only minor changes to the imports. Also, multiple versions could still be used in the same program, it would just require extra imports for each version:
import puresnmp.v1 as v1
import puresnmp.v2 as v2
import puresnmp.v3 as v3
v3.get(ip, community, oid, user=username, key=key) # Silly contrived example of v3
A little more work, but still infinitely better than PySNMP IMO.
from puresnmp.
I'm currently drowning a bit in work on other projects. I will look into this in a few weeks time.
Considering the notes on the overall API design you might also want to look at #3. I never received any replies on my last comments and the PR has run stale.
Maybe we could merge both efforts into a more useful API... even if it's not backwards compatible. This is where semver comes in handy :)
from puresnmp.
I've started refactoring the API in the past few days and looked at this issue again. It seems that all that is needed to support SNMPv1 is to change the version number in the header. At least that is all that I could find. If that's really all that is needed, it should be trivial to implement.
I don't know if this is still something you need one year after you initially added this issue, but I will see to implement it nonetheless. The new architecture should make this feasible.
from puresnmp.
I think there are a couple of other nuisances one might want to keep in mind when implementing dual v1/v2c support. Notably:
- v2c has
Counter64
type - v2c misses
NetworkAddress
type - v1 has unconstrained
INTEGER
type, while v2c has is as a 32-bit signed int - v1 has completely unique TRAP PDU while v2c reuses command PDU layout
May be something else, take a look at RFC3584 for complete information on that matter.
from puresnmp.
Thanks for the link @etingof. I'll have a look. It seems that most implementation difference would lie in the "set" command (by simply refusing unsupported types), and, as you mention, traps.
Traps are currently not yet supported, but I realise that this would be good to have a possibility to receive those as well.
from puresnmp.
It seems that most implementation difference would lie in the "set" command (by simply refusing unsupported types)
More or less, modulo slightly different NetworkAddress
PDU structure.
On the other hand, it may not be convenient for the clients to use differing library calls when talking to v1 or v2c agent....
In the RFC linked above the designers suggested building a mediation layer (called proxy) which would convert differing types/layouts so that the caller would always deal with the same abstractions regardless of the underlying protocol version used.
from puresnmp.
Yes. But that's one of the premises of this library anyway. To transparently convert between Python and SNMP types wherever possible. For set
commands this is unfortunately not 100% transparent as the client must specify which type should be sent to the agent. Especially in cases where one Python type maps to multiple SNMP types.
from puresnmp.
v1 support would definitely still be useful for my work. However, I just haven't had the time, energy, or access to v1 devices at home to implement anything, apologies.
from puresnmp.
@GhostofGoes no worries. I'm in the same boat, which explains the delayed reply 😃
I have pushed back the refactoring for too long now because I did not want to break backwards compatibility too soon. But I am motivated to go ahead with it now that the library has been battle-tested in our internal infrastructure for quite some time.
I might be able to to a transitional release which still supports the old API with added deprecation warnings, so it should be actually possible to avoid breaking too many things.
And given that the differences between v1 and v2 seem to be fairly small this shouldn't take too long. I just need to read through the RFCs first.
from puresnmp.
@etingof That is awesome. Thanks for letting me know. I was unaware of this!
from puresnmp.
I would really love the ability to make a v1 query
from puresnmp.
The latest release (v1.9.0) should have some support for SNMPv1, via #77 (thanks @revmischa)
from puresnmp.
I am planning to follow RFC-3411 (see #84) for the next major release, which should make it much cleaner to support SNMPv1.
This RFC outlines an architecutre for SNMP applications with different message processing models (f.ex. SNMPv1 and SNMPv2). Following that RFC, supporting SNMPv1 would only need an implementation of that message processing model.
I will leave this issue open as a way to keep an eye on SNMPv1 support.
Given that SNMPv1 and SNMPv2 are fairly similar it should be possible to reuse much of the SNMPv2 code (which is already evident from #77).
from puresnmp.
Please explain how to use the library with snmp version 1???
from puresnmp.
Please explain how to use the library with snmp version 1???
from puresnmp import get
from puresnmp.const import Version
print(get("10.0.20.4", "public", "1.3.6.1.4.1.318.1.1.1.1.1.1.0", version=Version.V1))
See the "version" attribute
from puresnmp.
Wow, thanks for implementing this!
I'll definitely give it a whirl if I get some time in the next week or two. Would love to be able to use puresnmp again instead of pySNMP 😄 (not to imply that pySNMP is bad, it's just way too complicated for my relatively simple use cases).
from puresnmp.
I was able to test this change against a v1 device with a few OIDs that return simple strings.
The wrong bit was being set for the version, but that was a simple fix (the PR #102 is literally a single-character change). It seems to be working fine now for simple OIDs.
I'll continue to test next week (if I have time) with more complex data types like tables.
from puresnmp.
Related Issues (20)
- v2.0.0rc1 on pip doesn't contain the necessary files. HOT 16
- when v2.x can install from pip HOT 3
- SNMPv3 authPriv not working for specific vendor. HOT 19
- ERROR: No matching distribution found for pack==1.1,==1.3; extra == "rest" HOT 3
- Cookbook link broken / trap example HOT 1
- Trap receiver throws exception HOT 1
- table and bulktable api is not identical
- Circular dependency error?
- get("1.3.6.1.2.1.2.1.0") good; get(OID("1.3.6.1.2.1.2.1.0")) throws exception HOT 1
- mportError: cannot import name 'get' from 'puresnmp HOT 3
- How to get value from DateAndTime snmp-type? HOT 2
- puresnmp.transport.SNMPClientProtocol.datagram_received sometimes throws asyncio.exceptions.InvalidStateError
- Documentation is down HOT 2
- V3 support out of the box, identifier 3?
- Limited examples
- Issue with importing typing library in Python 3.7 HOT 1
- bulkwalk loops forever if a buggy snmp server loops HOT 7
- Asyncio Traps HOT 2
- IndexError: list index out of range
- IndexError: list index out of range
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from puresnmp.