Scenarios

Connect directly with RFC 2217

Reach a serial server directly over a LAN or VPN and control its serial parameters as well as its data.

  1. RFC 2217 Client
  2. Reachable LAN or VPN
  3. On-site serial server
Scenarios

Connect directly to a remote serial port with RFC 2217

Use this when the client can reach the site's computer or serial server by IP address and TCP port. This usually means the same LAN or an already connected VPN.

If the site cannot be reached directly, use Web remote debugging.

The typical path is: Remote RFC 2217 client → reachable network → on-site TCP Server ⇄ physical serial port → device.

At the site: create the RFC 2217 server

  1. Configure endpoint A for the device's physical serial port and match the parameters in its manual.
  2. Choose Edit → Add Port for endpoint B; pick TCP/UDP → TCP Server, listen on the LAN address or AnyIPv4, and use a port such as 6000.
  3. Open Tools → Bridges… → New, choose the physical port and TCP Server as the two ends, and select A ⇄ B (both ways).
  4. Enable the bridge and Open both ends automatically. Choose RFC 2217 server and keep Forward immediately framing.
  5. Keep One client at a time. Set Allowed clients if needed and allow the port through the host firewall.

At the remote end: connect directly

Pick Remote Serial (RFC 2217) in the Port list and enter the site's reachable LAN or VPN address with the same 6000 port. Confirm TCP comes up, followed by The remote port accepted serial parameter control., then send a known command and verify TX/RX and the device response at both ends.

For the full setup of each end, see RFC 2217 server and RFC 2217 client; for the trade-off against transparent TCP and Cloud Console, see Choosing a remote access path.

End-to-end acceptance and layered troubleshooting

This path crosses two machines. Check these layers in order to separate network reachability, RFC 2217 negotiation and physical serial communication:

  1. The site shows that its TCP connection is waiting or connected, on the same address and port entered at the remote end.
  2. The site's bridge manager reports Running, with dropped staying at 0 in both A→B and B→A directions.
  3. The remote end first reports a TCP connection, then The remote port accepted serial parameter control.
  4. After the remote end clears "Keep the remote port's own configuration", change one parameter and confirm the site's physical port follows it.
  5. Send a known command, verify TX/RX changes at both ends and confirm the device replies.
  • Connection refused: check the site's listen address, port, firewall and Allowed clients list. Binding only to 127.0.0.1, blocking the port in a firewall or excluding the client from Allowed clients all prevent remote access.
  • TCP connects but falls back to transparent TCP: the peer is not an RFC 2217 server, or the site's bridge still uses Transparent mode.
  • Parameters are disabled or never sent: check whether "Keep the remote port's own configuration" is still ticked at the remote end.
  • Negotiation succeeds but the device does not reply: check the site's physical port, serial parameters, wiring and command.
  • Garbled data: first verify baud rate, parity and stop bits on the site's physical port.

RFC 2217 has no encryption or authentication, so do not expose it directly to an untrusted public network.

If the remote program needs only the byte stream, change the bridge to Transparent. The client must then use plain TCP as well; it can no longer connect as RFC 2217.

Common checks after creating a bridge

  • Both endpoint panes are open and show bridge badges. The manager should report Active rather than Degraded or Suspended.
  • The direction matches the topology. A one-way bridge does not return responses automatically.
  • Dropped counters should remain zero. A non-zero value means the sink is too slow, the buffer is too small or the source cannot be throttled. Fix the cause before merely increasing the buffer.
  • Keep One client at a time for TCP servers by default. If several request/response clients must share the device, use Take turns together with idle-gap, delimiter or fixed-length framing. All clients share the port can interleave requests on the serial wire.
  • Save the endpoints and bridge together in a .spu project for repeated use, and re-check the physical port assignments after loading it.

Was this document helpful?