Anders Broman wrote:
Hi, I have experemented with building libsmi.dll from libsmi SVN _http://www.ibr.cs.tu-bs.de/svn/libsmi_ with the included makefile-dll and smi.def file
It builds under MSVC6 I have not tested it but if some one likes to play with it - here it is... If you find any errors please let me know.
I've managed to get your makefile to work with MSVC8. My version attached. A few more -Dxxx make the compiler and linker happy.
Adding smiFree to smi.h and EXPORTing it from the DLL lets the memory that is currently being leaked be freed. Juergen agrees this is OK. If have added these to smi.h and EXPORTed them:
extern void *smiMalloc(size_t size); extern void *smiRealloc(void *ptr, size_t size); extern char *smiStrdup(const char *s1); extern char *smiStrndup(const char *s1, size_t n); extern void smiFree(void *ptr);
I think I have also tracked down one of the reasons wireshark crashes. Take this snippet:
ICS3-MIB DEFINITIONS ::= BEGIN
IMPORTS OBJECT-TYPE FROM RFC-1212 TRAP-TYPE FROM RFC-1215 westellInterchangeProducts FROM WESTELL-GENERAL-MIB;
ics3 OBJECT IDENTIFIER ::= { westellInterchangeProducts 2 2 }
smilint gives this warning.
./ICS3-MIB:16: warning: implicit node definition
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. Adding:
if (kind == OID_KIND_UNKNOWN) continue;
(you will have to separate the declarations and initialisations of oid and oid_data) before that call stops the crash.
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.
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.
/js
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.
On Thu, Apr 17, 2008 at 01:06:54AM +1000, Andrew Hood wrote:
Other than implicit nodes is there any any other way to get a node with no name?
This is the only case I can think of right now.
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.
Yesterday's patch did return a numeric OID in these cases. Today's patch does what you suggested (r8071).
/js
On Wed, Apr 16, 2008 at 09:22:38AM +1000, Andrew Hood wrote:
Adding smiFree to smi.h and EXPORTing it from the DLL lets the memory that is currently being leaked be freed. Juergen agrees this is OK. If have added these to smi.h and EXPORTed them:
extern void *smiMalloc(size_t size); extern void *smiRealloc(void *ptr, size_t size); extern char *smiStrdup(const char *s1); extern char *smiStrndup(const char *s1, size_t n); extern void smiFree(void *ptr);
These functions are now exported (r8062) in smi.h.
/js
participants (2)
-
Andrew Hood -
Juergen Schoenwaelder