On this page
On this page
Choosing a remote access path
There are four ways to work with a serial device from somewhere else. They do not solve the same problem, and choosing wrongly usually costs you either "connected but cannot change the parameters" or "the network never reaches the site at all".
- RFC 2217 — carries the serial port together with parameter control. The client can change baud rate, parity and DTR/RTS.
- Transparent TCP forwarding — carries bytes only. The parameters are decided at the site and the remote end cannot change them.
- Cloud Console (Web remote debugging) — relays through the cloud so a browser drives the on-site port. The client does not need a route into the site.
- Cloud Relay (remote serial port) — relays through the cloud so the on-site port becomes a real port in the application on another machine, RFC 2217 end to end. Same network posture as Cloud Console, but a transparent pipe instead of a live window.
How the paths differ
Two things separate the diagrams: which end opens the connection, which decides whether the network allows it at all, and the bar underneath, which decides whether the remote end can change serial parameters.
Cloud Relay reuses the third diagram's arrows — both ends dial out, so it too works from behind NAT — but its bar is the first diagram's: the full RFC 2217 stream, data and parameter control, crossing the cloud untouched. The remote end is not a browser but this application (or a third-party tool behind it), holding what behaves as a real local port.
Side by side
| RFC 2217 | Transparent TCP | Cloud Console | Cloud Relay | |
|---|---|---|---|---|
| Network requirement | Client reaches the site IP and port | Client reaches the site IP and port | Site has Internet access; no inbound port | Site has Internet access; no inbound port |
| Change serial parameters remotely | Yes | No | Yes | Yes |
| Drive DTR/RTS remotely | Yes | No | Yes | Yes |
| Protocol streams (Modbus, file transfer, firmware) | Yes | Yes | No — a frame-limited live window | Yes |
| What the client is | This application, an RFC 2217 virtual COM driver, pyserial, device-management software | Any TCP program | A browser | This application — signed in to the same account, or a guest holding an invite code (no account) |
| What the site sets up | Physical port + TCP Server + RFC 2217 server bridge | Physical port + TCP Server + transparent bridge | Sign in and enable remote access | Sign in and allow Cloud Relay, or mint an invite code for one port — GUI or the headless spu --share / spu --invite |
| Encryption and authentication | None; relies on the LAN or VPN | None; relies on the LAN or VPN | Yes, through the account and cloud link | Yes, through the account and cloud link |
| Extra cost | None | None | Uses the traffic quota | Uses the traffic quota; requires a Pro entitlement (on the sharing side — a guest pays nothing) |
| Where to configure it | RFC 2217 server / RFC 2217 client | TCP and UDP debugging | Web remote debugging | Remote serial port |
How to choose
Answer the first question: can the client reach the site's IP address and port directly?
- No (the site sits behind NAT, has no public address and there is no VPN) — the cloud paths are the only options. Opening an inbound port or forwarding one just for this exposes a debugging machine to the public Internet, which costs far more than it buys. Then ask what the remote end needs to be:
- A browser is enough — watching traffic, sending the occasional command, opening and closing ports — use Cloud Console.
- A real port in the application — a protocol has to run end to end (Modbus polling, XMODEM/YMODEM, a firmware update), or a tool on the remote machine must own the port — use Cloud Relay.
- Yes — then ask the second question: does the remote end need to change serial parameters?
- Baud rate, parity, stop bits or control lines have to change — use RFC 2217. Both ends must speak it; one end alone is not enough.
- Only the bytes need to travel, and the parameters are already fixed at the site — use transparent TCP forwarding. The client can be any TCP program and need not support RFC 2217.
Common mismatches:
- The site bridge is left on Transparent while the client connects as RFC 2217 — TCP comes up, but "The remote port accepted serial parameter control" never appears and no parameter ever reaches the port.
- A plain TCP socket connects to an RFC 2217 server — negotiation bytes mix into the data stream and show up as garbage in the first few bytes.
- An RFC 2217 port is exposed directly to the public Internet — it has no encryption and no authentication, so anyone who can connect can change your serial parameters. Use a VPN, Cloud Console or Cloud Relay when the path crosses the Internet.
- A file transfer or Modbus poll is attempted through Cloud Console — it is a frame-limited live window, not a pipe, and the protocol stalls. That job belongs to Cloud Relay.
The four are not exclusive. A common arrangement is RFC 2217 on the LAN day to day and a cloud path while travelling — Cloud Console to look, Cloud Relay to drive — all sharing the same physical serial connection.
For complete end-to-end setups, see Connect directly to a remote serial port with RFC 2217 and Debug a serial port from anywhere on the Web.