Resolving Siemens Sm@rtClient "Read Exact: Socket Error While Reading" on VPN Connections

When a remote engineering workstation attempts to control a Siemens Comfort Panel or WinCC Runtime Advanced HMI through the Sm@rtClient application over an Ewon Flexy VPN, Sinema RC client, or any routed IPSec/OpenVPN tunnel, the connection frequently fails with the dialog text Read exact: socket error while reading. The target HMI is visible in the connection list, the VNC password prompt is accepted, and the Sm@rtServer acknowledges the TCP handshake, but the first frame read from the RFB socket returns zero bytes and the client closes the channel. The fault has been reproduced on TIA Portal V15.1 projects running on TP700 Comfort through TP2200 Comfort panels, on IPC227G / IPC277G WinCC Runtime Advanced targets, and on the second-generation Unified Comfort panels when the Sm@rtServer is reached over a routed path rather than a flat LAN.

This reference consolidates the field-confirmed root causes, the diagnostic procedure, and the corrective actions that have been validated against the official Siemens documentation for the Sm@rtServer / Sm@rtClient architecture.

1. Affected Versions and Components

The following matrix summarizes the components most often associated with the reported failure. The exact firmware or TIA build is not the root cause; the underlying issue is almost always the transport path between the Sm@rtClient and the Sm@rtServer, but specific builds change which settings are exposed.

2. How Sm@rtClient Reaches Sm@rtServer

Understanding the data path is essential to triage. Sm@rtClient and Sm@rtServer communicate over an RFB (Remote FrameBuffer) protocol that is functionally identical to VNC and runs on a configurable TCP port (default 5900, with a per-display offset of +0, +1, ...). The Sm@rtServer inside the HMI publishes a service that the engineering PC must reach, and the Sm@rtClient is a Java RFB viewer bundled with TIA Portal or hosted as a Web Start application.

Per the official Siemens documentation for the Sm@rtClient application, the connection is split into two phases:

1. Discovery / authentication phase - the Sm@rtClient opens a TCP socket to port 5900, performs the RFB protocol version exchange, negotiates the security type (typically VNC Authentication with DES challenge/response), and validates the password. This phase is short, low-bandwidth, and tolerates latency up to several hundred milliseconds.
2. Frame exchange phase - the Sm@rtClient begins requesting framebuffer updates with FramebufferUpdateRequest messages and expects the server to push FrameBufferUpdate rectangles. This phase is bandwidth-sensitive and is where the failure occurs.

The error message "Read exact: socket error while reading" is generated by the underlying Java RFB client when a readExact(n) call cannot fulfill the requested byte count from the input stream. The most common cause is a socket that is closed by an intermediate device (firewall, NAT, VPN gateway) before the full framebuffer update arrives.

3. Root Cause Analysis

Across the field cases the failure has been traced to four primary root causes, which often compound when more than one is present:

3.1 Sm@rtServer not running as a service

Per the Siemens TIA Cloud manual for Sm@rtServer, if the Sm@rtServer is started as an application rather than a Windows service on the panel, the connection is closed automatically when no user input is detected. The error manifests in the client as a socket read failure because the OS terminates the underlying socket. The service-mode setting is exposed in the WinCC RT Advanced control panel of the HMI under Sm@rtServer > Service.

3.2 Java runtime newer than 8u161

Sm@rtClient is a Java application that ships with TIA Portal. Newer Java runtime revisions removed the older TLS cipher suites, the VNC DES authentication helper, and certain socket keepalive defaults that Sm@rtClient relies on. The symptom is identical to a transport failure: the read of the framebuffer update returns zero bytes. Siemens has historically pinned Java 8 update 161 for legacy Sm@rtClient deployments; the corresponding Oracle archive download is jdk-8u161-windows-i586.exe on the Oracle Java 8 archive page.

3.3 Firewall, NAT or VPN idle timeout

When the engineering PC reaches the HMI over a tunnel, the tunnel itself, the corporate firewall in front of the HMI, or the corporate firewall in front of the engineering PC will close idle TCP sessions after a configurable period. The first FrameBufferUpdate request from Sm@rtClient is sent only after the user has interacted with the panel (mouse move, key press). If the first interaction arrives after the tunnel idle timeout, the read on the now-closed socket returns -1 and the client reports the read error.

3.4 MTU / fragmentation regression on the tunnel

FrameBufferUpdate messages can exceed 1 KiB and are commonly 16-64 KiB for full-screen refreshes. If the underlying tunnel is unable to pass full-size TCP segments - for example, after a media change from copper (MTU 1500) to single-mode optical with a lower MTU, or after enabling IPSec encapsulation - the segments are silently dropped or the MSS is not negotiated, the read stalls, and the application times out. The original incident was triggered by switching the backhaul from copper to optical fiber and restarting the RC server, which is consistent with an MTU change rather than a configuration error.

4. Diagnostic Flow

Before applying any fix, isolate the failing layer with the procedure below. Each step takes less than 60 seconds and gives a binary pass/fail that points at one of the four root causes.

1. Confirm local Sm@rtClient works. Connect the engineering PC directly to the panel on the same subnet, run SmartClient.exe, and attempt the same connection. If local fails, the issue is on the HMI (project, password, service mode) and not on the tunnel.
2. Confirm reachability. From the engineering PC over the tunnel, run tcping <panel-ip> 5900 or Test-NetConnection -Port 5900 <panel-ip> in PowerShell. The TCP port must report TcpTestSucceeded : True. If the port is closed or filtered, the tunnel or firewall is blocking RFB before any Sm@rtClient logic runs.
3. Check for an idle-timeout on the tunnel. From a second PowerShell window, run ping -t <panel-ip> continuously while the Sm@rtClient is being used. If the tunnel drops ICMP echoes at the same moment the Sm@rtClient read fails, the tunnel is closing the session and the issue is firewall/NAT idle-timeout, not Java or Sm@rtServer.
4. Capture a packet trace on both ends. Use Wireshark with the display filter ip.addr == <panel-ip> && tcp.port == 5900. Confirm the FrameBufferUpdateRequest leaves the engineering PC and either a TCP RST/FIN is returned, or no FrameBufferUpdate is received. A RST/FIN from the panel or the firewall implicates the tunnel; an unanswered request with TCP retransmits implicates MTU / fragmentation.
5. Verify Java version. Run java -version in cmd.exe. If the reported build is newer than 1.8.0_161, install the pinned build and retry before changing any other setting.

5. Solution: Pin Java 8 Update 161

The simplest and most common fix in the field is to roll the engineering PC back to a known-good Java runtime. Sm@rtClient is sensitive to TLS, JCE, and socket keepalive behavior that changed after 8u161.

1. Open Control Panel > Programs and Features and uninstall every entry for Java, JRE, JDK, and Java 8 Update. Restart the PC.
2. Download jdk-8u161-windows-i586.exe (32-bit, even on 64-bit Windows) from the Oracle Java 8 Archive Downloads page. The 32-bit build is required because SmartClient.exe is a 32-bit Java process.
3. Install with default options. Do not install the Ask.com toolbar or any companion products.
4. Open Control Panel > Java > Java > View and confirm that 1.8.0_161 is the only enabled runtime. Disable any other installed versions or place 8u161 at the top of the user list.
5. Disable Java auto-update under Java > Update > Update so the pinned version is not silently replaced.
6. Re-run java -version in a fresh cmd.exe and confirm 1.8.0_161.
7. Retry the Sm@rtClient connection. If the failure persists, the Java fix is not the root cause and you should continue with section 6.

6. Solution: Run Sm@rtServer as a Service

If the panel itself is the Sm@rtServer (i.e. the HMI is being controlled, not doing the controlling), Sm@rtServer must be configured to run as a service so it survives the lack of an interactive user session. Per the Siemens manual for the Sm@rtClient application, when the Sm@rtServer is started as a normal application, the connection is interrupted automatically if the user does not interact with it.

1. On the panel, open Start > Control Panel > Sm@rtServer (or WinCC RT Advanced > Sm@rtServer on a PC Runtime).
2. Select the Service tab and enable Start Sm@rtServer as a service.
3. Enter the service password and confirm. The service is started immediately and persists across reboots.
4. On the engineering PC, retry the Sm@rtClient connection. If the read error still occurs, proceed to section 7.

7. Solution: Tunnel, Firewall and MTU Adjustments

When the local connection and the Sm@rtServer service are both healthy but the tunneled connection still fails, the transport layer is at fault. Apply the three changes below in order; each one is independent and addresses a different class of transport failure.

7.1 Eliminate idle-timeout on the firewall and tunnel

Most corporate firewalls, Ewon Flexy devices, and Sinema RC servers apply a default TCP idle-timeout in the range of 60 to 300 seconds. Sm@rtClient traffic is bursty: the client sends a FrameBufferUpdateRequest only on user interaction, then waits for the response. Between interactions, the TCP session appears idle and is reaped.

