Skip to content

Fixed bulk SNMP operations by making the protocol version configurable - #2160

Open
cafe-jun wants to merge 1 commit into
thingsboard:masterfrom
cafe-jun:fix/snmp-version-config
Open

Fixed bulk SNMP operations by making the protocol version configurable#2160
cafe-jun wants to merge 1 commit into
thingsboard:masterfrom
cafe-jun:fix/snmp-version-config

Conversation

@cafe-jun

@cafe-jun cafe-jun commented Aug 23, 2026

Copy link
Copy Markdown

Closes #2150

Problem

SNMPConnector hardcodes credentials.V1, so every request goes out with the SNMP version field set to 0 (SNMPv1):

https://github.com/thingsboard/thingsboard-gateway/blob/master/thingsboard_gateway/connectors/snmp/snmp_connector.py#L171-L173

GETBULK was introduced in SNMPv2c. Carried inside an SNMPv1 message it is discarded by the agent, and the client times out — the TimeoutError reported in #2150.

This is not limited to bulkwalk. Three of the eleven advertised methods are built on GETBULK and are therefore unusable:

  • bulkget
  • bulkwalk
  • bulktable

In puresnmp, V2C subclasses V1 and overrides only mpm (01), which is the version field in the packet. The credential class alone decides whether bulk operations can work.

Reproduction

Against a local snmpsim agent (community public), walking 1.3.6.1.2.1.2.2.1.2 (3 entries):

credentials get bulkwalk
V1 (current) OK Timeout: 3 second timeout exceeded on UDP transport.
V2C OK OK — 3 rows

Change

Adds an optional per-device version key accepting v1 or v2c, defaulting to v2c. SNMPv1-only agents stay reachable by setting it explicitly. An unknown value logs a warning and falls back to the default rather than breaking the poll.

The key is also added to the shipped config/snmp.json example so it is discoverable.

Verification

Exercised through SNMPConnector.__process_methods against the same agent:

device config resolved version method result
no version key v2c bulkwalk OK — 3 rows
"version": "v1" v1 bulkwalk times out (previous behaviour, now opt-in)
"version": "v1" v1 get OK — no regression for v1-only agents
"version": "V2C" v2c bulkwalk OK — case normalised
"version": "v9" falls back bulkwalk OK — warning logged

On the default value

I defaulted to v2c because the connector advertises bulk methods that cannot work under v1, and puresnmp itself emits UserWarning: Experimental SNMPv1 support. This does change behaviour for anyone relying on the implicit v1, so if you would rather keep v1 as the default and have users opt into v2c, say the word and I will flip it — the change is one constant.

Notes

  • No tests added: there is currently no SNMP coverage under tests/. Happy to add unit tests for the version resolution if you want them in this PR.
  • Out of scope, but noticed while working on this: config/snmp.json shows a per-datapoint "community" override, while the connector only reads device["community"]. I left it alone to keep this change focused.
  • v3 is not included since it needs auth/priv parameters and a wider config surface.

@CLAassistant

CLAassistant commented Aug 23, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

The connector hardcoded credentials.V1, so every request was sent as
SNMPv1. GETBULK was introduced in SNMPv2c, so agents discard the PDU and
the client times out. This made bulkget, bulkwalk and bulktable
unusable, even though all three are advertised as supported methods.

Added an optional per-device "version" key accepting "v1" or "v2c",
defaulting to "v2c". SNMPv1-only agents remain reachable by setting it
explicitly. An unknown value logs a warning and falls back to the
default instead of breaking the poll.

Closes thingsboard#2150
@cafe-jun
cafe-jun force-pushed the fix/snmp-version-config branch from 7b1f849 to 1b60f68 Compare August 24, 2026 11:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] SNMP bulkwalk does not work - SNMPv1 does not support bulkwalk

2 participants