smiGetNode and instance identifiers
Next problem:
The description of 'smiGetNode()' states
" The smiGetNode() function retrieves a struct SmiNode that represents a node of any kind. Node may be either a fully qualified descriptor, a simple node name, or a numerical OID. Nodes are also found, if node contains an instance identifier suffix. "
If I retrieve a node using a description that includes such a suffix, is there any way to determine what that suffix is?
Bearing in mind that it may not necessarily be a single subidentifier, and that some of the numbers in the string might actually be included within the node's OID.
I'm looking for an approach that can take a string such as "TCP-MIB::tcpConnTable.1.1.0.0.0.0.21.0.0.0.0.0" and return either "0.0.0.0.21.0.0.0.0.0" (or a parsed equivalent {0,0,0,0,21,0,0,0,0,0}) - without needing to duplicate much of the internal processing of the SMI library.
Any ideas?
Dave
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi!
Dave> The description of 'smiGetNode()' states
Dave> " The smiGetNode() function retrieves a struct SmiNode that Dave> represents a node of any kind. Node may be either a fully Dave> qualified descriptor, a simple node name, or a numerical OID. Dave> Nodes are also found, if node contains an instance identifier suffix. "
Dave> If I retrieve a node using a description that includes such a suffix, Dave> is there any way to determine what that suffix is?
Dave> Bearing in mind that it may not necessarily be a single subidentifier, Dave> and that some of the numbers in the string might actually be included Dave> within the node's OID.
Dave> I'm looking for an approach that can take a string such as Dave> "TCP-MIB::tcpConnTable.1.1.0.0.0.0.21.0.0.0.0.0" Dave> and return either "0.0.0.0.21.0.0.0.0.0" (or a parsed equivalent Dave> {0,0,0,0,21,0,0,0,0,0}) - without needing to duplicate much of the Dave> internal processing of the SMI library.
Dave> Any ideas?
Good point. Currently, there is no libsmi function that allows you to retrieve the instance part of a given OID or string. Generally speaking, there are no functions that handle real data. Another example I could imagine is the formatting of a value according to an object's/type's display hint.
Let me think about an API extension...
-frank -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Frank Strauss writes:
[...]
Dave> Any ideas?
Frank> Good point. Currently, there is no libsmi function that allows Frank> you to retrieve the instance part of a given OID or Frank> string. Generally speaking, there are no functions that handle Frank> real data. Another example I could imagine is the formatting of Frank> a value according to an object's/type's display hint.
Frank> Let me think about an API extension...
The question is whether libsmi should go into the direction of providing a library of utility functions that are commonly needed by applications that use libsmi. You will soon hit a point where you need things like dynamic strings and so on that are realized pretty different in various applications (Tcl_DString (Tcl), GString (glib), tbd (netsnmp), ...) and so on. On the other hand, we already have a bunch of those utility functions in the libsmi tools and some applications that use it - so there seems to be a need.
I think it all boils down to: Who is going to work out the API and implement, document and test this stuff? Volunteers?
/js
Frank> Good point. Currently, there is no libsmi function that allows Frank> you to retrieve the instance part of a given OID or Frank> string.
Juergen> The question is whether libsmi should go into the direction of Juergen> providing a library of utility functions that are commonly needed by Juergen> applications that use libsmi.
Well, in this case the lack of such a function is pretty fundamental. I need to be able to split a full OID into "object" and "instance" parts (which I don't think is an unreasonable thing to want to do :-) )
At the moment, I can use libSMI to parse an object string "TCP-MIB::tcpConnTable.1.1.0.0.0.0.21.0.0.0.0.0"
and be told "Here's the node that you asked about (tcpConnState). Oh - and there was some junk on the end, but you probably don't want to know about that."
But I *dooooo* !
I can't simply extract the last numeric subidentifier from the string manually, since the instance part is longer than that. I can't search for the first numeric subidentifier either, since the first two such subidentifiers are actually included within the node that smiGetNode() has returned.
I've either got to duplicate the OID parsing within my application (which rather defeats the point of using the library in the first place).
Or else I've got to work through successive substrings (either building up from "TCP-MIB::tcpConnTable" or knocking elements off the original string) until I find the point at which libSMI starts giving me a different result. That would tell me where the object/instance divide comes - but feels a somewhat cumbersome approach.
Frank already knows this information anyway - why won't he tell me. S'not fair!
Frank> Another example I could imagine is the formatting of Frank> a value according to an object's/type's display hint.
I think that's a slightly different situation. Yet it would be useful to have this handled within the library - but as long as the library provides the raw material (the basic value, and the hint string), I can at least do this myself.
The object/instance division is different - the basic information just isn't available in the first place.
Juergem> I think it all boils down to: Who is going to work out the API and Juergen> implement, document and test this stuff? Volunteers?
Well, I need this functionality pretty badly - without it, I can't see how we can sensibly adopt libSMI for the net-snmp suite. So I'm quite happy to do much of the donkey work. But I'm coming new to this package, so I'm not really au fait with the general design philosophy here. It's probably not sensible for me to suggest an appropriate API in keeping with the rest of the library. (And of course, the rest of you will be more familiar with the code than I am - so I'm probably not the best choice of coder either. But I'm quite happy to do this, if I'm given a basic design to work from).
Dave
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Dave Shield writes:
Dave> Well, in this case the lack of such a function is pretty Dave> fundamental. I need to be able to split a full OID into Dave> "object" and "instance" parts (which I don't think is an Dave> unreasonable thing to want to do :-) )
Dave> At the moment, I can use libSMI to parse an object string Dave> "TCP-MIB::tcpConnTable.1.1.0.0.0.0.21.0.0.0.0.0"
Dave> and be told "Here's the node that you asked about Dave> (tcpConnState). Oh - and there was some junk on the end, but Dave> you probably don't want to know about that."
Calling "smiquery node TCP-MIB::tcpConnTable.1.1.0.0.0.0.21.0.0.0.0.0" returns information for tcpConnTable (libsmi version 0.2.14) and not tcpConnState on my machine.
Dave> I've either got to duplicate the OID parsing within my Dave> application (which rather defeats the point of using the library Dave> in the first place).
Dave> Or else I've got to work through successive substrings (either Dave> building up from "TCP-MIB::tcpConnTable" or knocking elements Dave> off the original string) until I find the point at which libSMI Dave> starts giving me a different result. That would tell me where Dave> the object/instance divide comes - but feels a somewhat Dave> cumbersome approach.
Your application accepts a specific set of input formats and you can not necessarily expect that libsmi is prepared to handle exactly the same set of input formats. For example, the Tnm extension for Tcl also accepts strings in the form TCP-MIB::tcpConnTable:1.0x01 which libsmi also does not understand. So Tnm has to parse the string itself in order to do handle these things.
Dave> Well, I need this functionality pretty badly - without it, I Dave> can't see how we can sensibly adopt libSMI for the net-snmp Dave> suite.
Since libsmi seems to ignores the stuff after the dot, you should be relatively easily be able to support this format. The correct fix from the libsmi perspective would be to complain about trailing junk or not even accepting anything which has some "typical structure" for the smiGetNode() call and to provide a utility function which parses typical string representations of OIDs (which needs to be defined) and which does the right thing. Right now the code behind smiGetNode() (and smiGetType) is rather simplistic (see getModulenameAndName() in lib/smi.c) and the function signature really expects that you call it with a module name string and a descriptor string. What you want is something like
smiNode* smiFindNode(char *string, SmiSubid oid**, unsigned int oidlen*) smiType* smiFindType(char *string)
which parses the string and returns the node/type plus information about trailing subidentifier in the first case. The input format of smiFindNode() would be (by example):
[<M><S>]<D>[(.<I>)*]
<M> module name <S> :: or . <D> descriptor <I> unsigned number in dec/hex/oct
I am not sure we need more, although some applications accept really interesting things, e.g. TCP-MIB!tcpConnTable:01.tcpConnState.
I am also not sure that smiFindNode() should accept things like TCP-MIB::tcpConnTable.tcpConnEntry.tcpConnState or even just tcpConnTable.tcpConnEntry.tcpConnState or tcpConnState. I guess net-snmp has lots of input formats - I am not sure they need to be supported all by libsmi. (In order to be backwards compatible, you will probably end up having a net-snmp specific smiFindNode() anyway, right? I mean, who is going to parse smScriptOperStatus."foo"."bar"?)
/js
Calling "smiquery node TCP-MIB::tcpConnTable.1.1.0.0.0.0.21.0.0.0.0.0" returns information for tcpConnTable (libsmi version 0.2.14) and not tcpConnState on my machine.
<tap, tap, tap> So it does!
More surprisingly (to me at least), "smiquery node iso.org" returns information about 'iso', not about 'org'.
Hmmm... I've obviously misinterpreted what was meant by "a fully qualified descriptor" in the man page for smiGetNode.
Your application accepts a specific set of input formats and you can not necessarily expect that libsmi is prepared to handle exactly the same set of input formats.
That's fair enough.
Given the tight restrictions on acceptable input for smiGetNode() I'm going to have to do a more processing of the input than I expected anyway - so identifying where the object/subidentifier gap comes won't be as much of a problem as I'd thought.
I quite accept that the specification "TCP-MIB::tcpConnTable.1.1.0.0" or similar is somewhat idiosyncratic - and it's not too surprising if this isn't handled. But I must admit to some surprise (and disappointment) that the library doesn't seem to accept the common "iso.org.dod.internet" style syntax.
I guessnet-snmp has lots of input formats - I am not sure they need to be supported all by libsmi.
No - I quite agree. I just hadn't realised quite how tight the libSMI syntax was.
(In order to be backwards compatible, youwill probably end up having a net-snmp specific smiFindNode() anyway, right?
Probably using net-snmp naming conventions rather than libSMI ones, but yes.
I mean, who is going to parse smScriptOperStatus."foo"."bar"?)
I certainly wouldn't expect the libSMI library to handle all of Wes' wield and wonderful inventions. I just needed to know at what point in the string responsibility was passed over from the libSMI library back to the net-snmp library. Given that I'm going to have to identify the last non-numeric descriptor anyway - that's no longer a problem.
Thanks for the clarifications.
Dave
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
participants (3)
-
Dave Shield -
Frank Strauss -
Juergen Schoenwaelder