Fix SEQUENCE OF in getProvidersForModule

[micke75]

Here is a part of my MIB. It contains an object called tempSensors with is a SEQUENCE OF TempSensorEntry:

TempSensorIndex ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
        "A unique value, greater than zero, for each temp sensor in the managed system."
    SYNTAX Unsigned32

tempSensors OBJECT-TYPE
    SYNTAX  SEQUENCE OF TempSensorEntry
    MAX-ACCESS not-accessible
    STATUS  current
    DESCRIPTION
        "A list of temp sensor entries."
    ::= { tricontrol 3 }

tempSensorEntry OBJECT-TYPE
    SYNTAX  TempSensorEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
        "An entry containing information applicable to a particular temp sensor."
    INDEX { tempSensorId }
    ::= { tempSensors 1 } 

TempSensorEntry ::= SEQUENCE {
    tempSensorId            TempSensorIndex,            
    tempSensorValue         Integer32,
    tempSensorIsEnabled     TruthValue,
    tempSensorIsWorking     TruthValue
}

tempSensorId OBJECT-TYPE
    SYNTAX  TempSensorIndex
    MAX-ACCESS read-only
    STATUS  current
    DESCRIPTION
        "Temp sensor ID."
    ::= { tempSensorEntry 1 }                              

tempSensorValue OBJECT-TYPE
    SYNTAX  Integer32
    MAX-ACCESS read-only
    STATUS  current
    DESCRIPTION
        "Current temperature measured by temp sensor."
    ::= { tempSensorEntry 2 }          

tempSensorIsEnabled OBJECT-TYPE
    SYNTAX  TruthValue
    MAX-ACCESS read-only
    STATUS  current
    DESCRIPTION
        "Indicates if temp sensor is enabled or not."
    ::= { tempSensorEntry 3 }  

