How to convert a snmp-returned mac address?

Hi,
I am using an snmp node to query a network device. One node returns a value that shows in a debug node as 'OctetString'.
Is there a node object I can use to convert this to an ascii string?

Thanks

You haven't supplied any flow example of what you are doing, so just a guess here... but have you tried searching for "OctetString" in the forum? I did and see a possible solution, or part of one at least.

Im using node-red-snmp-node to connect to a router and query an OID which returns a NIC MAC address in a format of OctetString. My shell script that converts it to ascii needs its node-red counterpart. I looked at node-red-contrib-buffer-parser but I have not been able to decipher all of the options to get what I am looking for.

As it is, the OcteltString that is returned is undeciperable in a debug node. How to progress?

If you have a script that does what you need and if it is in javascript, or you can Google for something like it, perhaps put it in a function node.

Post up the outputof a debug node from the returned string - and also the real mac address in standard notation so we can see what is happening

  • MAC Adresses are decoded with .toString('hex')

Craig

Here is the output from the debug node:
[{"oid":"1.3.6.1.4.1.41112.1.4.5.1.4.1","type":4,"value":"hך�K�","tstr":"OctetString"}]

Properly formatted by an snmp client program, it is:
Name/OID: ubntWlStatApMac.1; Value (OctetString): 68-D7-9A-8D-4B-96

Would I use the .toString('hex') in a function node?

Hi yes - something basic like (assuming you only have one value returned)

msg.payload[0].value = msg.payload[0].value.toString("hex");


It certainly brings back what appears to be a strange value which matches that in the object, but .toString('hex') does not appear to convert anything.

sorry can you cut/paste the actual value of the whole payload object here as a code block (using the </> button above - hover over the right hand end of the payload line
image

I'm running on the same issue while querying network devices.
A copy of the value shows exactly the same information zubenubi posted on image, a value string with strange characters:

[{"oid":"1.3.6.1.4.1.2011.6.128.1.1.2.43.1.3.4194324224.1","type":4,"value":"HWTC��T�","tstr":"OctetString"}]

If I do a query using a snmpwalk from the linux console, I'm getting a readable "Hex-STRING":

iso.3.6.1.4.1.2011.6.128.1.1.2.43.1.3.4194324224.1 = Hex-STRING: 48 57 54 43 AD A1 54 9A

If I convert the string to a buffer, just some chars at the beginning are ok:

msg.payload=Buffer.from(msg.payload[0].value);
[72,87,84,67,239,191,189,239,191,189,84,239,191,189]

The very first bytes are ok (if converted to HEX), but not the last ones, and has more bytes (14) than expected (8).

Here is the debug output:

[{"oid":"1.3.6.1.4.1.41112.1.4.5.1.4.1","type":4,"value":"hך�K�","tstr":"OctetString"}]

I think it's a bug at the snmp get node, giving the response value as "OctetString" while (snmpwalk reports a Hex-String).
Looking into the value length, says that is 8, which is ok.
But looking into the char value for each character, looks like high values (above 128) are reported as 253 (xFD) and the real value has been lost:

msg.payload[0].value.toString("hex") =

[72,87,84,67,253,253,84,253]

Values reported as 253 (xFD) should be xAD, xA1 and x9A respectively. All the others are OK.

Hoping that the community can help to identify the difference between the 2 nodes. snmp node going after the specific oid returns:

[{"oid":"1.3.6.1.4.1.41112.1.4.5.1.2.1","type":4,"value":"NCB","tstr":"OctetString"}]

When I use the snmp-table node: this is what is returned:

{"1":{"1":5,"2":[78,67,66],"3":2,"4":[106,215,154,141,75,150],"5":-53,"6":43,"7":98,"8":-90,"9":58500000,"10":65000000,"11":[110,111,110,101],"12":2,"13":2,"14":20,"15":1}}

In the latter case, the SSID oid is not converted to ascii, which I can actually understand.

Is this an issue for node-red-snmp-node devs?

TIA

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