Discover hosts before interpreting services
Choose a bounded IPv4 subnet from the local interface. Host discovery answers which addresses are worth probing; it does not prove that any service is Modbus. Local interfaces and known neighbor-table entries are useful evidence, but the final result must come from an application-layer request.
Validate the protocol, then the Unit ID
Send a conservative supported request and validate the MBAP header, transaction identifier, protocol identifier, length, Unit ID, function code, and response shape. A valid Modbus exception still proves that the endpoint speaks Modbus; it may simply reject the chosen function or address.
For a gateway, the TCP endpoint and downstream Unit ID are separate parts of the route. Finding the gateway does not enumerate every serial slave behind it.
Treat TLS trust as a finding, not invisibility
A TLS handshake can identify an endpoint even when the certificate is expired, self-signed, issued for another name, or not trusted by the workstation. Report the IP and port with the validation failure. Let the operator decide whether to install the correct CA, select the expected client identity, or deliberately allow an insecure test connection.
Run broad port discovery only on networks you own or are authorized to test. Even a bounded scan is active traffic and may trigger monitoring systems.
Define the subnet from the selected interface
Choose the interface that actually reaches the device network and derive the smallest subnet that contains the expected equipment. Scanning 127.0.0.1/32 tests one local address; scanning a /24 tests up to 254 ordinary host addresses; a /16 expands that to more than sixty-five thousand. A typo in the prefix changes both the duration and the network scope materially.
Treat ARP or neighbor-table entries as host evidence, not Modbus proof. They can accelerate discovery on a local segment, but routed devices may not appear there and stale entries may remain after a host disappears. The protocol probe still has to validate each candidate endpoint.
Search ports without assuming the standard
Port 502 is conventional for Modbus TCP and 802 is assigned to Modbus Security, but deployed products, gateways, containers, and development simulators often use other ports. A complete endpoint result therefore includes IP address, port, transport, Unit ID used for validation, response classification, and latency.
Opening every TCP port on every active host can create a large workload. Discover active hosts first, limit the subnet, cap concurrency, and distinguish closed, refused, timed out, TLS, and non-Modbus responses. Do not label an endpoint as Modbus merely because a TCP connection succeeded.
Promote the result into a named profile
Re-run one conservative request against the discovered endpoint before saving it. If a gateway is involved, probe the intended downstream Unit ID rather than accepting any response from the gateway itself. For TLS, restore certificate validation and verify identity before treating the route as commissioned.
Name the profile after the device or route, not only the IP address. Save timeout, retries, Unit ID, and trust configuration with it. Network discovery answers where a service responded; the profile records how the application should connect reliably after the discovery window closes.