FireMon Lumeta is pleased to announce the general availability of Lumeta, a micro-release that provides enhancements and fixes issues, described on this page. This release is recommended for all Lumeta users.

Upgrading to Lumeta
Upgrade PathUpgrade Package


3.3.2x Command Center Command Center


SHA256 checksum: sha256sum spectre_update-

0c52223f5a9f082729305e1e8e64248bfdcf5f653b7970310a3e88db93c23460  spectre_update-

3.3.2x Scout Scout

3.3.2x Portal Portal

Lumeta Command Centers are not backward-compatible with older Scouts such as, and Please upgrade your Scouts to version


This release includes the following enhancements:

Case IDDescription
PO-9607Any configuration message received by a Scout used to cause all collectors to reconfigure themselves. Lumeta has been made to be more granular about which collectors can act on particular messages and what exactly a particular message can reconfigure.
PO-9608Scouts have been made to ignore any configuration changes for a disabled collector. When a collector is enabled or re-enabled, its configuration is then read by its associated Scout.
To optimize discovery performance, "TreeSets" were set up for every CIDR added to a List. This enhancement reduced discovery time for a 30K Avoid List from 6 minutes to less than a second.
The number of CIDRs transferred per page has been increased, thereby reducing loads on the database when Scouts request lists from collectors and eliminating associated API timeouts.
PO-9553In the prior release of Lumeta, an API call from the Scout to the CC would occasionally experience a timeout due to database slowness, leaving a Collector unconfigured and preventing scan activity. Customers experienced intermittent outages of scanning. In this release, the Scout logic has been enhanced to include a "wait-retry" after a timeout, resolving the problem.

Fixed Issues

The following issues reported by customers have been fixed: 

Case IDFixed Issue
PO-9605Improve the way we handle collectore configuration changes at the scout level


When the IP address of an existing device changes, the Target, Known, Internal and Eligible Lists are recalculated to reflect the correct current values for the updated IP address. This resolved an issue in which some devices present in a zone's discovery space were incorrectly reported as "false."

PO-9835Also in response to PO-9743, two scripts were prepared: One that identifies and reports mismatches between the, trusted, internal and known with the Target, Eligible, Internal, and Known Lists and another that rectifies the differences. These scripts should be run before upgrading to See Upgrading to Lumeta Spectre for the procedure.

When a CIDR is added to a configuration, changes to a device are now made to apply only to IP addresses contained within that CIDR and not to the parent outside the CIDR.

PO-9083When a collector gets archived, its configuration CIDRs are removed and table columns associated with those configuration CIDRs (Target, Eligible, Known, Internal) are recalculated to reflect those changes.

In previous releases, when a device's IP address for parent and child were the same, only the child device's IP would be recorded in the device response table. As a result of this, Lumeta did not display scan types for the parent IP when it received snmpDiscovery responses from the child's IP address. To fix, Lumeta changed Lumeta's response processing in these instances to also include an entry in in the device response table for the parent device. 

Known Issues

We'll make you aware of any known issues and the work-arounds here.

Lumeta Known IssuesCase ID
1None as of 4/3/2019

Security Updates

Lumeta resolves Common Vulnerabilities & Exposures (CVEs) and incorporates a variety of security-related (and non-security-related) enhancements. No new CVEs were resolved in this release. 

Change Log

Following are the changes made in preparation for this Lumeta release. This information has been refreshed on 5/23/2019 for GA. 


PO-9277 - Scouts picked up collector configuration after a long delay after upgrade

PO-9624 - Collector stops collecting because of timeout in getting a page of configuration CIDRs

PO-9679 - At NJOHS we are seeing devices with target and known=f when the device IP is in zone discovery space

PO-9704 - Device answers SNMP queries for non-interface address

PO-9743 - Identify discrepancies for target, trusted, internal and known

PO-9757 - CLONE - Archiving Collectors does not update Port to 3.3.2-maintenance

PO-9770 - CLONE - Port to maint branch - Disney is seeing devices where SNMP Aliases, snmpAccessible, snmpResponder is all set, yet discovery does not show snmpDiscovery

PO-9792 - CLONE - Port to branch - Identify discrepancies for target, trusted, internal and known

PO-9803 - CLONE - Port to branch - Change algorithm that picks reference ip address to not mandate that reference ip address has to be in target list

PO-9811 - Map does not work on today's netboot

PO-9835 - Write verification and rectification sqls to address target/known/trusted/internal mismatches

PO-9837 - Uploading config cidr updates parent's device values for known, target, trusted and internal

PO-9901 - CLONE - esi-current:Scan is not working for CC/Scout interfaces.Unable to discover devices in scan


PO-9721 - create upgrade to

PO-9805 - upgrade from to fails early at version check

PO-9828 - create esi- netboot and tag


PO-9551 - Change Paging Size of getConfigCidrs in ConfigManager

PO-9553 - Retry Collector Configuration When getCollectorCidrs Fails

PO-9606 - Configuration messages should not necessarily be sent to all scouts

PO-9716 - CLONE - Port to branch - Clear cifsName upon receiving NACK for tcpPorts or cifs

PO-9897 - Bug around suppressing frequent collector updates