How can I redirect serial data over Telnet on my network?

Networking
1

I’m trying to redirect data from a serial device so I can access it over Telnet from another machine on my network. I’m not sure which tools, settings, or protocols I should be using, and my current attempts either drop the connection or don’t forward data correctly. I need help understanding the right way to bridge a serial port to Telnet, including any recommended software, configuration steps, and common pitfalls to avoid.

2

If your goal is basically “serial to telnet over LAN,” you’re on the right track, just missing a couple of key pieces.

There are two typical ways to do this:

1. Using a software TCP/Telnet bridge on a PC

You plug the serial device into a machine, then run a tool that exposes that serial port as a TCP or Telnet server so another host can connect.

Common options:

  • ser2net (Linux)

    • Install: sudo apt install ser2net
    • Edit /etc/ser2net.conf, something like:
      2000:telnet:600:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT
    • This listens on TCP port 2000, speaks a telnet-like protocol, and forwards to /dev/ttyS0.
    • Then from another machine: telnet yourhost 2000.

  • socat (Linux / macOS)

    • Example:
      socat -d -d TCP-LISTEN:2000,reuseaddr,fork FILE:/dev/ttyS0,b9600,raw,echo=0
    • Then connect with any telnet or raw TCP client to port 2000.

  • Serial to Ethernet Connector (Windows + Linux)
    If you want a GUI and don’t feel like messing with configs, something like Serial to Ethernet Connector is pretty much built for what you’re describing. It lets you:

    • Share a COM port over TCP or Telnet
    • Configure baud rate, parity, flow control from a UI
    • Auto reconnect and log data so stuff doesn’t silently drop
      Their page on redirecting a serial port to a Telnet session basically walks through this “serial device on one machine, Telnet client on another” scenario.

This approach is ideal if the serial device is physically connected to a regular PC.

2. Using a hardware terminal server / serial device server

If you can put a little box in front of the serial device:

  • Devices from Lantronix, Digi, Moxa, etc
  • Plug serial into the box, give the box an IP
  • Configure its web UI for:
    • Serial params (115200 8N1 or whatever your device needs)
    • “TCP server” or “Telnet” mode on some port

Then from any machine on the network:
telnet device-ip port
and you get the serial console.

Common “gotchas” that cause drops / garbage

  • Wrong serial settings: Baud, parity, data bits, stop bits must match exactly. Garbage characters = mismatch.
  • Flow control: If device expects RTS/CTS and you have it off, stuff “randomly” drops. Check hardware vs software flow control.
  • Nagle / buffering: Some bridges buffer too much. If latency feels weird, look for options like “low latency mode” or disable Nagle (TCP_NODELAY) if supported.
  • Raw vs telnet mode: Some stuff expects raw TCP, not telnet negotiation. If your client app freaks out, try a raw TCP client instead of classical telnet.

If you just want something that works without learning half of networking, I’d start with Serial to Ethernet Connector on the host that has the serial cable, set it up as a Telnet server, and then connect from your other machine with telnet or PuTTY. That usually solves the “I tried some random tools and everything keeps dropping” problem pretty quickly.

How can I redirect serial data over Telnet on my network?
How can I redirect serial data over Telnet on my network?1536×951 199 KB

3

You’re basically building a poor man’s “serial console server,” which is fine, but Telnet is the worst possible protocol to glue on top if you’re not careful. @sterrenkijker covered the classic software bridge + hardware box angle pretty well, so I’ll focus on what usually goes wrong and a couple of alternative approaches.

1. Check if you actually need Telnet

A lot of serial-to-network tools can serve plain TCP sockets. Telnet adds option negotiation bytes that some devices or clients choke on. If your client is just a terminal emulator (PuTTY, etc.), you can usually:

  • Use Raw mode instead of Telnet
  • Point it at host:port of your bridge

If your “drops” look like weird control characters, it might be Telnet options confusing the other side. In that case, configure your bridge for raw TCP instead of telnet-mode.

2. If you really want Telnet, control the line discipline

Most of the trouble happens here:

  • Disable local echo on the TCP/Telnet side if your serial device already echoes characters.
  • Turn off line buffering: you want characters forwarded as they arrive, not after a newline.
  • Make sure the bridge sets the port to raw mode so the OS is not messing with CR/LF, XON/XOFF, etc.

On Linux, for example, using stty -F /dev/ttyS0 raw -echo -icrnl -onlcr before starting your bridge can help a lot, so the serial port behaves like a clean byte pipe.

3. Flow control & “random” drops

This is the bit people skip and then think the network is flakey:

  • Check the serial device manual for:
    • RTS/CTS (hardware)
    • XON/XOFF (software)
  • Make sure your bridge tool and your cable wiring actually provide what the device expects.
  • If you’re not using flow control but the device is chatty, buffers fill up and you lose bytes silently.

No amount of Telnet tweaking will fix bytes that never left the UART.

4. Consider running the client side as a virtual COM, not as Telnet

Instead of “serial → telnet → eyeballs,” you can do:

serial device → Serial to Ethernet Connector → TCP port → virtual COM on another machine

On the remote PC you then open a fake COM port, and your normal serial software thinks it’s talking to a local port. That often solves weird app issues where Telnet framing or terminal behavior causes problems.

For that, something like Serial to Ethernet Connector is actually handy:

  • On the machine with the real serial port, expose it as a TCP/Telnet server with correct baud/parity/flow control.
  • On the remote machine, create a virtual COM that connects to that IP/port.
  • Use your usual terminal / logging / SCADA software on the virtual COM.

It’s more robust than raw Telnet when you’re dealing with finicky legacy apps.

5. Logging & diagnosing the drops

