[BUG] snmpv3 usmStatsNotInTimeWindows

[mtuska]

EzSNMP release version OR commit number
1.0.0

Operating System and Version

• OS: Ubuntu
• Version 22

Net-SNMP Library Version

• 5.9.1

Describe the bug
When connecting to multiple devices via multithreading, the net-snmp user caching will also cache the engine id, boots, time with the user. Thus as it connects to multiple different devices can cause either blocking or interrupting with error "usmStatsNotInTimeWindows".

To Reproduce
Haven't worked extensively with snmpd so not sure if you could create multiple engines with differing time/boots/engineids.

Expected behavior
Each thread gets it's own caching/memory to avoid clashing.

Additional context
To bypass this issue within python, have switched to using multi-processing in python instead to give each their own space. Not sure how feasible it would be to correct the issue on the same process.

[carlkidcrypto]

RFC3411 section 3.1.1.1 states that the EngineID is unique across entities within an administrative domain. Your devices may be violating this if they're on the same network. It's odd that they both have the same ID, especially if each device uses something internal to auto-generated an ID. Are these the same host? easysnmp/easysnmp#146

[Guens]

It's an old problem already seen with easysnmp : easysnmp/easysnmp#146

@carlkidcrypto you're right, it should not happen to have different devices with the same EngineId. But, we can't avoid that, and when it happens, the library should not fail, isn't it ?

[carlkidcrypto]

yes, @Guens thanks for linking the issue. I was looking at it trying to figure out how to quote it here.
...
I assume by "we can't avoid that" you are referring to the end devices you are polling using EzSNMP correct? If that's the case I'll say this is "correct" behavior based on what I am reading in RFC3411 section 3.1.1.1. This doesn't appear to be an EzSNMP bug because EzSNMP is raising the error it gets from the underlying net-snmp library.

[Guens]

@carlkidcrypto First of all, I want to thank you to take over easysnmp/ezsnmp. It's important for python/snmp community.

You're correct, I reffered to the end devices. We can't always avoid misconfigured devices with the same EngineId.

Whatever RFC compliancy of the devices, I think library results should be consistent.

I mean this code :

s1 = ezsnmp.Session(hostname="10.246.93.192", **snmp_opts)
s2 = ezsnmp.Session(hostname="10.246.93.193", **snmp_opts)

print(f"s2 = {s2.get(oid)}")
print(f"s1 = {s1.get(oid)}")

with this result :

s2 = [<SNMPVariable value='"v+jV (contains binary)' (oid='.1.3.6.1.6.3.10.2.1.1', oid_index='0', snmp_type='OCTETSTR')>]
s1 = [<SNMPVariable value='"v+jV (contains binary)' (oid='.1.3.6.1.6.3.10.2.1.1', oid_index='0', snmp_type='OCTETSTR')>]

should have the same result as this code (s1 & s2 reversed) :

s1 = ezsnmp.Session(hostname="10.246.93.192", **snmp_opts)
s2 = ezsnmp.Session(hostname="10.246.93.193", **snmp_opts)

print(f"s1 = {s1.get(oid)}")
print(f"s2 = {s2.get(oid)}")

s1 = [<SNMPVariable value='"v+jV (contains binary)' (oid='.1.3.6.1.6.3.10.2.1.1', oid_index='0', snmp_type='OCTETSTR')>]
Traceback (most recent call last):
  File "/home/pg218277/.config/JetBrains/PyCharmCE2024.1/scratches/easysnmp_bug_snmpv3.py", line 45, in <module>
    print(f"s2 = {s2.get(oid)}")
  File "/home/pg218277/git/equtils/venv/lib64/python3.9/site-packages/ezsnmp/session.py", line 314, in get
    interface.get(self, varlist)
ezsnmp.exceptions.EzSNMPTimeoutError: timed out while connecting to remote host

[carlkidcrypto]

@Guens and @mtuska take a look at PR #163 . It adds UTs and a test script showing things working.
Of course, I want to see if what's on master works for both of y'all.

[Guens]

@Guens and @mtuska take a look at PR #163 . It adds UTs and a test script showing things working. Of course, I want to see if what's on master works for both of y'all.

Thanks @carlkidcrypto
It would be much easier for me to test it from a pypi release (tag rc4 ?). Is it possible to have such ?

[carlkidcrypto]

@Guens and @mtuska take a look at PR #163 . It adds UTs and a test script showing things working. Of course, I want to see if what's on master works for both of y'all.

Thanks @carlkidcrypto
It would be much easier for me to test it from a pypi release (tag rc4 ?). Is it possible to have such ?

Yes, I was working on that, but my CI for it seems to be broken. I am attempting to fix it. If I can't I'll just release one manually.

[Guens]

@Guens and @mtuska take a look at PR #163 . It adds UTs and a test script showing things working. Of course, I want to see if what's on master works for both of y'all.

Thanks @carlkidcrypto
It would be much easier for me to test it from a pypi release (tag rc4 ?). Is it possible to have such ?

Yes, I was working on that, but my CI for it seems to be broken. I am attempting to fix it. If I can't I'll just release one manually.

Sorry @carlkidcrypto I just tried with the "rc4" and it doesn't change anything. Depending on the order of the "session get", result is not consistent between 2 end devices with the same EngineId.
Nota: PR #163 mentions SNMP v2 tests, although this current issue is SNMP v3 specific (2 devices with the same EngineID)