-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
noSuchInstance result doesn't seem to be handled well #66
Comments
Can you run isolate the issue in a small test script and run it with these two lines added to the script:
this will print out each SNMP packet. I am currently having trouble to reproduce the issue. I don't have an OID which raises the "noSuchInstance" error on my test-machine. Having a hexdump of the packet which causes the error will help me isolate and fix the issue. I can confirm that the issue exists however. I have identified the part in the code which is responsible for the issue but would still like to have a way to reliably reproduce it. Without it I can't be totally sure that I simulated the issue correctly. |
Sure, just let me know what else I can do to help. Here's the output of a multi-get of two OIDs, the first one exists and the second does not. I've redacted the community.
|
the last block of binary data is enough by the way. This will be the packet returned by the device and will be the one which causes the error. |
Thanks for the dump. This will help a lot. I'll try to work on this in the coming days. |
This is related to #54 and requires a
I will fix the type-detection properly which requires a bit more work but will be beneficial in the long-run. |
I'm slowly moving forward on this. It takes me a bit longer than expected because I have trouble finding an authoritative information on how the special types
And, in order to avoid losing more time in that rabbit-hole I will continue with these values. I am confident that they are correct. If someone has a link to the definitions, I am curious to see it. |
References #66 and #54 The values are now supported but this brings microscopic changes to the API. I will keep this a *minor* change because the previous behaviour of the API was incorrect, and code relying on that behaviour is hence incorrect as well. The biggest impact this could have stems from the fact that code which previously incorrectly raised a "NoSuchOID" exception, now returns ``None`` (in the pythonic API) and either ``NoSuchInstance()`` or ``NoSuchObject()`` in the "raw" API. So any code catching ``NoSuchOID`` might require changes.
References #66 and #54 The values are now supported but this brings microscopic changes to the API. I will keep this a *minor* change because the previous behaviour of the API was incorrect, and code relying on that behaviour is hence incorrect as well. The biggest impact this could have stems from the fact that code which previously incorrectly raised a "NoSuchOID" exception, now returns ``None`` (in the pythonic API) and either ``NoSuchInstance()`` or ``NoSuchObject()`` in the "raw" API. So any code catching ``NoSuchOID`` might require changes.
I'm in the process of cleaning up the code-changes and will try to finish this up this week. In case you are still watching this you can already give the code on the branch "fix/1.6.3" a go and let me know if it works for you. |
I've tried that branch out against some of the endpoints that didn't previously work, and it seems to work now. |
Actually I'm not sure it does fully fix the original issue, which was, in a multi-get request, I want to be able to get the partial result and know which ones failed. |
using puresnmp 1.6.2.post1
I'm doing get and multiget requests. If I ask for an OID that doesn't exist, it returns noSuchInstance in the result (type code is 0x81). This doesn't seem to be handled properly.
The text was updated successfully, but these errors were encountered: