Skip to main content

Spec Clarification - Diagnostics API

6 replies [Last post]
ramks
Offline
Joined: 2010-06-17

Spec is not clear how the MIBListener would handle the SNMPResponse when it comes to table OIDs.

Can somebody provide the sequence with an app querying for queryMIBs and how it gets the MIBDefinition[]?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ramks
Offline
Joined: 2010-06-17

Another doubt
Why should registerOID take leaf as boolean? Should it matter if OID is leaf or not? Can't we know if OID has .0 it is leaf?

sarendt
Offline
Joined: 2009-07-21

Again, these are my assumptions on how it works -- I haven't actually implemented this, so I'm thinking this through on the fly.

1) Since a var bind list can contain any OIDs, I assume that each MIB in the var bind list is routed independently to the appropriate MIBListener. Then, the responses from the MIBListeners would be aggregated into a full SNMP response packet to be sent back to the SNMP manager that sent the request.

2) I suppose that the community name would be checked by the MIBManager before the requests are routed to MIBListeners.

3) Hmmmm...I can't think of why we should need to specify the leaf boolean rather than parsing out the ".0".

ramks
Offline
Joined: 2010-06-17

2. How this can be done? None of the diagnostics APIs have community names in them.

Another doubt
Why would they have SNMPRequest.SNMP_CHECK_FOR_SET_REQUEST? SNMPResponse has enough status values to convey any error.

sarendt
Offline
Joined: 2009-07-21

I assume that the community name would be checked after the SNMP packet is received, but before the notifySNMPRequest is called on the MIBListener. Then the APIs don't need to expose the community name.

I don't know what purpose SNMP_CHECK_FOR_SET_REQUEST serves, given that, as you say, error codes are available for all possible errors.

sarendt
Offline
Joined: 2009-07-21

I assume you are asking about how the potentially-unknown table indices are handled. I don't have an example to provide, but following the usual SNMP flow, here is how I assume it works:

The SNMPRequest var passed into the notifySNMPRequest has a request type for a get or get-next. So, if an SNMP Manager makes a get call for a table entry with a known table index, then it sends a get-request with the exact OID for the table entry The request is routed to the appropriate MIBListener, and the passed-in SNMPRequest has type SNMP_GET_REQUEST. The MIBListener responds with the SNMPResponse for that OID. That's the easy case.

On the other hand, if the SNMP Manager does not know the table index, it makes a get-next call with an appropriate OID. This OID could be the table colummn OID (in which case the first entry for that column would be returned), or it could be the OID for a known entry in the column (in which case the next entry after that one would be returned). The request is routed to the appropriate MIBListener, and the passed-in SNMPRequest has type SNMP_GET_NEXT_REQUEST. The MIBListener responds by looking at the OID in the request, and replying with the SNMPResponse pertaining to the next OID (in lexigraphical order) it has. If there is no next OID, then the SNMPResponse would contain a status value of SNMP_REQUEST_NO_SUCH_NAME. In that case, the get-next request would be re-routed to the next (in lexigraphical OID order) MIBListener. If there is no next MIBListener, then the SNMPResponse containing the SNMP_REQUEST_NO_SUCH_NAME status would be returned to the SNMP Manager that originated the request.

Is that what you had in mind?

ramks
Offline
Joined: 2010-06-17

Thanks for the reply. The doubt is cleared.

Another doubt.
Get request might have variable bindings but the listener API has only provision for 1 OID.

Another doubt.
How is the community name check covered?
The set API doesn't have any access parameter.