Blog

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).

Word has come to us by way of The Internet Patrol that Authorize.Net is down due to a fire at their Seattle data center. As we use Authorize.Net as our merchant card services provider, this means that we are likely unable to process online orders using credit cards at this time. We can, of course, still accept purchase orders in the mean time. We’ll update this post when we hear that Authorize.Net services have been restored or if we have any additional news.

UPDATE: Authorize.net says they’re back up (at least the interface we use). Orders placed through our web site should proceed normally.

MIB Smithy 4.1.4 is now available for download. This release fixes the following bugs in the workspaces for AGENT-CAPABILITIES SUPPORTS and MODULE-COMPLIANCE MODULE clauses:

1668: Error editing AGENT-CAPABILITIES modules

A ‘can’t read “window(groups)”: no such element in array’ error would occur when opening the workspace for AGENT-CAPABILITIES modules.

1670: Some combobox lists not updated with record name change

Some comboboxes for selecting available records in a module to be added as a group or variation in AGENT-CAPABILITIES and MODULE-COMPLIANCE statements were not being automatically repopulated when the name of the module (referenced by the SUPPORTS or MODULE clause) was changed, instead requiring the workspace to be reopened or reverted to get an updated list.

1669: Combobox for VARIATION, GROUP clauses populated from wrong module

Some comboboxes for selecting available records in a module to be added as a group or variation in AGENT-CAPABILITIES and MODULE-COMPLIANCE statements were being populated from the module in which the conformance statement was defined, rather from than the module referenced by the statement’s SUPPORTS or MODULE clause.

Muonics now has a presence on Facebook! If you’re a Facebook user, please consider becoming a fan of the page(s) that interest you. You can show your support for Muonics and our products and subscribe to news and articles as an alternative to subscribing directly to the Muonics blog.

You can find separate fan pages for MIB Smithy, MIB Smithy SDK, and MIB Views if you’d like to receive updates and join the community just for those products, or the Muonics, Inc. page with a consolidated view of them all and other more general features.

They’ve just been set up today so there might not be a lot there yet, but we do hope you’ll join us.

[Editor’s Note: In theory, this blog post should also serve as a test to verify the RSS-to-Wall automation is working. :)]

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.