Before you tweak yet another setting, verify where things vanish:

  1. On the machine directly connected to serial, run cat /dev/ttyS0 | hexdump -C (or use a serial monitor on Windows) and confirm the data is solid before bridging.
  2. Then use a packet sniffer like tcpdump / Wireshark on the bridge port.
  3. If bytes leave the serial side but never appear on the network, the bridge tool or serial config is misbehaving.
  4. If they’re on the network but the Telnet client does not show them, the client or Telnet-negotiation is messing them up.

This beats randomly swapping tools and hoping.

6. Small disagreement with the “just throw a tool at it” approach

Where I’d slightly disagree with @sterrenkijker is the implication that picking the right tool alone usually fixes the drops. In my experience, serial parameters and flow control are the real killers, not the choice between ser2net vs socat vs GUI. You can absolutely make any of them misbehave if baud/parity/RTS/CTS are wrong.

Get the serial layer rock solid first, then worry about Telnet vs raw vs virtual COM.

7. Where to get the software

If you go the Serial to Ethernet Connector route, you can grab installers and documentation here:
get Serial to Ethernet Connector for stable serial-over-network access

That’s a decent starting point if you’re tired of terminal settings and command-line glue and just want a GUI-driven way to share a serial port over the LAN.

TL;DR:

  • Prefer raw TCP over Telnet unless you specifically need Telnet.
  • Make sure baud/parity/flow control match your serial device exactly.
  • Use raw mode on the serial port and disable unnecessary echo/translation.
  • If this is for an application, not just a human terminal, a virtual COM via Serial to Ethernet Connector is smoother than plain Telnet.
2 Likes
4

You already got solid pointers from @ombrasilente and @sterrenkijker on tools. I’ll zoom out a bit and cover “architecture choices” plus where Telnet actually makes sense.

1. Decide what the other side expects

Before picking tools, answer:

  • Are you a human with a terminal emulator?
  • Or is it an application that expects a local serial/COM port?

If it is a human:

  • You can use Telnet or raw TCP to a serial bridge.
  • Telnet is only useful if you need classic terminal behavior (negotiation, environment options).

If it is an application:

  • Do not use Telnet at all.
  • Give the app a virtual COM port that tunnels over TCP.

This is where something like Serial to Ethernet Connector fits better than just ser2net or socat: it emulates a serial port on the client side, so your app thinks the device is local.

2. Telnet vs raw: pick one intentionally

I slightly disagree with the “Telnet is just fine” vibe. Telnet adds negotiation bytes, which can:

  • Confuse simple serial protocols.
  • Break binary data streams.
  • Make it harder to debug.

Use Telnet only if:

  • You are dealing with a text-only, interactive console.
  • You actually want terminal-style features.

Use raw TCP if:

  • Device sends binary or strict framed packets.
  • You see strange extra bytes or broken packets.

Most terminal clients (like PuTTY) can do “Raw” mode, which avoids Telnet negotiation altogether.

3. Where Serial to Ethernet Connector is actually useful

Think of three common setups:

  1. Serial device → PC A (physical COM) → PC B (human with terminal)
  2. Serial device → PC A → PC B (legacy app expecting COM)
  3. Serial device → headless box / VM → multiple clients

Serial to Ethernet Connector helps most with 2 and 3.

Pros:

  • GUI configuration of baud, parity, flow control, port number.
  • Can create a virtual COM port on the remote PC, so legacy apps run unmodified.
  • Handles reconnects, connection persistence, and logging more gracefully than ad‑hoc CLI glue.
  • Easier for non-Linux / non-cli users on Windows environments.

Cons:

  • Not free, unlike ser2net or socat.
  • Heavier and more complex than necessary if all you need is “one laptop, one cable, one quick session.”
  • Introduces another layer that can hide misconfigurations if you do not verify serial parameters carefully.
  • Less scriptable than pure CLI tools in some automation scenarios.

If you want something that you set once and then forget, especially in Windows-heavy networks, it often beats tinkering with many small tools.

4. Avoiding “it works for a bit, then drops”

Most “drops” people blame on the network or Telnet are actually:

  • Flow control mismatch

    • Device wants RTS/CTS but you wired only RX/TX/GND.
    • Or device expects XON/XOFF and your bridge is not using it.

  • Latency and buffering

    • Nagle’s algorithm on the TCP side causing clumping.
    • Serial side buffers filling because nobody is reading fast enough.

For a stable setup:

  1. Confirm serial settings in the device manual: baud, data bits, parity, stop bits, flow control.
  2. Configure them identically in your bridge tool (including Serial to Ethernet Connector if you use it).
  3. Enable hardware flow control only if the cable and device truly support RTS/CTS.
  4. On the bridge, pick “raw mode” on the serial side so the OS does not insert translations.

5. When a hardware serial device server is worth it

Where I slightly diverge from @sterrenkijker: I think cheap dedicated serial device servers are underrated if you care about reliability.

They give you:

  • A box with a UART tuned for this exact job.
  • Web UI to set serial + TCP/Telnet modes.
  • Often better electrical characteristics and isolation.

For permanent infrastructure (router consoles, PLCs, lab gear) they tend to be less fragile than “old PC in the corner running a script,” even if that old PC is running ser2net or Serial to Ethernet Connector.

Use the software approach when:

  • You are still experimenting.
  • You must run on an existing PC.
  • You need integration with other software on that host.

6. Simple decision tree

  • Need remote human console, text only →
    Use serial bridge + Telnet or Raw mode. Telnet only if you need classic terminal features.

  • Need remote legacy Windows app to see a COM port →
    Use Serial to Ethernet Connector to create a virtual COM on the client.

  • Need “set and forget” box in a rack, multiple devices →
    Consider a hardware terminal/serial server, with Telnet or raw TCP enabled.

Get the serial parameters and flow control right first, then layer Telnet or TCP on top. Most of the headaches vanish at that point.