Resolving SIMATIC IOT2040 PuTTY SSH Connection Failure

Problem Description

When commissioning a Siemens SIMATIC IOT2040 using the example image example-v2.2.0.wic and the official SIMATIC IOT2000 Setting Up manual (V2.1.1), an SSH session to the device via PuTTY (Section 3.2.1 "Remote Access with PuTTY") fails to complete the TCP handshake. Ping tests from the engineering workstation to the IOT2040 yield either timeout or "Destination host unreachable" responses. The host PC typically reports an active interface IP of 172.20.10.12, which is a strong indicator that the workstation is on a non-routable hotspot subnet rather than the IOT2000 service subnet that the manual assumes.

Symptoms observed in this failure mode:

• PuTTY "Network error: Connection timed out" after 10-30 seconds.
• Ping reports "Request timed out" or "Destination host unreachable".
• The PC's active IPv4 address is in a range other than 192.168.200.x.
• Windows Network Connection icon shows an unrecognized public network.
• The link LED on the IOT2040 X1 jack illuminates, but no SSH session is possible.

Root Cause Analysis

The TCP/IP stack rejects the SSH SYN packet because no Layer 3 path exists between the workstation's active interface and the IOT2040's management interface. Layer 2 adjacency (same switch, same wire) and Layer 3 address compatibility (same subnet or reachable gateway) are both required for SSH to reach 192.168.200.1:22. Windows automatically selects the interface with the lowest routing metric for outbound traffic, so simply adding a 192.168.200.x address to a secondary adapter does not solve the problem if a hotspot or USB tether remains active.

The 172.20.10.0/24 subnet is reserved by several platforms for hotspot and tethering services:

Regardless of source, the 172.20.10.x address range is not part of the 192.168.200.0/24 subnet that the IOT2040 example image configures on eth0. The two networks have no bridge, no router, and no route between them on a typical engineering laptop. The fix is to put the wired Ethernet adapter on 192.168.200.x and disable the conflicting interface.

SIMATIC IOT2040 Network and Service Defaults

Understanding the IOT2040's default state is essential to resolving the connectivity issue. The values below are preconfigured in the official Siemens example image example-v2.2.0.wic and described in the SIMATIC IOT2000 documentation, available from Siemens Industry Online Support and the product page at SIMATIC IOT2000.

The hardware platform is built around an Intel Quark x1000 SoC with 1 GB DDR3 RAM and 8 MB on-module flash, augmented by a user-supplied SD card slot. Two independent 10/100 Mbit/s Ethernet ports are exposed on the front panel, identified as X1 (P1, the service port) and X2 (P2, the uplink port). For first-time commissioning, only X1 is used, wired point-to-point to the engineering PC. This is the exact cabling scenario assumed by Section 3.2.1 of the Setting Up guide.

Prerequisites

Before re-attempting the SSH session, verify the following:

1. SIMATIC IOT2040 with the example-v2.2.0.wic image flashed to a microSD card (minimum 4 GB, Class 10 recommended) using tools such as Win32 Disk Imager, balenaEtcher, or dd on Linux.
2. SD card inserted into the IOT2040 before power is applied; the device boots from SD by default.
3. 24 V DC supply connected to the removable terminal block on the front of the IOT2040. Power LED PWR illuminates green within 5-10 seconds.
4. Standard Ethernet cable (Cat 5e or better) between the IOT2040 port X1 and the engineering PC's Ethernet jack. Auto-MDI/MDIX means a crossover cable is not required.
5. PuTTY 0.74 or later (0.78 recommended). The 3.2.1 reference in the manual is a chapter number, not a PuTTY version.
6. The SIMATIC IOT2000 Setting Up manual V2.1.1, available from Siemens Industry Online Support.
7. Administrator rights on the engineering PC to change the Ethernet adapter IPv4 properties (Windows 10/11 requires elevated privileges for static IP changes).

Solution: Configure the PC Ethernet Adapter to 192.168.200.x

Place the workstation on the same 192.168.200.0/24 subnet as the IOT2040 eth0 interface. Disconnect any active Wi-Fi, hotspot, or secondary Ethernet connection that is providing the 172.20.10.x address, since Windows will route outbound traffic through the lowest-metric interface regardless of which one you intend to use.

Step 1 - Disable the conflicting network

Open Settings → Network & Internet → Status. Click the active Wi-Fi or Ethernet connection that shows the 172.20.10.12 address and toggle it off, or right-click the wireless adapter in Control Panel → Network and Sharing Center → Change adapter settings and select Disable. If a mobile hotspot or USB tether is active on the same workstation, disconnect it physically. A Wi-Fi "disconnect" is not sufficient; the radio must be turned off so that Windows cannot prefer that interface by metric.

Step 2 - Open the Ethernet adapter properties

Right-click the wired Ethernet adapter connected to X1 and choose Properties. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.

Step 3 - Enter a static IP in the 192.168.200.x range

Select Use the following IP address and enter:

Set the Preferred DNS server to 8.8.8.8 and Alternate to 8.8.4.4 only if you need name resolution from the PC. Name resolution is not required for SSH to 192.168.200.1.

Click OK twice and close the Network Connections window. Windows resets the adapter for approximately 5 seconds; the link light on the IOT2040's X1 jack should remain steady green or amber (link speed is 100 Mbit/s full duplex on Quark silicon).

Solution: Configure the PuTTY SSH Session

Launch PuTTY. In the Session category, populate the fields as follows:

Enable local echo and terminal line discipline

If PuTTY connects but the shell appears blank, characters typed at the keyboard do not display, or output from the IOT2040 does not appear, configure the terminal settings before opening the session. In the left-hand category tree, expand Terminal and tick the following check boxes:

• Local echo: Force on - the PuTTY client echoes typed characters locally so they appear in the window even before the remote shell acknowledges them.
• Local line editing: Force on - arrow keys, backspace, and Ctrl+C are interpreted by PuTTY before the keystrokes are sent to the IOT2040, preventing garbled command lines on a sluggish link.

These two settings are independent of the SSH protocol and affect only the on-screen terminal rendering. They are commonly toggled on when the remote system does not allocate a pseudo-TTY that echoes back, or when character echo is disabled in /etc/ssh/sshd_config on the IOT2040.

Adjust keepalives to survive long idle sessions

Navigate to Connection and enter the following in the Sending of null packets to keep session active group:

PuTTY will emit an SSH-level null packet every 60 seconds. This prevents intermediate switches and Windows' TCP tuning from silently dropping the session after 2 hours of idle time.

Open the session

Click Open. The first connection attempt triggers a PuTTY Security Alert dialog displaying the IOT2040's SSH host key fingerprint (a SHA-256 hash by default for OpenSSH 7.4+, which ships with the v2.2.0 example image). Accept the key once; subsequent connections compare against the stored fingerprint and warn only on a mismatch (which would indicate a man-in-the-middle or a reflash of the SD card).

Log in as root with the password defined in the example image build notes. The shell prompt displays:

root@iot2000:~#

Solution: Direct Ethernet Cabling and Link Verification

If the link LED on either the PC or the IOT2040 is dark after Step 3, the physical layer is not up. Check the following in order:

1. Cable seating: a standard Cat 5e patch cable is sufficient. Length must be under 100 m for reliable 100BASE-TX operation.
2. Adapter enable state: confirm in Device Manager → Network Adapters that the wired Ethernet adapter is enabled and not in power-saving mode. Right-click the adapter, choose Properties → Power Management and uncheck Allow the computer to turn off this device to save power.
3. Auto-negotiation: the IOT2040 only supports 10/100 Mbit/s. If a USB-to-Ethernet dongle is in use, force it to 100 Mbit/s full duplex rather than auto-negotiate, since some adapters default to 1 Gbit/s and silently fail link.
4. Port selection: the SIMATIC IOT2040 has two RJ45 jacks labelled X1 and X2. The first example image configures the service IP on X1 (the left-most jack, marked P1). Connecting to X2 will yield no link on the service subnet.
5. Switch in the way: if a managed switch is between the PC and the IOT2040, disable STP on that port or speed up STP convergence, since the Quark SoC may not respond to STP BPDUs in the first 30 seconds of boot.

