[solved] SNMP(v3) not working for one host (Infortrend)

CMK version: 2.3.0p47 and 2.4.0p30
OS version: Ubuntu LTS 24.04

Error message: SNMP query timed out

Output of “cmk --debug -vvn hostname”: (we get the following for every host with SNMP, but only one is not working)

OMD[test]:~$ cmk --debug -vvn Infortrend
Trying to acquire lock on /omd/sites/test/var/check_mk/crashes/base/4b55fdb6-6499-11f1-9657-005056ae87ad/crash.info
Got lock on /omd/sites/test/var/check_mk/crashes/base/4b55fdb6-6499-11f1-9657-005056ae87ad/crash.info
Releasing lock on /omd/sites/test/var/check_mk/crashes/base/4b55fdb6-6499-11f1-9657-005056ae87ad/crash.info
Released lock on /omd/sites/test/var/check_mk/crashes/base/4b55fdb6-6499-11f1-9657-005056ae87ad/crash.info
Traceback (most recent call last):
File “/omd/sites/test/bin/cmk”, line 135, in
errors = config.load_all_plugins(
^^^^^^^^^^^^^^^^^^^^^^^^
File “/omd/sites/test/lib/python3/cmk/base/config.py”, line 1451, in load_all_plugins
errors = agent_based_register.load_all_plugins(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/omd/sites/test/lib/python3.12/contextlib.py”, line 81, in inner
return func(*args, **kwds)
^^^^^^^^^^^^^^^^^^^
File “/omd/sites/test/lib/python3/cmk/base/api/agent_based/register/_discover.py”, line 76, in load_all_plugins
_register_plugin_by_type(location, plugin, validate=raise_errors)
File “/omd/sites/test/lib/python3/cmk/base/api/agent_based/register/_discover.py”, line 112, in _register_plugin_by_type
register_snmp_section(plugin, location, validate=validate)
File “/omd/sites/test/lib/python3/cmk/base/api/agent_based/register/_discover.py”, line 146, in register_snmp_section
section_plugin = create_snmp_section_plugin(section, location, validate=validate)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/omd/sites/test/lib/python3/cmk/base/api/agent_based/register/section_plugins.py”, line 289, in create_snmp_section_plugin
_validate_detect_spec(snmp_section_spec.detect)
File “/omd/sites/test/lib/python3/cmk/base/api/agent_based/register/section_plugins.py”, line 165, in _validate_detect_spec
raise ValueError(
ValueError: OID in value of ‘detect’ keyword must start with ‘.’: ‘1.3.6.1.2.1.1.1.0’

The problem has been discovered when updating our test checkmk system from 2.3.0p47 to 2.4.0p30. Then discovered the problem also exists in productive system (still 2.3.0p47). Existing checks seem to work but I am not really sure they do.

The system that does not work is an Infortrend system. We are using the Infortrend plugin from checkmk exchange. I a pretty sure, that the plugin itself is not the problem and it does not matter if version 5.0.1 or 6.0.1 of the plugin is used.

Problem is, that a “full rescan” (in the webUI) or “cmk --snmpwalk HOST” is running into a timeout, while a “normal” snmpwalk snmpwalk -v 3 -a sha -x aes -l authPriv -A AuthPW -X PrivPW -u checkmk 172.16.x.x .1

does work. Output (first 20 lines)
iso.3.6.1.2.1.1.1.0 = STRING: “Infortrend SNMP agent”
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.1714.1.1
iso.3.6.1.2.1.1.3.0 = Timeticks: (1864812300) 215 days, 20:02:03.00
iso.3.6.1.2.1.1.4.0 = STRING: “Administrator”
iso.3.6.1.2.1.1.5.0 = STRING: “Infortrend”
iso.3.6.1.2.1.1.6.0 = STRING: “Office”
iso.3.6.1.2.1.1.7.0 = INTEGER: 72
iso.3.6.1.4.1.1714.1.1.1.1.1.0 = STRING: “Intel CPU”
iso.3.6.1.4.1.1714.1.1.1.1.2.0 = INTEGER: 2
iso.3.6.1.4.1.1714.1.1.1.1.3.0 = INTEGER: 5
iso.3.6.1.4.1.1714.1.1.1.1.4.0 = INTEGER: 1
iso.3.6.1.4.1.1714.1.1.1.1.5.0 = INTEGER: 68
iso.3.6.1.4.1.1714.1.1.1.1.6.0 = INTEGER: 4
iso.3.6.1.4.1.1714.1.1.1.1.7.0 = INTEGER: 1
iso.3.6.1.4.1.1714.1.1.1.1.8.0 = INTEGER: 11
iso.3.6.1.4.1.1714.1.1.1.1.9.0 = INTEGER: 12
iso.3.6.1.4.1.1714.1.1.1.1.10.0 = INTEGER: 9317755
iso.3.6.1.4.1.1714.1.1.1.1.11.0 = STRING: “Infortrend”
iso.3.6.1.4.1.1714.1.1.1.1.12.0 = INTEGER: 267013

The normal snmpwalk does work from every system i tested (as long as credentials are correct). “cmk --snmpwalk” does not work from productive and test checkmk system.
Both credentials (auth and priv) are below 20 chars. They do not contain any special characters. I re-entered the credentials in host settings (copy from PW safe) multiple times. Other systems that use snmpv3 can be queried with “cmk --snmpwalk” and do work with a full rescan in the UI.

In the productive checkmk the host does have multiple checks that were discovered when we integrated the infortrend system in our network. We thought those checks were working, but i am not really sure. The “check_mk” check always has an execution time of 0.0. If we do a “full rescan” on this host, there is a snmp timeout like in test system. (Screenshot of services attached)

Any ideas or hints what we can do or check to get the cause of this issue?

With a lot of trial and error we found something.

The Infortrend system does not like snmpbulkwalks AND the inline snmp of checkmk.

We set rules for both (disable snmpbulkwalk and use classic backend) and the snmp from checkmk is working. Now we see that there maybe is an error in the infortrend extension. But the problem as described is solved, so i will mark it as such.