Establishing the autodiscovery list

The Autodiscovery module's work is centred on a list of IP addresses and device names which is continuously updated and verified. The list contains the following information for each entry:

  • Name of the device. This is obtained either through the Windows Network Neighbourhood API or a DNS name lookup using the IP address. If both methods fail, the name is set to be the same as the IP address.
  • IP address of the device.
  • Entry Status ( Unverified , Verifying , Verified , Learned , Invalid ).
  • HTTP port used to communicate with agent on device.
  • Discovery date, expressed as seconds since midnight 01 Jan 1970 UTC (epoch).
  • Response time to ping/TCP connect, in milliseconds.
  • Router hop count established through ping. This can only hold the values 1, 2, 4 or 8.Relay enabled.
  • Agent version.

The Entry Status for each address in the device list can have any of the following values. The integer value next to the name is the value used in the Autodiscovery.sqlite database file:



Unverified - 0

The entry IP address has not been verified as being a real device on the network. The verification is done by using either the network name or the IP address of the device.

Verifying - 1

Currently verifying if this device exists on the network.

Verified - 2

The device exists on the network.

Learned - 3

The entry was learned from another Autodiscovery module. When reading the device list from a remote module, only those entries which are Verified or Learned are returned. Therefore when an entry is Learned , it means that its validity was verified by at least one other device on the network.

Invalid - 4

The address did not respond to any pings or other network traffic and so is not a valid device on the network.

The Autodiscovery module updates the contents of the device list at three possible points during its operation:

  1. At Agent Start-up
  2. After ScanCount Verifications
  3. At the Discovery of a Client Executing Autodiscovery

The Autodiscovery schema displayed further on details this process.

At agent start-up

When the Autodiscovery module is started on a device, it creates a list of devices in its database using three different sources as defined through the module settings in the module INI file. These sources are the defined through the following parameters:




defines the number of neighboring IP addresses to add to the device list. This defaults to 10, which means 5 addresses above and 5 addresses below the devices own IP address. If this is set to 0, no neighboring addresses are added to the list.


a list of static addresses to add to the device list. This can be individual addresses or device domain names or address ranges separated by ‘,'. This is empty by default.


on a Windows computer, use the network neighborhood APIs to populate the list. The default value for this entry is true. On a UNIX/Linux computer, this entry is not used.

You can also apply the following parameter to limit the list:




this value specifies if the list of discovered and learned clients is limited to those devices which are located on the same network as the device. The possible values are: 0 = There is no filter applied to any of the discovered devices, add all of them. 1 = All discovered client devices must be on the same network as us. 2 = All discovered devices which have their relay function enabled must be on the same network as us. 3 = All discovered devices must be on the same network as us.

The Autodiscovery module never adds the same address or device name to its list twice. If a duplicate entry is found when trying to add an address to the list, the two entries are merged together.

After ScanCount verifications

The Autodiscovery device list is constantly updated by the module by verifying the oldest address in the list. Each time an entry is verified, whether successfully or not, its update time is set to the current time which causes it to become the newest entry in the list. In this way all addresses are eventually verified in a round-robin fashion.

The module maintains an internal counter which is incremented every time an entry is verified. When this counter reaches the value configured in the ScanCount parameter, the list contents are refreshed in the same way as at agent startup, taking care to correctly merge any duplicate entries. This ensures that any changes to the INI file settings or the network environment are taken into account. For example, if the ScanCount parameter is set to its default value of 30, the list will be refreshed after every 30 verifications. Note, that the existing list contents are not deleted during a refresh.

At the discovery of a client executing autodiscovery

Part of the verification process for an address includes checking to see if there is a CM agent running on the remote device. If an agent is found and the local agents CanLearn parameter is enabled, the discovering module attempts to read the device list of the remote module to integrate it into its own list. As the contents of the read list are being added to the local database, all entries added are marked as Learned to avoid having to verify them in the future. Also, if a new entry is found in the local list, the two entries are merged together to avoid duplicates.

Was this page helpful? Yes No Submitting... Thank you