SNMPv3 authPriv not working for specific vendor. #104
Comments
|
Oh... this is going to be a fun one to dig into. One thing that would help me is to include the debug-logging if you can. Note that this will include encrypted bytes and - if possible - you should change the privacy-/encryption-key and the auth-password to something safe (i.e. not your real password/key) before executing the script with debug logging. Encryption is notoriously hard to debug and having the debug logs, which include the exchanged packets will make this a tiny bit less difficult. To do this, simply add the following two lines to the top of your script: and then add the contents of Again, I can't repeat this often enough: Change your auth-password and priv-key before doing that. Otherwise you will share your secrets publicly in this thread 😉 |
|
Don't worry, the credentials used here were created just for this ticket on the device so i don't share secret credentials in this thread. Here is the debug.log |
|
Thank you for the debug log. I hope this will lead me onto the right track. Again, considering that this is encrypted it's not going to be trivial and I can't give you a good time estimate.
Perfect. So I assume the values you used were the same as in the original ticket (that is: username= |
|
That's right! Same values from the original ticket. |
|
A quick "from the top-of-my-head" analysis: My suspicion is that it has something to do with the "discovery message". We can see in the debug log 2 request/response pairs are exchanged. The first is most likely the "discovery" packet in which the client (in this case Considering that the error message we get says "Not in time window" leads me to believe that it has something to do with that. Now for some wild guessing: The "time-window" message might suggest that the message which follows the discovery message comes too late. Either there's a latency problem (but that's unlikely given that other tools work), or the second message messes up the timing information. But the latter is also unlikely given that it works for other devices. OR, the device is suuuuuper fussy and really expects packets to be exchanged extremely fast. We'll see. The above is just a summary for myself and whoever is stumbling across this. |
|
As an update: I'm still working on this. I ran into an unexpected side effect with pycrypto (it's no longer supported) and needed to switch to This is unrelated and switching to cryptography will surely not fix this "out of time window" issue, but it currently prevents me from digging deeper into it. |
|
I found something that could explain the behaviour and am working on a solution. It might take a couple of days as I'm currently swamped with a project with higher priority. I might need your help in verifying the behaviour as - at the moment - I don't have a device which triggers this error myself. |
|
No problem at all on the timeline. I am more than happy to assist in the testing of this as well! |
|
Hey Hey! |
|
Hi. Sorry for the radio silence. A couple of bumpy weeks at the office and this issue needed me to dig in deeper into the RFCs as expected. My biggest slowdown right now is that I have no physical device that lets me reproduce the issue so I need to triple and quadruple check that I implement it properly. I have now the pre-release My internal tests seem fine but I don't know yet if it fixes this issue right here. This depends on the exact behaviour of the device you are interfacing with. Your packet trace shows me that it returns The updated implementation should now detect the When you have the time, give |
|
No need to apologize!! |
|
Hey @exhuma this is what I'm getting now; Also while trying with a juniper EX4300-24T (regular snmpwalk works) But now i'm seeing this; The next mib should be |
|
Huh... that is interesting. And it's hard to tell just from the tracebacks, without seeing the exchanged packets. Could you maybe run both requests using |
|
Here's the |
|
|
|
I'm.... stumped... The debug logs above show that the device returns the "out of time window" error directly as a response to the discovery message. Which, by definition cannot be "in the time window" because the discovery is used to establish the time-synchronisation. I will try a simpler solution as last time and simply disable the error handling during the discovery process. This is a fiddly issue and I am taking my time to get it right (at least as right as I can 😉 ) |
|
No worries at all. My interim solution is using the |
|
I just tried v3 with puresnmp for the first time and ran into the same issue. @exhuma let me know if there's anything I can do to help you reproduce or test this. It works fine with pysnmp and command-line net-snmp. |
|
Same issue for me with "Error response from remote device: Not in time window" (Same NTP server). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Description
When doing SNMPv3 to as specific Networking Vendor, it will throw an exception
puresnmp.exc.SnmpError: Error response from remote device: Not in time windowI have configured SNMPv3 with authPriv on the device, and using normal linux
snmpwalkor even another package ofeasysnmp2it works just fine hitting this specific device.Doing some debugging on some of the source code https://github.com/exhuma/puresnmp/blob/develop/puresnmp_plugins/security/usm.py
I was able to pull the following, when executing my code when it attempts to validate_usm_message it never comes as an encrypted message.
HexDump
If the issue you are reporting relates to data conversion, or other related
issues about the data transferred over the wire, please include a hexdump of
the data in your bug report.
Otherwise leave this section empty.
The easiest way to do this is to enable debug logging:
Code:
Exception:
SNMPWALK:
As you can see from the above it shows a
PlainMessage()coming in. When it test this towards another vendor such as Cisco or Juniper, it'll show an Encrypted message instead.Are there any other debugging steps i could attempt?
This will display the raw bytes which help a lot in debugging the issue.
The text was updated successfully, but these errors were encountered: