Blog

MIB Views 1.7 Released

MIB Views 1.7 is now available. Changes in this release include:

3173: Save/restore window geometry across sessions

The size and position of the MIB Views main application window is now saved on exit and restored at launch, rather than using a fixed size/position at each new session.

276: Support loading MIBs/PIBs directly from RFCs

Like MIB Smithy, you can now add MIBs to MIB Views by directly adding the RFC text file. MIB Views will extract and load any MIB modules it finds.

3491: Add firefox to browsers tried for help

When opening html help files from MIB Views, which currently uses whatever browser is available on the system, FireFox is now among the browsers that are tried.

520: Save agent settings for defaults between MIB Views sessions

MIB Views will now save and restore last connected agent address, port, version, username, timeout, and retries, to use for defaults at the next session.

2460: Default window size on Windows with multiple displays

The default window size is no longer relative to the desktop size, but rather a fixed size at first launch (and saved/restored per case 3173). On multiple displays this caused the window to span all of them at every launch.

522: Auto-completion not happening in Query OID field

Auto-completion of typed names is now supported in the Query Tool’s OID field, as is with the “Go to” bar at the top of the application.

2688: Can’t recall main window when only trap monitor left open

The Trap Watch tool’s Window menu now has entries for opening the main application window. Previously if all windows were closed except the Trap Watch, you’d need to exit and relaunch the application to get the main window back.

3523: Linux: Application won’t launch outside terminal

Under Linux, the application wouldn’t launch from the file explorer or as a regular application icon added to the menus. It would only launch from the terminal/CLI or as a “terminal application” due to an exception at startup when trying to determine the user ID.

3540: get-bulk endOfMibView handling problem

SNMPv2/v3 exceptions in varbinds will no longer be treated as values to be formatted and displayed in the various lists/tables. Previously something like “endOfMibView” could end up rendered as (for example) a bogus DateAndTime value.

3465: Whitespace in snmp query tool name/oid field causes error

White space is no longer allowed in the SNMP Query tool’s OID field or the “Go to” entry at the top of the application. Previously, entering white space would cause an application error.

2707: Clarify “Invalid OBJECT IDENTIFIER” error

A generic “Invalid OBJECT IDENTIFIER” was given when trying to issue an SNMP request with a symbolic OID that couldn’t be fully resolved. It will now instead give an “Unable to resolve OID” error that indicates which parent couldn’t be resolved and likely reason.

2708: Clarify “search string is ambiguous” errors

The generic “record search string is ambiguous” error is replaced with an error indicating which string is ambiguous, along with a list of non-ambiguous matches.

3524: Randomize starting request-id and message-id

The starting request-id and message-id for an SNMP session is now random, rather than starting at 0 for each session.

2691: Improve randomness

Changes have been made to the use of random numbers (e.g. for SNMPv3 authentication/privacy salts) to make them more random.

3525: Matching Reports to Requests if agent doesn’t parse PDU

When matching SNMPv3 reports to pending requests, only the message-id will be used instead of also matching the request-id. SNMPv3 allows for the possibility that the security model may trigger a report to be sent back by an agent to a manager without the request PDU being parsed, which would cause the request to time out rather than processing the report.

3526: Update time window for resent SNMPv3 messages on timeout

When SNMPv3 requests time out, they will no longer be sent with the same engineBoots/engineTime values when resent; instead the time window will be updated and the message re-encoded (and re-encrypted/authenticated if applicable).

310: Clarify dependency failure for duplicate module names

When a module name referenced by MODULE-COMPLIANCE or AGENT-CAPABILITIES is ambiguous, the validator message incorrectly indicated that it was an IMPORTS module reference that was ambiguous.