SNMP Translate?

[mrcarter7]

Sorry if I missed it in the docs - but is there an equivalent to SNMP translate? I want to show a user friendly key for the oids that I'm getting via session.get? is it part of the varbinds object that I missed maybe?

I do see that the mib object has some user friendly options but it also looks like its code-defined based on a new agent object. I'm not creating any new agents I'm just using the library to get oids from existing agents (agentx).

If its not build into the library now is it something worth adding? Or is there universal way to do the translation that maybe I don't know about?

[markabrahams]

Hi @mrcarter7 - there is not currently an API call similar to snmptranslate from the Net-SNMP tools.

The information to implement such a feature is available in the ModuleStore. The parsed modules returned from store.getModuleNames() contain all of the information required to convert from OID to name and vice versa. Although the existing JSON structures could be searched for the information, perhaps adding some additional indexing might help for quick and easy access to the desired mappings.

I'm open to an API proposal or PR for this if you - or anyone else! - would like to suggest new API calls and/or provide an implementation to add this functionality.

Also, if you're able to give your particular use-case for this feature, that would be great, just as an example of how/where it might be used, and the value gained by adding the feature.

[HeyITGuyFixIt]

This is something I would be interested in seeing. I am working on a script that receives SNMP trap messages and sends them to a syslog server. It would be nice to have a simple way to translate the OIDs.

[christopher-nielsen-ny]

I'm open to an API proposal or PR for this if you - or anyone else! - would like to suggest new API calls and/or provide an implementation to add this functionality.

We'd definitely like to see this as well, particularly when querying for data across MIBs. (Per related issue #238.) More details are below, in terms of our use-case.

As for the implementation, we might be able to help with that as well. Though this would be a personal contribution on my part, done outside of work hours. (However, that shouldn't be a barrier; it's simply a matter of carving out the time.)

Also, if you're able to give your particular use-case for this feature, that would be great, just as an example of how/where it might be used, and the value gained by adding the feature.

For our case, we're monitoring printers. The vast majority of the data is table-based (obtained via session.tableColumns), from two key MIBS:

• Printer MIB
• Job Monitoring MIB

Plus some info from the Host Resources MIB.

Code-wise, we're maintaining the relevant OIDs in a JavaScript object, essentially as a set of constant properties. (One property per OID.) We then break that down further, with constant properties defined for the specific columns we're interested in.

It looks something like this:

// ========================================================================
// MIB definitions, to avoid having to define full OIDs everywhere
// ========================================================================

const OidTopLevelMibs = {
    internet: '1.3.6.1',
};

const OidParentMibs = {
    hostResources: OidTopLevelMibs.internet + '.2.1.25',
    print: OidTopLevelMibs.internet + '.2.1.43',
    printWorkingGroup: OidTopLevelMibs.internet + '.4.1.2699',
};

const OidChildMibs = {
    pwgJobMonMibObjects: OidParentMibs.printWorkingGroup + '.1.1.1',
};

// ========================================================================
// Printer tables/columns we're interested in
// ========================================================================

const PrinterDataOids = {

    // NOTE: This is just a small subset of what we use, trimmed down
    //   for illustration purposes.

    jmGeneralTable: {
        oid: OidChildMibs.pwgJobMonMibObjects + '.1.1',
        columns: {
            jmGeneralNumberOfActiveJobs: 2,
            jmGeneralOldesActiveJobIndex: 3,
            jmGeneralNewestActiveJobIndex: 4,
        },
    },

    jmJobTable: {
        oid: OidChildMibs.pwgJobMonMibObjects + '.3.1',
        columns: {
            jmJobState: 2,
            jmJobStateReasons1: 3,
        },
    },
};

But we'd much prefer to query tables/values via their identifier names, such as Job-Monitoring-MIB:jmJobTable. Similarly, it would be great to be able to access table columns by their name, such as jmJobState.

We can provide more info if needed, but that's the basic idea. Let me know if that makes sense.

[markabrahams]

Thanks for providing your use case @christopher-nielsen-ny!

I've implemented an OID translation function now. Documentation is here: https://github.com/markabrahams/node-net-snmp?tab=readme-ov-file#storetranslate-oid-destinationformat

Translates OIDs between three formats:

• OidFormat.oid - canonical (numerical) OID format e.g. 1.3.6.1.2.1.1.1
• OidFormat.path - named OID path format e.g. iso.org.dod.internet.mgmt.mib-2.system.sysDescr
• OidFormat.module - module-qualified format e.g. SNMPv2-MIB::sysDescr

Use like this:

const moduleQualifiedName = store.translate ('1.3.6.1.2.1.1.1', snmp.OidFormat.module);

This is published in version 3.10.0 of the npm.