Is there a way to get metric information using MIB instead of OID to external snmp agent that already exists?

[bkkoli]

Looking at the README.md file, it looks like you can only get metric information through OID. If only the MIB file for the SNMP Agent that already exists exists, is there a way to query the metric with that MIB?

[Example]

const snmp = require('net-snmp')

const options = {
  port: 161,
  retries: 1,
  timeout: 5000,
  transport: 'udp4',
  trapPort: 162,
  version: snmp.Version3,
  engineID: '8000B98380XXXXXXXXXXXXXXXXXXXXXXXX', // where the X's are random hex digits
  backwardsGetNexts: true,
  reportOidMismatchErrors: false,
  idBitsSize: 32,
  context: '',
}

// Example user
const user = {
  name: 'test',
  level: snmp.SecurityLevel.authPriv,
  authProtocol: snmp.AuthProtocols.sha256,
  authKey: 'auth1234',
  privProtocol: snmp.PrivProtocols.aes,
  privKey: 'priv1234',
}

var session = snmp.createV3Session('127.0.0.1', user, options)

const oids = ['HOST-RESOURCES-MIB::hrFSMountPoint']

session.get(oids, function (error, varbinds) {
  if (error) {
    console.error(error)
  } else {
    for (let i = 0; i < varbinds.length; i++) {
      if (snmp.isVarbindError(varbinds[i])) {
        console.error(snmp.varbindError(varbinds[i]))
      } else {
        console.log(varbinds[i].oid + ' = ' + varbinds[i].value)
      }
    }
  }
  session.close()
})

[markabrahams]

Hi @bkkoli - no this isn't yet supported in the library. This would depend on the translation function requested in #208 - see the discussion there. Once #208 is implemented, this will be trivial to implement.

[markabrahams]

Hi @bkkoli - I've just implemented #208, and so translating between numeric and named OIDs is now possible.

Documentation is here: https://github.com/markabrahams/node-net-snmp?tab=readme-ov-file#storetranslate-oid-destinationformat

[christopher-nielsen-ny]

Hi @bkkoli - I've just implemented #208, and so translating between numeric and named OIDs is now possible.

Documentation is here: https://github.com/markabrahams/node-net-snmp?tab=readme-ov-file#storetranslate-oid-destinationformat

Mark, this is great functionality, and we're presently migrating our code to use it. Thank you so much!

So far, we did encounter one minor snag, with the Job-Monitoring-MIB: When translating Job-Monitoring-MIB::jmJobTable, the result is 1.3.6.1.4.1.jobmonMIB(1).1.3.1. (Perhaps due to the way the table is indexed?) And since that's not considered a valid OID [to other net-snmp calls], it results in failure.

Is there a second/subsequent level of resolution that needs to occur within the translate call? Or...?

[christopher-nielsen-ny]

So far, we did encounter one minor snag, with the Job-Monitoring-MIB: When translating Job-Monitoring-MIB::jmJobTable, the result is 1.3.6.1.4.1.jobmonMIB(1).1.3.1. (Perhaps due to the way the table is indexed?) And since that's not considered a valid OID [to other net-snmp calls], it results in failure.

Similarly, attempting to translate the numeric OID to the friendly name, results in Error: No translation found.

EDIT: Here I'm referring to the real numeric OID (1.3.6.1.4.1.2699.1.1.1.3.1), which fails to translate.

[markabrahams]

Hi @christopher-nielsen-ny - thanks for the feedback!

I do get slightly different albeit incorrect results for your problem case.

Calling: store.translate('Job-Monitoring-MIB::jmJobTable', snmp.OidFormat.oid) gives me: 1.3.6.1.4.1.1.1.3.1

Despite the differences in your results and mine, I can see that there is a problem being caused because of this OBJECT IDENTIFIER value assignment in the Job Monitoring MIB file:

jobmonMIB MODULE-IDENTITY
<...snip...>
    ::= { enterprises pwg(2699)  mibs(1)  1 }

I have never come across before - and the code doesn't cater for - an OBJECT IDENTIFIER value assignment that is not of the form: ::= { parentName childNumber } e.g. { enterprises 2699 }

