On this page
On this page
Choosing a remote access path
There are three 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.
How the three 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.
Side by side
| RFC 2217 | Transparent TCP | Cloud Console | |
|---|---|---|---|
| Network requirement | Client reaches the site IP and port | Client reaches the site IP and port | Site has Internet access; no inbound port |
| Change serial parameters remotely | Yes | No | Yes |
| Drive DTR/RTS remotely | Yes | No | Yes |
| What the client is | This application, an RFC 2217 virtual COM driver, pyserial, device-management software | Any TCP program | A browser |
| 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 |
| Encryption and authentication | None; relies on the LAN or VPN | None; relies on the LAN or VPN | Yes, through the account and cloud link |
| Extra cost | None | None | Uses the traffic quota |
| Where to configure it | RFC 2217 server / RFC 2217 client | TCP and UDP debugging | Web remote debugging |
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) — Cloud Console is the only option. 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.
- 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 or Cloud Console when the path crosses the Internet.
The three are not exclusive. A common arrangement is RFC 2217 on the LAN day to day and Cloud Console while travelling, both 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.