Juergen Schoenwaelder wrote:
On Wed, Apr 16, 2008 at 09:22:38AM +1000, Andrew Hood wrote:
I think I have also tracked down one of the reasons wireshark crashes.
[...]
At line 595 oids.c calls smiRenderOID to format the node. The implicit node is not completely filled in, and wireshark/tshark crashes in libsmi. This is not totally unreasonable since implicit nodes should never be seen.
A crash _inside_ libsmi is not really acceptable; smiRenderOID should return NULL if it can't do what the caller wants. So I created a sample MIB and a little program to test this (see attachment) and I found where things go wrong.
I wasn't meaning to suggest it was acceptable, just that the way wireshark was using it was unexpected.
Attached is a patch which causes smiRenderOID() to render the OID as a sequence of numbers in case it is called with SMI_RENDER_NAME or SMI_RENDER_QUALIFIED and the label of the node is not known. But this might not be the right thing to do; it might be better to fail by returning NULL so that the caller gets control of what should happen. On the other hand, we always append numeric OIDs.
I guessed you'd figure it out faster than I would. In addition to OID_KIND_UNKNOWN I found cases with OID_KIND_NODE having NULL name pointers.
Other than implicit nodes is there any any other way to get a node with no name? Should we be going on a pointer hunt to ensure they are all initialised to NULL and then test them to be non-NULL before use.
I gather that you are suggesting smiRenderOID() make the implicit name that of the nearest parent concatenated with "." and the numeric value? So in your example:
FOO-MIB DEFINITIONS ::= BEGIN IMPORTS mib-2 FROM SNMPv2-SMI; foo OBJECT IDENTIFIER ::= { mib-2 88 1 } END
it would return "mib-2.88" which would be perfectly acceptable.