However, on scouring RFC2578 section 3.6 it looks like a chain of intermediate name/number pairs between the parent name and the leaf child number - like we have in the jobmonMIB case - is also a valid OBJECT IDENTIFIER value.

So the short of it is that the MIB parsing code will need to be changed to cater for intermediate name/number pairs in OBJECT IDENTIFIER value assignments. It's not the OID name/number translating code that's the problem, as the MIB parser has already parsed the OID value incorrectly in the first place.

(You might have noticed the incorrect OID in the jobmonMIB entry in the parsed MIB module - it shows as 1.3.6.1.4.1.1 instead of 1.3.6.1.4.1.2699.1.1. Similarly the NameSpace is incorrect - showing as iso.org.dod.internet.private.enterprises.jobmonMIB instead of iso.org.dod.internet.private.enterprises.pwg.mibs.jobmonMIB.)

[markabrahams]

@christopher-nielsen-ny - I've just pushed a fix for the MIB parser to handle OID value lists of length greater then two, and published this in version 3.10.2 of the npm.

I did get different errant results than you did, but this fixed the problem I had, so hopefully it will fix your problem as well! :-)

[christopher-nielsen-ny]

@christopher-nielsen-ny - I've just pushed a fix for the MIB parser to handle OID value lists of length greater then two, and published this in version 3.10.2 of the npm.

I did get different errant results than you did, but this fixed the problem I had, so hopefully it will fix your problem as well! :-)

Well, it fixes the problem if the module identity matches with your test case:

 ::= { enterprises pwg(2699)  mibs(1)  1 }

However, the official MIB - sourced from datatracker.ietf.org - has a module identity of the following:

 ::= { enterprises pwg(2699)  mibs(1)  jobmonMIB(1) }

And the latter still fails.

(To be fair, it appears that the Job-Monitoring-MIB available from mibbrowser.online, isn't a 100% match with the official version. Though based on a quick diff, the module identity line is the only meaningful difference.)

[markabrahams]

That fully explains the difference in the results that I was getting and those you were getting @christopher-nielsen-ny!

I took a copy of the MIB from the download link you provided in the description of the problem at mibbrowser.online, which contained: ::= { enterprises pwg(2699) mibs(1) 1 }

Your test came from the RFC2707 version of the MIB at datatracker.ietf.org, which contained: ::= { enterprises pwg(2699) mibs(1) jobmonMIB(1) }

This is another first that I've seen - to have the last component of the OBJECT IDENTIFIER value list contain a name/number pair instead of just a number. Which raises the question, what should a parser do with this last name, and specifically if it does not equal the LHS of the assignment, which it appears to duplicate? For mind, this name in the final OBJECT IDENTIFIER component is at best a duplication of information if they match, and at worst conflicting information if they don't.

Possibly for this very reason, the person who edited the "mibbrowser.online" version elected to remove the jobmonMIB name from the last component of the OBJECT IDENTIFIER value assigned.

I've taken a leaf out of that book with the parser change, and so the fix here is to simply ignore any name attached to the final component of an OBJECT IDENTIFIER value assignment, preferring instead the LHS name for this.

I've pushed this fix and published in version 3.10.3 of the npm.

[markabrahams]

A further note here is that neither SMIv1 (RFC1155) or SMIv2 (RFC2578) are incredibly prescriptive on the format of valid OBJECT IDENTIFIER values, so presumably one would defer to the original ASN.1 (X.680) standard, which seems to allow what is calls a "NameAndNumberForm" component as the final component in the OBJECT IDENITIFIER value list (ITU-T Rec. X.680 (07/2002) section 31).

[christopher-nielsen-ny]

That fully explains the difference in the results that I was getting and those you were getting @christopher-nielsen-ny!

[...]

I've taken a leaf out of that book with the parser change, and so the fix here is to simply ignore any name attached to the final component of an OBJECT IDENTIFIER value assignment, preferring instead the LHS name for this.

I've pushed this fix and published in version 3.10.3 of the npm.

Beautiful, your latest fix resolves the issue. Thank you again Mark!