libsmi numeric constraints convertion bug
I've run into a possible problem in SVN version of libsmi. I have not done any debugging, so this is just a bug report:
When I do:
smidump -f python TCP-MIB.txt
for the following MIB text:
tcpMaxConn OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The limit on the total number of TCP connections the entity can support. In entities where the maximum number of connections is dynamic, this object should contain the value -1." ::= { tcp 4 }
smidump generates:
"tcpMaxConn" : { "nodetype" : "scalar", "moduleName" : "TCP-MIB", "oid" : "1.3.6.1.2.1.6.4", "status" : "current", "syntax" : { "type" : { "basetype" : "Integer32", "ranges" : [ { "min" : "-1", "max" : "2147483647" }, ], "range" : { "min" : "4294967295", "max" : "2147483647" }, }, }, "access" : "readonly", "description" : """ [skipped] """, }, # scalar
Where range constraints seem to be broken at:
1. Range minimum (0) gets converted into 4294967295. 2. Single value constraint (-1) gets translated into a value range constraint with wildly inflated upper range (2147483647).
Current stable release (0.4.5) behaves differently (yet, incorrectly) in this respect:
"tcpMaxConn" : { "nodetype" : "scalar", "moduleName" : "TCP-MIB", "oid" : "1.3.6.1.2.1.6.4", "status" : "current", "syntax" : { "type" : { "basetype" : "Integer32", "range" : { "min" : "-1", "max" : "2147483647" }, }, }, "access" : "readonly", "description" : """ [skipped] """, }, # scalar
Is there currently a fix for this issue?
Thanks, ilya
On Tue, Jan 29, 2008 at 09:42:15PM +0300, Ilya Etingof wrote:
I've run into a possible problem in SVN version of libsmi. I have not done any debugging, so this is just a bug report:
From what I can tell, the code is simply broken since it assumes that
ranges are unsigned, which is clearly not true. This not only affects the python driver but at least also the perl driver (I think the python driver was modelled after the perl driver). I do not have a quick fix.
/js
On Tue, Jan 29, 2008 at 09:42:15PM +0300, Ilya Etingof wrote:
I've run into a possible problem in SVN version of libsmi. I have not done any debugging, so this is just a bug report:
[...]
Is there currently a fix for this issue?
The attached patch should fix this problem. Since several backends do similar things, we need to factor this out into a reusable function before this can go into SVN...
/js
This patch seems to use a SMI_BASETYPE_POINTER cpp macro, which is not defined or used in SVN sources. Or am I missing something?
Thanks, ilya
On Wed, 30 Jan 2008, Juergen Schoenwaelder wrote:
On Tue, Jan 29, 2008 at 09:42:15PM +0300, Ilya Etingof wrote:
I've run into a possible problem in SVN version of libsmi. I have not done any debugging, so this is just a bug report:
[...]
Is there currently a fix for this issue?
The attached patch should fix this problem. Since several backends do similar things, we need to factor this out into a reusable function before this can go into SVN...
/js
On Mon, Feb 04, 2008 at 12:08:34PM +0300, Ilya Etingof wrote:
This patch seems to use a SMI_BASETYPE_POINTER cpp macro, which is not defined or used in SVN sources. Or am I missing something?
Sorry, some stuff went into the patch that should not have been there... Here is the smaller version of it.
/js
The latest patch sometimes causes segfault. For instance, with ADSL2-LINE-MIB:
Program received signal SIGSEGV, Segmentation fault. 0xb7de0004 in _IO_default_xsputn_internal () from /lib/libc.so.6 (gdb) where #0 0xb7de0004 in _IO_default_xsputn_internal () from /lib/libc.so.6 #1 0xb7dd4499 in _IO_padn_internal () from /lib/libc.so.6 #2 0xb7dbbcf6 in vfprintf () from /lib/libc.so.6 #3 0xb7dd540b in vsprintf () from /lib/libc.so.6 #4 0xb7dc185e in sprintf () from /lib/libc.so.6 #5 0x08066305 in getValueString (valuePtr=0xbfabd4f0, typePtr=0x80d9f58) at dump-python.c:241 #6 0x08066f3c in fprintTypedef (f=0xb7eba4c0, indent=16, smiType=0x80d9f58) at dump-python.c:408 #7 0x080682f6 in dumpPython (modc=1, modv=0x809e060, flags=0, output=0x0) at dump-python.c:808 #8 0x0804a6bd in main (argc=808464416, argv=0xbfabd784) at smidump.c:396 (gdb) frame 5 #5 0x08066305 in getValueString (valuePtr=0xbfabd4f0, typePtr=0x80d9f58) at dump-python.c:241 241 sprintf(s, "0x%*s", 2 * valuePtr->len, ""); (gdb) p *valuePtr $2 = {basetype = 4222451713, len = 134855840, value = { unsigned64 = 579201422609464480, integer64 = 579201422609464480, unsigned32 = 134855840, integer32 = 134855840, float32 = 4.14486655e-34, float64 = 6.0895994962384466e-270, float128 = <invalid float value>, oid = 0x809bca0, ptr = 0x809bca0 "0x", ' ' <repeats 198 times>...}}
Also, smidump reports a handful of:
smidump: unhandled SMI basetype
messages when running against almost any MIB text, not sure how critical it is.
When completing successfully, smidump seems to sometimes produce empty "ranges" (TCP-MIB::tcpConnState).
thanks, ilya
This patch seems to use a SMI_BASETYPE_POINTER cpp macro, which is not defined or used in SVN sources. Or am I missing something?
Sorry, some stuff went into the patch that should not have been there... Here is the smaller version of it.
/js
On Mon, Feb 04, 2008 at 02:00:29PM +0300, Ilya Etingof wrote:
The latest patch sometimes causes segfault. For instance, with ADSL2-LINE-MIB:
Another attempt...
/js
For quite a number of MIBs smidump reports various unhandled SMI basetype's:
$ smidump -k -f python /usr/local/share/mibs/ietf/ACCOUNTING-CONTROL-MIB >/dev/null smidump: module `/usr/local/share/mibs/ietf/ACCOUNTING-CONTROL-MIB' contains errors, expect flawed output smidump: unhandled SMI basetype 3 smidump: unhandled SMI basetype 11 ...
I wonder how critical it is?
Thanks, ilya
This patch works alright so far. Thanks!
-ilya
The latest patch sometimes causes segfault. For instance, with ADSL2-LINE-MIB:
Another attempt...
/js
On Mon, Feb 04, 2008 at 09:35:17PM +0300, Ilya Etingof wrote:
For quite a number of MIBs smidump reports various unhandled SMI basetype's:
[...]
OK, time to try to get it right.
I have factored out some duplicated code by introducing a new API function smiGetMinMaxRange() and I have updated the perl and python drivers to use this function for calculating the overall range. The xsd driver should also call this function but the code is a bit more complex to read/update.
Please check out the head SVN version...
/js
My tests went perfect with current svn code. Thanks!
-ilya
OK, time to try to get it right.
I have factored out some duplicated code by introducing a new API function smiGetMinMaxRange() and I have updated the perl and python drivers to use this function for calculating the overall range. The xsd driver should also call this function but the code is a bit more complex to read/update.
Please check out the head SVN version...
/js
Hello,
Looking at the "smidump -f python" output, I'm not sure how to distinguish IMPLIED INDEX object from just INDEX one. That is, the following SMI code (from SNMP-COMMUNITY-MIB):
snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular community string." INDEX { IMPLIED snmpCommunityIndex } ::= { snmpCommunityTable 1 }
gets converted into
"snmpCommunityEntry" : { "nodetype" : "row", "moduleName" : "SNMP-COMMUNITY-MIB", "oid" : "1.3.6.1.6.3.18.1.1.1", "create" : "true", "status" : "current", "linkage" : [ "snmpCommunityIndex", ], "description" : """Information about a particular community string.""", }, # row
where I see no clear indication of the IMPLIED status of this INDEX. Or is it the "create" flag? Simply INDEX'ed object like (from UPS-MIB):
upsInputEntry OBJECT-TYPE SYNTAX UpsInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular input line." INDEX { upsInputLineIndex } ::= { upsInputTable 1 }
gets converted into:
}, # table "upsInputEntry" : { "nodetype" : "row", "moduleName" : "UPS-MIB", "oid" : "1.3.6.1.2.1.33.1.3.3.1", "status" : "current", "linkage" : [ "upsInputLineIndex", ], "description" : """An entry containing information applicable to a particular input line.""", }, # row
Any hints?
Thanks, ilya
On Mon, Feb 04, 2008 at 05:32:17PM +0300, Ilya Etingof wrote:
Looking at the "smidump -f python" output, I'm not sure how to distinguish IMPLIED INDEX object from just INDEX one. That is, the following SMI code (from SNMP-COMMUNITY-MIB):
snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular community string." INDEX { IMPLIED snmpCommunityIndex } ::= { snmpCommunityTable 1 }
gets converted into
"snmpCommunityEntry" : { "nodetype" : "row", "moduleName" : "SNMP-COMMUNITY-MIB", "oid" : "1.3.6.1.6.3.18.1.1.1", "create" : "true", "status" : "current", "linkage" : [ "snmpCommunityIndex", ], "description" : """Information about a particular community string.""", }, # rowwhere I see no clear indication of the IMPLIED status of this INDEX. Or is it the "create" flag?
We could generate
"implied" : "true",
where it is needed, similar to what you get with
$ smiquery node SNMP-COMMUNITY-MIB::snmpCommunityEntry
/js
That would be absolutely great! I wonder if a patch would be available before a formal release....
Thanks, ilya
We could generate
"implied" : "true",where it is needed, similar to what you get with
$ smiquery node SNMP-COMMUNITY-MIB::snmpCommunityEntry
/js
On Mon, Feb 04, 2008 at 05:51:45PM +0300, Ilya Etingof wrote:
That would be absolutely great! I wonder if a patch would be available before a formal release....
I just committed a patch to the SVN since this was trivial.
/js
I just realized that this "implied" flag should probably be specific to sub-index rather than being object wide. Consider the following object for example (DISMAN-EVENT-MIB):
mteTriggerEntry OBJECT-TYPE SYNTAX MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger. Applications create and delete entries using mteTriggerEntryStatus." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerTable 1 }
Beware, I'm not an SMI guru. ;)
Thanks, ilya
That would be absolutely great! I wonder if a patch would be available before a formal release....
I just committed a patch to the SVN since this was trivial.
/js
On Mon, Feb 04, 2008 at 07:06:41PM +0300, Ilya Etingof wrote:
I just realized that this "implied" flag should probably be specific to sub-index rather than being object wide. Consider the following object for example (DISMAN-EVENT-MIB):
mteTriggerEntry OBJECT-TYPE SYNTAX MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger. Applications create and delete entries using mteTriggerEntryStatus." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerTable 1 }
Beware, I'm not an SMI guru. ;)
Well, I am. ;-)
You can only have on IMPLIED and it can only affect the last element of an INDEX.
/js
Hello,
With smidump's Python driver, it becomes impossible to easily distinguish OBJECT-GROUP from NOTIFICATION-GROUP item in the output.
For instance:
ifCounterDiscontinuityGroup OBJECT-GROUP OBJECTS { ifCounterDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects providing information specific to interface counter discontinuities." ::= { ifGroups 13 }
linkUpDownNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { linkUp, linkDown } STATUS current DESCRIPTION "The notifications which indicate specific changes in the value of ifOperStatus." ::= { ifGroups 14 }
translates into:
"ifCounterDiscontinuityGroup" : { "nodetype" : "group", "moduleName" : "IF-MIB", "oid" : "1.3.6.1.2.1.31.2.1.13", "status" : "current", "members" : { "ifCounterDiscontinuityTime" : { "nodetype" : "member", "module" : "IF-MIB" }, }, # members "description" : """A collection of objects providing information specific to interface counter discontinuities.""", }, # group
"linkUpDownNotificationsGroup" : { "nodetype" : "group", "moduleName" : "IF-MIB", "oid" : "1.3.6.1.2.1.31.2.1.14", "status" : "current", "members" : { "linkUp" : { "nodetype" : "member", "module" : "IF-MIB" }, "linkDown" : { "nodetype" : "member", "module" : "IF-MIB" }, }, # members "description" : """The notifications which indicate specific changes in the value of ifOperStatus.""", }, # group
Maybe it would make sense to keep the group type information somewhere in python structures?
thanks, ilya
participants (2)
-
Ilya Etingof -
Juergen Schoenwaelder