1. On the Ewon Flexy, raise the VPN idle timeout in the VPN configuration to a minimum of 1800 seconds, or disable the idle reaper if the platform supports it.
2. On Sinema RC, raise the Connection timeout for the relevant OpenVPN/IPSEC profile to at least 1800 seconds and disable TCP-level inactivity reaping.
3. On the corporate firewalls on both sides, add a permanent firewall rule that allows the engineering PC source IP, the panel destination IP, and TCP port 5900 in both directions, bypassing the global idle reaper.

7.2 Clamp the MTU on the tunnel

If the read failure coincides with a media change (e.g. copper to optical fiber), an MTU mismatch is the most likely cause. Test the path with ping -f -l <size> <panel-ip> against the engineering PC and reduce the payload size until the DF-don't-fragment echo succeeds. A typical safe value for a single-encapsulation IPSec tunnel is MTU 1400; for double-encapsulation (IPSec inside a VXLAN, or OpenVPN inside IPSec) drop to MTU 1280.

1. Calculate the path MTU with ping -f -l 1472 <panel-ip> and reduce the -l value in steps of 10 until the echo succeeds.
2. Apply the resulting MTU on the tunnel interface of the Ewon / Sinema RC gateway. The setting is typically under Network > Interfaces > MTU.
3. Force the engineering PC to advertise the smaller MSS by adding the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery = 1 and rebooting.
4. Confirm with Wireshark that the SYN from the engineering PC carries MSS = MTU - 40 matching the tunnel MTU.

7.3 Reduce the Sm@rtClient display size and color depth

Sm@rtClient supports a reduced color depth (8-bit) and a reduced window size. Both options cut the size of every FrameBufferUpdate message, which in turn reduces the probability of a fragmented or dropped segment over the tunnel.

1. In SmartClient.exe, click Settings before connecting.
2. Set Color depth to 8 bit.
3. Set Window size to 50 % or smaller.
4. Disable View only if read/write is required.
5. Retry the connection.

8. Solution: TIA Portal Project-Side Sanity Check

If the project was built with TIA Portal V15.1 and later migrated, regenerate the Sm@rtServer configuration to ensure the service password, the port, and the SSL/TLS flag are all current.

1. Open the project in TIA Portal.
2. Navigate to Devices & Networks > <HMI device> > Sm@rtServer.
3. Confirm Enable Sm@rtServer is checked, the port is 5900 (or the documented alternative), and the password is set.
4. If the project was migrated from V13 or V14, recompile the HMI and download it to the panel to flush any stale runtime configuration.

9. VNC Authentication / Java Security Caveats

The Siemens knowledge base PDF "Why do you get an error message when opening the Sm@rtClient ..." documents the case where the Sm@rtClient opens but the browser address bar shows a red certificate error. While not the exact symptom of the socket-read error, the two are related: both stem from the Java security policy on the engineering PC, and a strict policy can also produce a socket-level read failure if the JAR signing check is enforced. Add the panel's IP and the TIA Portal installation directory to the Java Exception Site List under Control Panel > Java > Security as a precaution.

10. Verification

After each fix, validate the connection in three steps:

1. Connection success: Sm@rtClient reports Connected to <panel> and displays the panel screen. Confirm that the first user input (mouse click) is registered by the panel by toggling a value in the project.
2. Stability: Leave the connection idle for at least 10 minutes. If the panel does not disconnect automatically, the idle-timeout fix in section 7.1 is effective.
3. Bandwidth: Move the mouse continuously over the panel for 60 seconds. Wireshark must show full FrameBufferUpdate responses with no TCP retransmits. If retransmits appear, return to section 7.2 and reduce the MTU further.

11. Troubleshooting Matrix

12. Field Tips and Lessons Learned

• Always pin the Java version on every Sm@rtClient engineering station. A Windows Update can silently swap the runtime and reintroduce the read error weeks after a fix.
• When commissioning a new tunnel between an Ewon and a Comfort panel, set the tunnel MTU to 1400 from the start. The default of 1500 will eventually hit a segment that cannot be reassembled.
• If the customer reports a recurring failure every morning, suspect the tunnel's nightly rekey. Reconfigure the rekey to keep TCP sessions alive across the rekey window.
• The TIA Portal version reported in the original incident (V15.1) is not the root cause, but it is the build most commonly paired with SmartClient.exe. Migrating to a newer TIA build does not fix the socket read error - the transport must be fixed first.
• Sm@rtServer on a Comfort Panel can be reached on the same TCP port as the WinCC project; do not assume the default 5900 has been changed without checking the runtime control panel.

FAQ