shashank created CAMEL-25245:
--------------------------------
Summary: camel-snmp - a GET_NEXT walk that reaches the end of the
agent's MIB view never ends, a walk can run into a neighbouring subtree, and a
walk without answer returns an empty list as success
Key: CAMEL-25245
URL: https://issues.apache.org/jira/browse/CAMEL-25245
Project: Camel
Issue Type: Bug
Components: camel-snmp
Reporter: shashank
{{SnmpProducer}} with {{type=GET_NEXT}} walks each OID of the endpoint: it
sends GETNEXT for the OID of the last variable binding as long as that OID *as
a string* starts with the requested OID. Three defects (CAMEL-13936, 2019):
# *End of the MIB view: endless loop.* When the walk reaches the end of what
the agent exposes (a walk of the whole tree, or of the last subtree of a
restricted view: the stock Debian/Ubuntu {{snmpd.conf}} gives the {{public}}
community only the {{systemonly}} view, {{1.3.6.1.2.1.1}} and
{{1.3.6.1.2.1.25.1}}, so a walk of {{1.3.6.1.2.1}} hits it), the agent answers
the last GETNEXT with the requested OID and the value {{endOfMibView}}
(SNMPv2c/v3), or with error status {{noSuchName}} and the requested variable
binding (SNMPv1). That OID still starts with the walked OID, so the producer
requests the same OID again, forever, and adds one message per answer to the
result list: the exchange never completes, the list grows until the JVM runs
out of memory, and the agent is flooded with requests.
# *String prefix.* {{nextOid.startsWith(oid.toDottedString())}} takes
{{1.3.6.1.4.1.2021.1.0}} as part of the subtree of {{1.3.6.1.4.1.2}}, so the
walk continues into the next subtree and returns its entries.
# *Timeout.* When a request gets no answer the walk just stops: an unreachable
agent gives an empty list, and a timeout half way a partial list, both as a
successful result. {{GET}} throws {{TimeoutException("SNMP Producer Timeout")}}
in the same situation.
h3. Reproduction
A test agent (SNMP4J {{CommandResponder}}, v2c) that answers GETNEXT
{{1.3.6.1.4.1.9}} with {{1.3.6.1.4.1.9.1.0 = cisco}} and {{1.3.6.1.4.1.9.1.0}}
with {{endOfMibView}}; {{1.3.6.1.4.1.2}} with {{1.3.6.1.4.1.2.1.0 = ibm}}, then
{{1.3.6.1.4.1.2021.1.0 = ucd}}, then {{1.3.6.1.4.1.3.1.0}}. The agent stops
repeating after 20 identical requests so that the test ends.
* walk of {{1.3.6.1.4.1.9}}: 21 messages (cisco, then {{endOfMibView}} 20
times) instead of 1; without the agent's limit it never ends;
* walk of {{1.3.6.1.4.1.2}}: 2 messages (ibm, ucd) instead of 1;
* walk against a port where no agent listens ({{timeout=200&retries=0}}): an
empty list and no exception.
h3. Proposed fix
In the walk loop: fail with {{TimeoutException}} when there is no response (as
{{GET}} does); end the walk on {{noSuchName}} (net-snmp's {{snmpwalk}} also
reports it as "End of MIB" and fails on other error statuses and on a timeout),
on an exception value ({{endOfMibView}}, {{noSuchObject}}, {{noSuchInstance}}),
on an OID that does not increase, or on an OID outside the subtree
({{OID.startsWith(OID)}}); fail on any other error status. With the fix the new
test ({{WalkOIDEndTest}}, 5 tests: {{endOfMibView}}, SNMPv1 {{noSuchName}},
neighbouring subtree, {{genErr}}, no agent; all five fail on main) and the
camel-snmp suite (20 tests) pass; the existing {{WalkOIDTest}} is unchanged.
Behaviour changes for walks that time out or hit an error, so the upgrade guide
gets a note.
Affected: 4.14.x, 4.18.x and main (same code since 3.0).
Not in scope: the producer is a singleton and the walk mutates the shared
{{pdu}} field, so two concurrent walks on the same endpoint interfere (noted,
not changed).
Duplicate check (2026-10-01): JIRA component camel-snmp (25 issues) and text
"snmp" with "walk"/"GET_NEXT"/"endOfMibView": only CAMEL-13936 and CAMEL-3110
(the features). GitHub pull requests "snmp walk": only #3150 (the feature).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
