Blog

MIB Smithy SDK 4.4 Released

MIB Smithy SDK version 4.4 is now available for download. This release includes the following changes, which will be incorporated into new MIB Smithy and MIB Views releases shortly:

274: Alphabetize command options

The list of command options given in error messages when a bad option is given is now alphabetized to make it easier to figure out the correct option. They’ve also been alphabetized in the SDK documentation.

530: Add APIs for configuring local Engine ID

A -localengid session configuration option was added in an earlier SDK release, but was not used for anything. The option can now be used to configure the actual snmpEngineID value for the session for when the session is the authoritative engine (i.e., when receiving SNMPv3 inform requests).

3778: Fat Binaries for Mac OS X

Fat binaries (PPC and x86 32-bit) for the SDK are now available.

531: Add SNMPv3 Inform Support

Support for receiving and responding to SNMPv3 inform requests at all security levels is now supported. Previously inform requests could be sent with SNMPv3, but could only be received with SNMPv2c.

4719: Add support for SNMPv3 context name/engine ID

Added -ctxname and -ctxengineid session configuration and message generation options for specifying SNMPv3 contextName and contextEngineID. If -ctxengineid is empty (default), contextEngineID will be the same as msgAuthoritativeEngineID, which was the prior behavior.

4728: Default local SNMP Engine ID assignment

The session’s -localengid value was previously defaulted to an empty string. Sessions are now assigned a unique partially-random Engine ID at creation time or can be assigned the same Engine ID. (The non-random component is based on the Muonics enterprise number and Product ID, per the SnmpEngineID TEXTUAL-CONVENTION). Persistence to non-volatile storage is left to the user to implement as they wish.

4657: Allow local interface selection for traps

A -localaddress session configuration option was added to specify the IP address of a local interface to bind to for receiving notifications. The default (empty string) indicates that notifications should be received on all applicable interfaces, which was the previous behavior.

4720: Add option to configure remote Engine ID

A -engineid session configuration option was added to configure the remote SNMP Engine ID (the one authoritative for request PDUs), primarily to hook into the Tnm compatibility. The value configured will be changed in response to a usmStatsUnknownEngineIDs report from the agent, however.

4758: Recursive OID assignments can cause hang

In some cases, two OID assignments that were defined as subnodes of each other could cause an infinite loop during MIB validation. Measures were implemented to fix the cases where this could still occur.

4392: Startup crash when no physical interfaces are detectable

When no ethernet interfaces were detectable, a bad pointer when generating the message about needing a license key (that includes the list of Host IDs) could lead to a crash or corrupted error message at startup.

4393: Windows: Startup crash obtaining Host IDs under Windows 7

A buffer overrun could lead to a crash at startup when using using one of the fallback methods to obtain the list of available Host IDs (particularly, but not necessarily, under Windows 7).

4187: Duplicate sysUpTime or snmpTrapOID in translated v1 traps

The SDK translates received SNMPv1 traps into SNMPv2 format by converting the v1 trap fields into into snmpTrapOID and sysUpTime varbinds. However, if the sending agent included varbinds with these OIDs already (e.g. due to translation by proxy along the way) then multiples of these varbinds could appear. The received varbinds are now discarded in favor of the ones generated by the SDK’s translation.

4464: Code audit for Tcl_Obj leaks

A thorough code audit was done to check for any leaks of allocated Tcl_Obj values and several were fixed. In general, the ones that were found only occurred when an API call resulted in an error (e.g. allocating an empty Tcl_Obj for the non-error result that was not discarded before returning an error). Since Tcl holds onto the memory for discarded Tcl_Objs for later reuse, though, and the error would likely be due to a script error to be corrected, the impact was negligible.