How is 1.3.6.1.2.1.1.3... "Error: argument is not a valid OID string"
Jibun-no-Kage opened this issue · 5 comments
How is 1.3.6.1.2.1.1.3... "Error: argument is not a valid OID string" I am using the SNMP (get) node in Node Red, and I get the error? Sorry but it is not making any sense. I enter the OID in the OID box of the node.
for general how-to questions we prefer people to use the only discourse forum as then the question will be seen by the widest possible audience including many who may use the node day to day.
can you show us exactly what you have entered. for example by highlighting the entry in a screenshot of the field. to check there is no whitespace or extra hidden characters.
Not a how to question. The OID is valid, but it is rejected.... but if .0 appended then and only then accepted? That is NOT how the various CLI SNMP tools accept such and OID. So is it a code design issue? Appending .0 should not be required. If the NR node is wrapper, then the wrapped component could be at issue. But if your code is doing something to break a valid OID, that should be discussed here, IMHO.
We are just calling the underlying net-snmp library like
sess.get(oids.split(","), function (error, varbinds) { ...
So we are just splitting a comma separated list into an array of oids to get.
So if that library thinks there is an error then yes - that will need to be raised against that library - but you haven't clarified exactly what oid you are using ? Is 1.3.6.1.2.1.1.3... with trailing ... really valid ?
I don't use SNMP at all, having "inherited" the node from someone else. Hence why you may get better help via the forum.
Digging slightly deeper the error seems to be coming from the ASN1 library they are using where they test the OID with a regex
if (!/^([0-9]+\.){0,}[0-9]+$/.test(s))
throw new Error('argument is not a valid OID string');
which you can test online using something like https://regex101.com
Luckily the ASN1-ber library is by the same author as net-snap - https://github.com/markabrahams/node-asn1-ber so feel free to raise an issue there.
You details are a bit help. The interesting thing is... net-snmp, i.e. snmpwalk does in fact accept the above OID as valid. I have tested it explicitly. For example...
# snmpwalk -v 1 -c DD 192.168.1.252 1.3.6.1.2.1.1.3
iso.3.6.1.2.1.1.3.0 = Timeticks: (404901445) 46 days, 20:43:34.45
Whereas...
# snmpwalk -v 1 -c DD 192.168.1.252 1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks: (404905056) 46 days, 20:44:10.56
So why the net-snmp library fails to accept the first example is a mystery. The value returned is not a tree, or group object returned, as some SNMP get query OIDs return. In fact using the subtree node, the .0 is not required. Per the way I read the SNMP standard, .0 is only required if you want the explicit first element of a dataset returned, say an array of items turned, such as....
# snmpwalk -v 1 -c DD 192.168.1.250 1.3.6.1.2.1.2.2.1.6
iso.3.6.1.2.1.2.2.1.6.1 = ""
iso.3.6.1.2.1.2.2.1.6.2 = Hex-STRING: 00 01 36 1F E4 59
iso.3.6.1.2.1.2.2.1.6.3 = Hex-STRING: 00 01 36 1F E4 5B
iso.3.6.1.2.1.2.2.1.6.4 = Hex-STRING: 00 01 36 1F E4 5F
iso.3.6.1.2.1.2.2.1.6.5 = Hex-STRING: 00 01 36 1F E4 59
iso.3.6.1.2.1.2.2.1.6.6 = Hex-STRING: 00 01 36 1F E4 69
iso.3.6.1.2.1.2.2.1.6.7 = Hex-STRING: 00 01 36 1F E4 59
iso.3.6.1.2.1.2.2.1.6.8 = ""
iso.3.6.1.2.1.2.2.1.6.9 = ""
Or...
# snmpwalk -v 1 -c DD 192.168.1.250 1.3.6.1.2.1.2.2.1.6.0
[No Result]
# snmpwalk -v 1 -c DD 192.168.1.250 1.3.6.1.2.1.2.2.1.6.1
iso.3.6.1.2.1.2.2.1.6.1 = ""
# snmpwalk -v 1 -c DD 192.168.1.250 1.3.6.1.2.1.2.2.1.6.2
iso.3.6.1.2.1.2.2.1.6.2 = Hex-STRING: 00 01 36 1F E4 59
From the CLI of net-snmp, snmpwalk and snmpget are identical for the above results. Really interesting inconsistent handling of OIDs that are not index specific,, i.e. .0,, .1, etc.
Closing since the real issue appears to be with core code, not the NR node wrapper.