Docs.bmc.com will undergo a brief maintenance outage 27 March 2025. The site will be unavailable for ten minutes starting at 6:30 AM CDT/5 PM IST.

Dark space scans

Dark space scanning removes the need for organizations with sparsely populated IP space to perform sweep scans to determine the IP addresses which should be scanned.

Stages in dark space scanning

Scanning is undertaken in two distinct stages:

  • Pre-scanning
  • Scanning

Pre-scanning is the initial stage of discovery. The list of endpoints to be scanned is segmented into blocks of 256, and each block is passed to discovery. The endpoints are then pre-scanned in parallel using the following techniques if enabled in discovery configuration and the IP address is not part of an exclude range:

  • Ping
  • TCP ACK ping and/or TCP SYN ping

If pinging is not permitted:

  • The endpoints are port scanned, using the TCP/UDP ports configured for initial scans.
  • The valid port states setting is used to determine whether a port is open.

If a device is present and desktop discovery is disabled (the default), an SMB query is used to determine whether the endpoint is a Windows desktop. On FIPS-enabled appliances/instances, the SMB query is not used and detection of Windows desktops is done later. If the device appears to be a Windows desktop, the WBEM ports are checked. If it responds on the WBEM ports, it continues the scan as the device is most likely an embedded OS on a storage device, otherwise, it is classed as a desktop.

Endpoint results for dark space scanning

The following results are possible for each endpoint:

  • Response
  • Desktop (only if desktop discovery is disabled)
  • No response

Where there is a response, the endpoint is put into the discovery queue for full discovery.

Where the endpoint is determined to be a desktop, the DiscoveryAccess is created with the result Skipped (Desktop host discovery has been disabled).

For endpoints that have no response, the system searches for a DiscoveryAccess with that endpoint as the last IP address. The following outcomes are possible:

  • Not found.
  • A DiscoveryAccess is found and it has a dark_space flag set.
  • A DiscoveryAccess is found and it does not have a dark_space flag set.

For the first two outcomes, the endpoint is put into a DroppedEndpoints node and no further investigation of the endpoint is undertaken. For the third, the endpoint is put into the discovery queue. The DiscoveryAccess is then aged in a similar manner to DDD aging, though it uses no_response_count and last_response. If the DiscoveryAccess is successfully aged, then the dark_space flag is set.

Aging is also applied to DiscoveryAccess nodes with the dark_space flag set, so dark space endpoints will age out and be removed.

DroppedEndpoints nodes have the following attributes:

UI Name
Attribute Name and Type

Description

Start Time
starttime : date

Start date and time endpoints were dropped

End Time
endtime : date

End date and time endpoints were dropped

Reason endpoints dropped
reason : string

Reason endpoints were dropped. For dark space scans this is: No response from these IPs.

Scope
scope : string

Distinguish overlapping address spaces

Endpoints
ip_addresses : list:string

Endpoints that have been dropped

Endpoints
endpoints : list:string

Endpoints that have been dropped

Number of endpoints dropped
count : int

Number of endpoints dropped

Not shown in UI
__indexes : list:int

Indexes of endpoints which have been dropped

In debug mode, the __reason attribute shows the reasons for a dropped endpoint:

  • Excluded – the endpoint was part of an excluded range
  • Already processing – no longer created in the DiscoveryAccess chain
  • DarkSpace – this endpoint is dark space

In early releases the removed dark space endpoints caused a mismatch in the number of endpoints linked to discovery runs. As the DroppedEndpoints node records the dark space endpoints, this no longer occurs. A single DiscoveryRun can be linked to multiple DroppedEndpoints nodes.