
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