SNMP OID Not Valid, but Linux CLI snmpwalk disagrees?

So this OID... is choking up snmp node in node red?

[{"id":"96e7fdd3e7a204dc","type":"snmp","z":"d287cfa5c9da1fdc","host":"","version":"1","timeout":5,"community":"DD","auth":"noAuthNoPriv","authprot":"MD5","privprot":"DES","oids":"1.3.6.1.2.1.4.20.1.1","name":"Address?","x":1140,"y":580,"wires":[["52f9e4bdab151376","5b020eada4bb8f25"]]}]

Where as linux cli snmpwalk...

# snmpwalk -v 1 -cDD hall 1.3.6.1.2.1.4.20.1.1
iso.3.6.1.2.1.4.20.1.1.127.0.0.1 = IpAddress: 127.0.0.1
iso.3.6.1.2.1.4.20.1.1.192.168.1.244 = IpAddress: 192.168.1.244

But via node red snmp node...

"RequestFailedError: NoSuchName: 1.3.6.1.2.1.4.20.1.1"

Other OIDs I have tried seem to work, such as...

1.3.6.1.2.1.1.3.0

Ok? What gives?

Don't know that I've ever had that much joy with that node and many SNMP responses don't always play nicely with JavaScript either due to being very large numbers.

Personally, I'd use Telegraf to translate SNMP to InfluxDB and MQTT as I use it for other monitoring already.

Telegraf Best Practices: SNMP Plugin | InfluxData

Yeah, unfortunately I have some routers that only support SNMP. But I managed to work round the issue. This is not the first time the 'get' snmp node gripped about a completely valid OID.

There is something a bit funky with that set of nodes, or the code below them. The SNMP walk node for example does not behave like the typical snmpwalk linux CLI command does, but the SNMP walk node does what its documentation states if will do, so go figure.

Where the 'get' node failed, the 'subtree' node worked, for this specific OID. I wish the error reporting was was bit better, just throwing back that a given OID is invalid seems like a catch all returned result? But I suspect that is coming from the code below the nodes.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.