Remote serial port

Remote serial port with Live Relay

A transparent byte pipe across NAT: parameters, control lines and protocol streams all work.

On this page

Remote serial port with Live Relay

Live Relay makes a physical serial port on one of your machines behave as a real port on another. The site machine shares the port, the operator machine opens a connection whose type is Remote Serial (Live Relay), and the cloud in between forwards the bytes without reading them.

Both ends dial out to the cloud, so it works across NAT with no public address and no inbound port — the same network posture as Live Console. The difference is what crosses the link. Live Console is a live window in a browser: text events, frame-limited, view and send. Live Relay is a transparent byte pipe speaking RFC 2217 end to end, so everything a local port can do still works:

  • Change baud rate, framing and flow control from the operator side, or keep the remote port's own configuration.
  • Drive DTR/RTS and Break; the control-line lamps follow the remote port's modem lines.
  • Run protocol streams unmodified — Modbus RTU polling, XMODEM/YMODEM file transfer, firmware updates.

By default both machines are signed in to the same account: you can only relay to your own devices. To let a colleague without an account in, use an invite code — opened in their own copy of the application, or straight in a browser with nothing installed. For how this path compares with RFC 2217, transparent TCP forwarding and Live Console, see Choosing a remote access path.

Share a port (site side)

  1. Sign in inside the application (Cloud menu → Sign In).
  2. Check Cloud → Live Console. The relay rides on the same cloud presence, so the main switch must be on; the consent switches below it stay greyed out until it is.
  3. Check Cloud → Live Relay, or reach the same switch from Live Sync in the status bar. It is off by default and deliberately not implied by Allow Remote Send or Allow Remote Port Control — a relay is the whole port, handed over.
  4. Open the serial connection you intend to share. Only serial connections are offered for relay: RFC 2217 describes a serial port, so a TCP or UDP endpoint has nothing for it to control.

While an operator holds the port, the status bar says so — the Live Sync cell turns orange and reads In use, and the notice names the operator — and the local window keeps displaying the traffic — data with no local sender is a takeover you should be able to see. Unchecking Live Relay ends every active relay from this machine at once.

Use the port from another machine (operator side)

  1. Sign in with the same account.
  2. In a connection's settings, choose Remote Serial (Live Relay) as the port type.
  3. Pick the target in the "Select a Remote Serial Port" dialog. It lists your online devices and their serial ports, and marks the ports whose sharing side has not allowed relay. The port list is fetched from the device on demand, so it can take a few seconds to fill — up to about 30 seconds when the device is on its slow polling path.
  4. Decide who sets the serial parameters — the same rule as an RFC 2217 client: keep "use remote configuration" checked to leave the port as the site configured it, or clear it to push your own baud rate and framing when the connection opens.
  5. Start the connection. The status bar reads "Live Relay · port · connecting", then "connected" once both ends are paired.

From then on it is an ordinary connection: Text/HEX send and receive, timestamps, logging, control lines, CRC tools and file transfer all work, and it can be bridged onward like any other port.

Share from a headless machine (the spu command)

A site machine does not need a desktop session. The direct-download build ships a small console program spu beside the GUI (the Mac App Store build does not include it):

spu -l                                   # list local serial ports
spu login --email user@example.com       # sign in; prompts for the password without echo
spu -D /dev/ttyUSB0 -b 115200            # raw local terminal (stdin ↔ serial)
spu -D /dev/ttyUSB0 -b 115200 --share    # share this port through Live Relay

spu login stores the account session in the same profile the GUI uses; for provisioning scripts, pipe the password to --password-stdin instead of putting it on the command line. -S / --share opens the port and turns on relay consent only — no Live Console traffic stream, no remote send, no generic port-control commands — and it is strictly the sharing side: it never selects or dials another machine's port. An idle sharing agent is a control-plane presence; nothing is captured or uploaded until an operator actually engages the port.

Share with a colleague (Live Share)

The two sections above are about two machines of your own. To let a colleague who has no account work on the port with you, use an invite code: the site machine mints a time-limited code for one open serial port, and your colleague either pastes it into their own copy of the application and gets exactly the port you would have got, or opens it in a browser with nothing installed. They need no registration, no subscription and no bound device; the traffic stays on your side.

This is independent of Live Relay, in both directions: that switch admits your own other machines, an invite admits the holder of the code, to that one port, for that long. For minting, the three browser levels, spu --invite and everything the host can take back, see Live Share.

Good to know

  • One relay per port. A second operator asking for a port that is already relayed is refused loudly rather than silently sharing a byte stream that would give each side half of every reply.
  • A relay that drops — either end going offline, the session closed from the other side — ends; it is not silently redialled. Start the connection again deliberately.
  • The relay is rate-limited per session. A stream faster than the allowance is throttled with real back-pressure toward the source, and a brief "rate limited" advisory appears; each session also has a data ceiling, after which it is closed.
  • Common open failures: the sharing side's Live Relay is off (permission_denied), the port is already relayed (relay_busy), the device is offline, or the account's cloud traffic allowance for the month is used up.
  • Timing quirks aside, the traffic itself is exactly what a direct RFC 2217 connection would carry — byte-for-byte, escaping included.

Traffic, quota and subscription

  • Live Relay does not require Pro; every account can use it. What differs is the monthly traffic allowance — 10 MB per direction on a free account, 1 GiB with Pro (a paid licence or an active subscription), then purchased traffic packs. It bills by usage, not by fleet size, and a forgotten full-speed session would drain a free allowance in minutes.
  • Relayed bytes are metered against the same monthly cloud traffic allowance and top-up balance as Live Console; there is no separate relay quota.
  • Budget with this number: a port running flat out at 115200 8N1 in both directions moves about 22.5 KB/s — roughly 81 MB per hour. Most debugging sessions are far below that, but a busy binary stream is not.

Security and privacy

  • Sharing is off by default, and consent lives on the machine that owns the port; nothing on the web or in the cloud can switch it on remotely.
  • Both legs are outbound encrypted connections. A relay pairs two machines on the same account, or one machine with the holder of an invite code it minted itself — either way the machine that owns the port is what authorises it.
  • Within an accepted relay, changing serial parameters and driving DTR/RTS/Break are intentional parts of handing the port over — grant Live Relay only where that is acceptable.
  • A browser guest sees that one port's decoded text, passed through a short cloud buffer with the same size and retention as Live Console; how far they can go is fixed when you mint the code, checked once by the server and once by your device, and cannot be raised from the web.
  • Switching Live Relay off or signing out ends all relays immediately. These data flows are disclosed in the Privacy Policy.

Was this document helpful?