Verification Steps

After applying the static IP and opening the PuTTY session, validate end-to-end connectivity with the following checks. All commands below are entered at the Windows command prompt or in the PuTTY terminal after logging in.

Layer 3 - ping the IOT2040

C:\> ping 192.168.200.1

Pinging 192.168.200.1 with 32 bytes of data:
Reply from 192.168.200.1: bytes=32 time=1ms TTL=64
Reply from 192.168.200.1: bytes=32 TTL=64
Reply from 192.168.200.1: bytes=32 TTL=64
Reply from 192.168.200.1: bytes=32 TTL=64

Ping statistics for 192.168.200.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

A round-trip time of 1-3 ms is expected for a direct point-to-point link. Times in the 10-50 ms range indicate cable or duplex mismatch. A "Request timed out" reply means Layer 3 is still broken - return to Step 1 of the IP configuration.

Layer 4 - TCP port reachability

From an elevated Windows command prompt, use PowerShell to test the SSH port directly:

PS> Test-NetConnection 192.168.200.1 -Port 22

ComputerName     : 192.168.200.1
RemoteAddress    : 192.168.200.1
RemotePort       : 22
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.200.10
TcpTestSucceeded : True

A failed TcpTestSucceeded result with a successful ping indicates a firewall issue. Permit inbound TCP/22 in Windows Defender Firewall, or temporarily disable the firewall for testing.

Layer 7 - login banner and prompt

After successful SSH authentication, the OpenSSH banner displays the Yocto Linux distribution version and the kernel build string. Verify the expected banner before issuing any commands:

root@iot2000:~# uname -a
Linux iot2000 4.4.13-yocto-standard #1 SMP PREEMPT Fri Jan 12 10:06:19 CET 2018 i686 i686 i386 GNU/Linux
root@iot2000:~# cat /etc/os-release
ID=iot2000
NAME="SIMATIC IOT2000"
VERSION="2.2.0 (morty)"
PRETTY_NAME="SIMATIC IOT2000 2.2.0 (morty)"

The PRETTY_NAME line confirms the example image version is 2.2.0, matching the SD card flashed. If the kernel string reports a different version, the wrong SD card is installed in the IOT2040.

Advanced Troubleshooting Matrix

The following table maps common fault symptoms to root causes for the SIMATIC IOT2040 first-commissioning workflow. Use it when the simple static-IP fix does not immediately resolve the issue.

Operational Notes and Field Caveats

When the example image is reflashed, the SSH host key is regenerated. PuTTY's cached fingerprint will no longer match, and a security alert will fire on the next connection. The cached key is stored in the Windows registry under HKCU\Software\SimonTatham\PuTTY\SshHostKeys. Deleting the entry for the IOT2040's IP forces PuTTY to accept the new key on the next connection. This is a security feature, not an error: an unexpected fingerprint change on an unchanged image can indicate a man-in-the-middle attempt and should be investigated before accepting the new key.

For production deployment, the static 192.168.200.1 address on eth0 should be changed to match the plant network. Edit /etc/network/interfaces on the IOT2040:

auto eth0
iface eth0 inet static
    address 10.10.50.100
    netmask 255.255.255.0
    gateway 10.10.50.1
    dns-nameservers 8.8.8.8 8.8.4.4

Reboot with reboot or shutdown -r now and reconfigure the PC to a corresponding subnet. Always document the new address on the panel label of the IOT2040 for field service.

For commissioning multiple IOT2040s on a shared service switch, change the default 192.168.200.1 before connecting the second device. Two devices responding from the same IP on the same Layer 2 segment will produce ARP flapping and intermittent SSH failures. A conservative commissioning pattern is to keep each device on a private service subnet, configure its plant address, then connect it to the production network.

If SSH is not required and only a quick file transfer is needed, the IOT2040 also exposes a web-based terminal on port 80 (Node-RED based) when the example image is running. This is convenient for one-off tasks but is not a substitute for a real SSH session in production work because it lacks the deterministic character handling of PuTTY over a real terminal session.

Frequently Asked Questions