Siemens S7 Device Discovery With OTserver

Overview

Siemens S7 communication exposes controller identity through System Status Lists (SZLs). OTserver reads the identity lists needed for inventory and associates the result with the MAC address found during ARP discovery.

How OTserver discovers S7 devices

OTserver connects to TCP port 102, negotiates an ISO-on-TCP COTP connection, and performs S7 Setup Communication. It first tries destination TSAP 01:02 and retries with 02:00 when the first negotiation is not accepted.

After setup, the scanner reads SZL 0x0011 for hardware/module details and SZL 0x001C for component identity. Fragmented replies are assembled with strict limits and validated TPKT, COTP, S7, parameter, data-length, record-length, and record-count fields.

Evidence extracted

OTserver evidenceS7 source
VendorIdentified as Siemens for a valid S7 response
ModelModule type, module, or basic hardware record
FirmwareVersion bytes from SZL 0x0011
NameSystem name from SZL 0x001C
Serial numberSerial record from SZL 0x001C
Additional evidencePlant identification, copyright, module, and basic hardware

Security and read-only safety

OTserver requests two diagnostic identity lists. It does not read or write process variables, start or stop the CPU, upload or download blocks, or change controller configuration. Even diagnostic requests consume a small amount of controller and network capacity, so use the protocol toggle and scan only with authorization.

Frequently asked questions

Does S7 discovery require PROFINET DCP?

No. S7 identity is queried over TCP/IP after ARP finds a target. PROFINET DCP discovery is separate and can add Layer 2 names, addressing, and device-role evidence.

Why does OTserver try two TSAP values?

Different S7 endpoints accept different rack/slot conventions. OTserver tries two fixed connection requests and stops if neither produces a valid COTP response.

Compare all supported discovery protocols or configure the scanner.