A Sneek Peek at MIB Smithy SDK 4.0
As I mentioned earlier, version 4.0 of MIB Smithy SDK is extremely close to release, now with only 9 cases left open (of which 3 are implemented but just need more QA testing, and one is nearly finished). I thought I’d whet your appetite with a summary of what’s coming, but I also wanted to give fair warning regarding a couple points of compatibility so there are no surprises.
Compatibility issues are one of the main reasons for bumping the major version to 4.0, since Tcl’s “package require
” version matching mechanisms make it easy to ensure your scripts pull in a version of a package that is compatible. If you use “package require SmithySDK 3.0
” then Tcl will load the latest 3.x version found, but won’t load 4.x, so if there’s any migration you need to do in your scripts then you can change the required version as the migration is done.
The two potential compatibility issues are changes to [officially] supported platforms and in the handling of binary data passed to and returned by the APIs. I’ll get those out of the way first, as they are important, and then tell you about the new enhancements that will also be in the release.
Supported Platform Changes
The minimum version requirements for the Linux, FreeBSD, and Solaris platforms will be changing to something a bit more recent. Current releases are built against Fedora Core 5, FreeBSD 4.3, and Solaris 2.7, which are ancient and long past end of life. I’ve held off requiring newer versions for the next major version because I don’t like to break compatibility in a minor or patch level release. Plus the Solaris development machine, gifted to the company many years ago already many years used, died a couple months ago. That’s why there are no Solaris demos at the moment: I’m still shopping for a replacement; the demo builds expired and can’t be rebuilt at the moment.
We’re currently building 4.0 against FreeBSD 6.2 and Fedora Core 7 (kernel 2.6.23.x), and chances are we are looking at Solaris 10+ (as that’s likely what’s available), so these are likely to be the minimum officially supported versions: as it is, FreeBSD 6.2 and FC7 are both somewhat old. The software will likely run just fine on earlier versions, we just won’t be able to guarantee it since the FC5 and FreeBSD 4.3 VMs, only still around for SDK 3.x builds, will be retired soon after the 4.x release.
There are two upsides here, however, in that (1) I suspect it’s us who’ll be catching up a bit to our user’s platforms, not vise versa; and (2) the last of those 9 cases to be worked on for 4.0 is I’ll be looking at (not promising yet) Linux x86_64 support. I have a VM set up for it already, but I know need to upgrade at least one third-party library before our software will build on it, then I’ll see how it fares against the more than 2000 automated regression test scripts we have for the SDK now (probably 1500 or more written to test the architecture changes in 4.0).
API Changes for Binary Data
The way binary data (OCTET STRING, etc.) is handled is changing. Once upon a time, Tcl didn’t initially have support (or at least good support) for working with binary data at the Tcl level, but it’s now had this for many years (initially with Tcl 8.0, but there were bugs). To work around the limitation, I chose to use a hex format like "0x01:ab"
that each of the APIs would accept or return (for example, in request variable bindings or a session’s community string). The SDK would check if a given value had this format and convert it to the equivalent octets, or check if a value to be returned contained anything other than 7-bit printable ASCII and convert it to hex. While this makes such values readable for interactive use, it’s cumbersome for scripts that want to make use of actual binary data. It’s also problematic for using strings that just look like they’re in that format but aren’t intended to be if the APIs go and reinterpret them when you don’t want them to.
And, ever since Tcl’s binary support became stable, I’ve wanted to drop this eventually. Tcl has its own way of specifying binary data in hex ("\x01\xab"
), or other formats like unicode, so the SDK having its own hex format is superfluous. But I’ve similarly held off switching to binary for a long time so that it could be done with a major version bump according to package versioning rules. So, instead of using its own hex format, as of 4.0 the APIs will now accept (and return) binary data directly (as Tcl_ByteArrayObjs at Tcl’s C layer). This change affects values in variable bindings, session configuration options (e.g. community strings), values parsed from instance identifiers, etc.
My hope is that switching to binary will have little or no impact on your scripts. Any value you get out of an API call (e.g. get request) and feed back into an API call (e.g. set request) should continue to work, since both sides of the conversion will go away. In general, you should also already be using the [smilib format]
command to format SNMP values according to DISPLAY-HINTs when you want to display or print them. If you do, you shouldn’t see much impact there. Strings containing only 7-bit printable ASCII characters should be unaffected because they were not previously converted, and are indistinguishable from byte arrays already. Any impact will largely be confined to values currently hard coded in hex (which are fairly simple to convert to Tcl’s own syntax) or issuing requests in Tcl’s interactive mode (which may print gibberish for binary data).
The [smilib format]
command has new capabilities to help as well. Where you now have to specify an OBJECT-TYPE or TEXTUAL-CONVENTION to format a value against, in 4.0 you can specify base types such as "OCTET STRING"
to use a default format. For "OCTET STRING"
, that default format is the same as before, but without the 0x
prefix (so, "01:ab"
instead of "0x01:ab"
). You can use this to, for example, get a guaranteed-printable version of, say, an SNMPv3 User Name (which is typically, but not necessarily, plain text).
Summary of Enhancements
Full release notes will be available with the release, but here’s a quick run down of the new goodies in MIB Smithy SDK 4.0, which will also find their way into MIB Smithy and MIB Views with their next feature releases:
- IPv6 support
- Improved raw binary data support (explained above)
- A new license key format to simplify managing multiple license keys (includes the serial number in plain text, for example)
- A new licensing option (user based, rather than host based)
- Many new MIB and PIB validation rules
- Many clarifications to messages or error levels from existing MIB and PIB validation rules
- More issues in your MIB and PIB modules are automatically corrected for you
- Improved socket error reporting
- Additional properties for working with table definitions smilib
Best of all (for me) is the new architecture will be easier to maintain and extend, and once 4.0 is out I’ll be free to focus all my energy back into new features rather than maintaining two code branches or getting the new architecture to a stable release. With all the QA automation that’s been done for 4.0, it took a long time, but it should be the the most stable dot-zero release of any piece of software I’ve done.
Getting Very Close to MIB Smithy SDK 4.0 Release
It’s been a very, very long time coming, due to the scope of architecture changes and QA testing required (along with numerous distractions along the way, including the pain of maintaining to very diverging branches of code), but I’m so close to finally releasing MIB Smithy SDK 4.0. I had told a few people that I was trying hard to get it out by the end of 2009, which obviously has passed. But there’s a bit more I’m trying to squeeze into the release (to make it more worthy of a major version number) and tiny bit more QA test automation to do for one of the feature changes.
As I write this, I have 16 open feature and 7 open bug cases in FogBugz currently targeted for 4.0, which is down from and 31 features and 13 bugs a week ago, to give you an idea how close it is and how much progress is being made.
My focus for these last cases is primarily clarifying some existing MIB/PIB validation messages, adding more validation routines where gaps in coverage were uncovered during the big QA test automation push (which involved hard core analysis of old vs. new code and revisiting the standards documents), and closing nearly all of the known bugs in the SDK. The latter is particularly important to me in getting to where I can make it policy aim for each release to be “known bug free”.
At this point there are only 10 total remaining bug cases, and the three not targeted for 4.0 are so minor or obscure as to not matter for now: one of them, for example, is about comments just before macros not being preserved by the parser because we skip over (but don’t preserve) the macros themselves. Well, macros are only defined in the SMI base modules, which don’t change, so it’s a stretch to call it a bug and there’s no reason hold 4.0 any longer for it.
With the 4.0 release so close I can almost taste it, I feel a bit more comfortable talking about it, and you may have noticed I’ve also been sprucing up the Muonics web site a fair bit in preparation. I’ll be back later today or tomorrow with a little preview of MIB Smithy SDK 4.0.
PS: I set up a new twitter account for another way to follow the goings on at Muonics. If I set things up correctly, this post should show up as the first tweet automatically.
MIB Smithy 4.1.5, SDK 3.4.8, MIB Views 1.4.4 Releases
We’re now in the final stretches of automating regression tests for our MIB parsing and validation code in preparation for releasing the 4.0 branch of the SDK, with better than 3/4 of the test automation done. After the latest round of several hundred tests and analyzing the current results, we identified some more areas for improvement in the validation code we felt were appropriate to release in the current stable branch. These include eliminating redundant messages, clarifying other messages, correcting some false errors, some error level adjustments, and some additional rules. The changes below are incorporated into the latest releases for MIB Smithy, MIB Smithy SDK, and MIB Views.
1735: INDEX and AUGMENTS forbidden with RFC1155-SMI, RFC1065-SMI
It is now an error, rather than a warning, for an OBJECT-TYPE to have an INDEX or AUGMENTS clause when imported from RFC1065-SMI or RFC1155-SMI.
1760: TEXTUAL-CONVENTIONs must not derive from other TEXTUAL-CONVENTIONs
It is now an error, rather than a warning, for SMIv2 modules to define TEXTUAL-CONVENTIONs derived from other TEXTUAL-CONVENTIONs. This is also now an error for COPS-PR-SPPI modules, which previously gave no warning.
1747: Additional validation for variant access levels
PIB-MIN-ACCESS is now checked to ensure its values are allowed by COPS-PR-SPPI. MODULE-COMPLIANCE’s PIB-MIN-ACCESS and MIN-ACCESS, and AGENT-CAPABILITIES ACCESS, are now checked to ensure their values are within bounds of the referenced object’s (or PRC’s) MAX-ACCESS or ACCESS value.
1761: Improved version-specific validation with missing IMPORTS
Previously, when a macro (such as OBJECT-TYPE) was not imported as required, certain version-specific validation checks (such as allowed STATUS values) were suppressed, giving only an error about the missing import. Now, the version may be assumed based on other imports that are present, allowing further checks to be performed.
1733: Suppress bit zero warning when no bits are defined
A redundant warning regarding starting BITS at zero when also erroring about needing at least one bit to be defined.
1738: Clarify access keywords in error messages
Validator messages should use the proper access keyword (ACCESS, MAX-ACCESS, PIB-ACCESS, MIN-ACCESS, PIB-MIN-ACCESS) depending on the record type and version (SMIv1, SMIv2, COPS-PR-SPPI) of the record. In some cases, they simply said “ACCESS”.
1701: False errors and changes to BITS DEFVAL validation
The algorithm for checking set bits in hex/binary DEFVALs versus BITS named bit values was not correct, leading to errors for valid DEFVALs. Also, an integer is no longer allowed for DEFVAL with BITS type, and undefined bits may no longer be set in the DEFVAL (previously these were warnings).
1720: Disallow hyphens in COPS-PR-SPPI identifiers
As with SMIv2 modules, which COPS-PR-SPPI derives from, a warning is now produced for identifiers with hyphens in PIB modules.
1717: Wrong range given in INSTALL-ERRORS message
INSTALL-ERRORS was being checked versus the correct allowed range of 1..65535, but the error message indicated 0..65536 was allowed.
1689: False subordinate OID warnings for conformance records
Conformance sub-records were not properly ignored when checking relative structure of the OID tree, causing false errors/warnings to be produced (nothing should be considered relative to these records as they’re purely an implementation detail, not truly separate from the conformance statement).
1682: Value Assignment values missing from error messages
Error messages regarding ASN.1 Value Assignment values not matching the type were giving an empty string for the value rather than the actual value. (Note: only ASN.1 Value Assignments of type OBJECT IDENTIFIER are allowed in MIB and PIB modules; this validation is part of plain ASN.1 support.)
1685: False warning for starting bit zero when using BITS-derived type
A warning message was produced for OBJECT-TYPEs with SYNTAX referencing a TEXTUAL-CONVENTION of type BITS indicating that bits should start at zero even when the TEXTUAL-CONVENTION itself started at bit zero.
1684: Missing error for invalid PIB-REFERENCES
An incorrect function argument was suppressing the error message for PIB-REFERENCES pointing somewhere other than a PRC (row) OBJECT-TYPE.
1759: REVISIONs not sorted properly by XML parser
MODULE-COMPLIANCE REVISIONs are normally sorted when assigned or parsed from normal SMI syntax (with parse-time warning in the latter case), and therefore not checked during validation. They were not sorted properly by the XML parser, however, leaving them out of order with no indication. They are now sorted at parse time from XML as well.
1716: Severity of Value Assignments in SMIv2/SPPI
It’s now an error, rather than a warning, to use ASN.1 Value Assignments other than of type OBJECT IDENTIFIER in SMIv2 and COPS-PR-SPPI modules. It remains a warning for SMIv1 modules, but is now suppressed entirely for modules that aren’t SMI or SPPI (just ASN.1).
1736: Redundant messages for Counter with bad ACCESS
Use of Counter, Counter32, or Counter64 syntax and ACCESS, MAX-ACCESS, or MIN-ACCESS value unknown to the SMI version now produces one error message for the unknown value, rather than a second for the value being disallowed with counter types.
1729: PIB-INDEX may use attributes of other PRCs
An error message was produced if PIB-INDEX referenced an attribute of another PRC (table) rather than an attribute of the same PRC. As this is explicitly allowed by RFC 3159 section 7.5, this check has been removed.
1731: OID in module header forbidden in SMIv2
It’s now an error, rather than a warning, to assign an OID to a module in the module in SMIv2 or COPS-PR-SPPI modules (which use MODULE-IDENTITY instead). It remains a warning in SMIv1 and is now suppresed for modules that are neither SMI or SPPI (just ASN.1).
1728: OBJECT-IDENTITY and Assignment with same OID should be a warning
It is now a warning, rather than an error, when an OBJECT-IDENTITY statement and OID Value Assignment have the same OID, as it is with an OID Value Assignment and other macros having the same OID.
1727: Missing error for INDEX with negative enumerations
An intended warning for an INDEX pointing to an object with possible negative enumerations was not being produced.
1725: Superfluous auxilliary INDEX warnings
The warning for a table using only columns from other tables for indices is no longer generated when already indicating an error because the INDEX clause is not allowed (e.g. on a scalar OBJECT-TYPE).
1711: Undefined symbols should always error if known to be undefined
Dependency check “failed” errors and “skipped” warnings are now more consistent in behavior: e.g., a check is “skipped” with a warning if cross-checking can’t be performed because a module isn’t loaded, while an error is produced if it is loaded but the symbol imported from is not defined.
1710: Mixing SMI and COPS-PR-SPPI base types/macros
It’s now an error, rather than a warning, to import both SMI and COPS-PR-SPPI base types and macros within the same module (note: importing MIB OIDs and TEXTUAL-CONVENTIONs in PIB modules is allowed, provided the underlying base type is the supported by the SPPI).
1690: Wrong format indicated in DEFVAL type/value mismatch errors
When comparing the form of DEFVAL values to an object’s SYNTAX, the wrong keyword for the form of the value was specified in some errors pertaining to hex and binary. The wording of DEFVAL type/value related messages is also now more consistent.
1686: Redundant hex/binary length errors
When validating hex and binary DEFVALs, redundant errors were produced for some types when they were both not of the required length for that type and not the right multiple of digits. There was some inconsistency in whether or not they were checked for capitalization, and the wording of hex/binary related messages was also clarified.
1683: UNIQUENESS value missing from message
A warning message regarding UNIQUENESS values was showing an empty string for the value rather than indicating the actual value warned about.
1708: SMI base modules should not require MODULE-IDENTITY
On the off chance you load SNMPv2-CONF into the SDK and validate it, despite not defining anything other than macros, it will no longer error about needing a MODULE-IDENTITY statement (as with other SMI/COPS base modules).
MIB Smithy 4.1.3, SDK 3.4.7, MIB Views 1.4.3 Releases
I guess I jumped the gun a little bit in stating that the previous releases would likely be the last based on the MIB Smithy SDK 3.4 branch, prior to releasing SDK 4.0. The main reason for the previous releases was to fix case 1406 (circular type references cause crash), which was discovered while creating regression tests for SDK 4.0. I’d not yet finished all the regression tests for SYNTAX validation, so it slipped by that the fix for case 1406 also caused some SYNTAX validation steps to be bypassed (shame on me).
The problem was discovered while finishing those regression tests, and this release restores the bypassed validation steps. While I was at it, I thought I’d back-port fixes for a few other validation bugs also uncovered while preparing the regression tests.
Changes in these releases:
1478: Fix for case 1406 caused some syntax checks to be bypassed
The fix for case 1406, which resolved an issue with circular type references, inadvertently blocked base type resolution in some cases, causing some syntax-related checks to be bypassed.
1479: Special cases for ExtUTCTime, ObjectName, and NotificationName
Errors regarding the disallowed importing of ExtUTCTime, ObjectName, and NotificationName (internal to SNMPv2-SMI) are now suppressed when validating the COPS-PR-SPPI or SNMPv2-CONF base modules.
1480: MODULE-IDENTITY required in PIB modules
As with SMIv2, an error message will now be produced for COPS-PR-SPPI (PIB) modules lacking a MODULE-IDENTITY statement.
1481: MAX-ACCESS read-write not allowed for Counter types
SMIv2 requires Counter32 and Counter64 OBJECT-TYPEs to have MAX-ACCESS read-only or accessible-for-notify. The error message indicated this properly, but the actual check was instead allowing read-only or read-write.
1483: Inverted check for SMIv2 INDEX object accessibility
A warning intended to be produced for INDEX OBJECT-TYPEs with MAX-ACCESS other than not-accessible was instead produced for every version except SMIv2. This has been corrected, and it will also now be suppressed for indexes from other tables.
1484: Duplicate warning message for empty PRODUCT-RELEASE field
Two separate warnings were being produced for an empty PRODUCT-RELEASE field in AGENT-CAPABILITIES validation. The duplicate warning has been removed.
An Ironic Argument for Using MIB Smithy
I must admit I’ve been sadly lax in getting this blog rolling for articles and things other than announcements. I had a plan in mind of some topics I wanted to start out with, but you know what they say about the best laid plans. I’d been collecting topics for a while but intended to stick with the plan for starting out. Well, priorities shift often, and nearly two years later (!) I still hadn’t started. Sometimes topics would come up that I wanted to write about when they were timely, but by the time I’d get to it they wouldn’t be anymore. So I made it one of my New Year’s Resolutions this year to forget The Plan, which by now was getting in the way, and Just Do It. It’s with this in mind that I just had to share this little tale of current projects, and why you need MIB Smithy if you’re a MIB author.
MIB Smithy, as you may be aware, is our editor/compiler environment for SNMP MIBs. My goal in creating the product was to make it as easy as possible for novices to write MIBs, but thorough enough in checking and enforcing standards compliance and compatibility with other compilers that even staunch experts and purists, who wrote MIBs using text editors and command-line tools, to use. Such a tool would save developers a great deal of time and money through a little form-filling and point-and-click action to quickly generate fully standards-compliant MIBs rather than through manual editing and worrying about silly things like missing a comma or curly brace.
In this regard, I believe I succeeded in my goal, though I’m always looking for ways to improve upon it. There are over 650 validation checks based on calls to generate compiler messages alone, which doesn’t account for checks handled by a single function applied in multiple places (like all the checks done on all OIDs). I’m a fan of eating out own dog food, so when consulting clients ask me to design and implement MIBs for them, I use MIB Smithy myself to do so and save weeks of development time in the process, translating to less billable time for the client. I like to believe using MIB Smithy saves our users similar time and costs whenever they use it, allowing the software to quickly pay for itself many times over.
Flash back to 2001 for a moment when I started writing the software, with the core in C++ and GUI in Tcl/Tk. The standards compliance of C++ compilers, particularly Visual C++ 6.0, were abysmal. Much of the architecture of the C++ portion needed to be based on partially reinvented wheels because one couldn’t rely on a simple thing like a standard string class being portable between platforms and compilers, and I design for cross-platform support as a rule. As time went on, the “partially” aspect became more and more of an obstacle to implementing various plans for the product, much as the compilers once were.
C++ standards compliance in g++ and Visual C++ have both come a long way since then, as have open source cross-platform libraries for previously tedious things to implement. For the 4.0 SDK development branch, I decided it was time to uplift, refactor, and simplify the code to get rid of the maintenance cost of those tired old wheels. That was a rather large undertaking itself due to how deep and interconnected the dependencies ran. Unfortunately, back in 2001, I hadn’t yet picked up the habit of test driven development, which is the idea that you write unit tests before (or in parallel with) with the code you’re testing. I did later, which means there are a lot of automated regression tests for things like SDK APIs that came later, but there weren’t for core functionality like the MIB parser and validator, originally tested manually, that haven’t changed much–exactly the places with the most code changes now.
Recognizing the need to thoroughly check for regression issues before releasing the 4.0 SDK branch, I hired someone to tackle regression test automation for the parser (about 450 tests there), and I’m currently working on tests for those 650++ checks our compiler does. That means, essentially (and tediously), writing about 650 small MIB modules, by hand, intentionally broken in various ways that the MIB Smithy editor won’t let you (or will only let you because sometimes you need break something temporarily to remove a dependency or change a design). Therein lies the irony.
As a side benefit, I have in a few instances discovered some previously unknown bugs in the current stable branch and been able to fix them. But boy do I wish I could be eating our dog food right now. Don’t you? Why don’t you give MIB Smithy a try?