tempSensorIsWorking OBJECT-TYPE
    SYNTAX  TruthValue
    MAX-ACCESS read-only
    STATUS  current
    DESCRIPTION
        "Indicates if sensor is working or not."
    ::= { tempSensorEntry 4 }  `

Here is a part of my code:

this.snmp.store.loadFromFile(path.join(__dirname, 'TSAB-TRICONTROL-MIB.my'));
let mib = this.snmp.agent.getMib();
console.log(util.inspect(this.snmp.store.getProvidersForModule("TSAB-TRICONTROL-MIB"), { showHidden: true, depth: null }));
mib.registerProviders(this.snmp.store.getProvidersForModule("TSAB-TRICONTROL-MIB"));
mib.addTableRow ("tempSensors", [1, -100, -100, -100]);

Running it generates the following error:

UnhandledPromiseRejectionWarning: ReferenceError: No MIB provider registered for tempSensors at Mib.getProviderNodeForTable (K:\temp\netsnmp\node-net-snmp\index.js:4033:9) at Mib.addTableRow (K:\temp\netsnmp\node-net-snmp\index.js:4157:22)

The console.log shows:

{ 
    tableName: 'tempSensors',
    type: 2,
    tableColumns: [ 
        { number: 1, name: 'tempSensorId', type: 66, maxAccess: 2 },
        { number: 2, name: 'tempSensorValue', type: 2, maxAccess: 2 },
        { number: 3, name: 'tempSensorIsEnabled', type: 2, maxAccess: 2 },
        { number: 4, name: 'tempSensorIsWorking', type: 2, maxAccess: 2 },
        [length]: 4 
    ],
    tableIndex: [ 
        { columnName: 'tempSensorId' }, 
        [length]: 1
    ],
    maxAccess: 0,
    name: 'tempSensorEntry',                                              
    oid: '1.3.6.1.4.1.22562.2.3.1' 
}

With my changes in index.js the console.log shows as below, running the code above will not generating any error and the addTableRow actually does what its supposed to:

{ 
    name: 'tempSensors',
    type: 2,
    tableColumns: [ 
        { number: 1, name: 'tempSensorId', type: 66, maxAccess: 2 },
        { number: 2, name: 'tempSensorValue', type: 2, maxAccess: 2 },
        { number: 3, name: 'tempSensorIsEnabled', type: 2, maxAccess: 2 },
        { number: 4, name: 'tempSensorIsWorking', type: 2, maxAccess: 2 },
        [length]: 4 
    ],
    tableIndex: [ 
        { columnName: 'tempSensorId' }, 
        [length]: 1
    ],
    maxAccess: 0,
    entryName: 'tempSensorEntry',                                             
    oid: '1.3.6.1.4.1.22562.2.3.1' 
}

[derrell]

@micke75 I think you'll find that the code was working fine, except that instead of giving the table name to addTableRow, you give the entry name, i.e., in your code, you'd say

mib.addTableRow ("tempSensorEntry", [1, -100, -100, -100]);

instead of

mib.addTableRow ("tempSensors", [1, -100, -100, -100]);

I never understood why you use the Entry name and not the Table name, but the change you suggest would be a breaking change for all existing users...

[micke75]

@derrell If we instead say that the MIB would have two tables, both with SYNTAX SEQUENCE OF TempSensorEntry (see below), then how do I use mib.addTableRow to add a row to tempSensorsNew?

tempSensorsOld OBJECT-TYPE
    SYNTAX  SEQUENCE OF TempSensorEntry
    MAX-ACCESS not-accessible
    STATUS  current
    DESCRIPTION
        "List of old tempsensors."
    ::= { tricontrol 3 }

tempSensorsNew OBJECT-TYPE
    SYNTAX  SEQUENCE OF TempSensorEntry
    MAX-ACCESS not-accessible
    STATUS  current
    DESCRIPTION
        "List of new tempsensors"
    ::= { tricontrol 4 }

[derrell]

Valid point. Let's wait for @markabrahams' comments about why it's implemented the way it is.

[markabrahams]

Hi @micke75 - first up, @derrell is correct above: When providers are read in from a MIB using store.getProvidersForModule, the library is designed to register a table provider at the level of the "row-entry" node of the MIB. In your case, this is the "tempSensorEntry" node.

RFC 2578 Section 7.1.12 contains the description of a "conceptual table" and its elements - worth a read for a bit of background on this if you haven't already done so. To summarize that section, a table consists of: (1) an "EntryType" which is a SEQUENCE { <type1>, ... <typeN> } (2) a "table-entry" node with syntax SEQUENCE of <EntryType> (3) a "row-entry" node - a subordinate (immediate child) of the "table-entry" node, with syntax (4) nodes defining each column under the "row-entry" node

When designing, I weighed up whether to register the provider at the "table-entry" node (the "tempSensors" node in your example) or the "row-entry" node (the "tempSensorEntry" node in your example). There were pros and cons of both approaches. On one hand, the name of the "table-entry" node is intuitively where you'd expect a table provider to register. Influencing my decision towards the "row-entry" node was that this is the parent node of the actual rows. RFC 2578 is silent on whether the "table-entry" node can have child nodes other than the "row-entry" node, and it was to cater for this possible scenario I preferred the more specific selection of the "row-entry" node to remove any possible ambiguity. In practice, I have only ever seen the "row-entry" node as ".1" under the "table-entry" node, and have never seen any other siblings of a "row-entry" node. If I'd found some hard evidence to dictate those two conditions as a standard, I would have went the other way on this. Having still not found this evidence, coupled with the fact that a move to the "table-entry" node would be a breaking change, my preference is to keep the design as is, and hence not merge this PR. As I say, the downside of this is that the automatic naming of the providers is a little confusing being "xxxEntry" rather than "xxxTable". I threw out a token gesture to help the situation by adding a "tableName" field in a MIB-generated table provider, so the "table-entry" node name is there available for reference if required by your code as well.

In your scenario above, there's no problem with your tempSensorsOld and tempSensorsNew structure if you fill out the rest of the table requirements. From that list above, you've specified (2), and you've defined (1) in your initial post in this issue, but you need to add (3) and (4) for your tempSensorsOld and tempSensorsNew tables for them to be functional. Having done that, after reading providers from the MIB using store.getProvidersForModule, you can addTableRow using the "row-entry" node name for each (which will be the name assigned automatically to each provider by store.getProvidersForModule).

[micke75]

Hi @markabrahams Thank you for taking the time to write this detailed explanation. Now I understand your design and can rewrite my code so it works without my own changes. Thank you very much!