How can I share a Linux serial port with a Windows machine?

Serial Communication
1

I have a device connected via serial to a Linux PC, but I need to access and control it from a Windows computer on the same network. I’m not sure what tools or settings I should use to reliably forward or share this serial port over the network so Windows can see and use it like a local COM port. What’s the best way to set this up, and are there any security or performance issues I should watch out for?

2

You basically have two main routes here: DIY with native tools or use a ready‑made serial over IP solution. For what you want (Linux box hosting the serial device, Windows machine using it “like COM1”), the second route is usually a lot less pain.

1. Concept in plain terms

  • Linux machine has the real serial port, say /dev/ttyS0 or /dev/ttyUSB0.
  • You run a server on Linux that exposes this serial port over TCP.
  • On Windows you install a client that creates a virtual COM port and forwards all traffic over the network to that Linux TCP port.

Once this is set up, Windows apps just see a normal COM port and don’t care that the device is actually plugged into Linux.

2. Easiest “it just works” approach

A dedicated serial over network tool is going to save you a lot of hacking around with socat and weird scripts.

A solid option here is Serial to Ethernet Connector. It basically does:

  • On the Linux side: shares your local serial port over TCP or over a virtual LAN.
  • On the Windows side: creates a virtual COM port that connects to that Linux endpoint.

So your Windows terminal program or SCADA or whatever talks to COM5, and behind the scenes that data is actually going over the LAN to Linux and into /dev/ttyUSB0.

If you care about reliability and reconnects and not babysitting it after every reboot, this is the easiest way. It also avoids a lot of stty/permissions nonsense.

3. Roll your own with socat & TCP (more manual)

If you want “free and fiddly”:

On Linux (server):

sudo apt install socat

# Share /dev/ttyUSB0 at TCP port 5555
socat -d -d TCP-LISTEN:5555,reuseaddr,fork FILE:/dev/ttyUSB0,raw,echo=0,b115200

Adjust the baud rate to match your device.

You then get a TCP socket at linux_ip:5555 that basically forwards bytes to and from the serial device.

On Windows (client side):

You now need a COM port redirector that maps COMx to linux_ip:5555.

Options:

  • Free tools like com0com + com2tcp can do it but they are fiddly and old.
  • Some terminal programs can talk directly to a TCP port, but they will not create a COM port, so only apps with TCP support can use it.

This is why a proper serial over Ethernet app is usually nicer: it handles the redirector side cleanly and presents a normal COM port.

4. Permissions / stability tips on Linux

  • Make sure your user or service can access /dev/ttyUSB0 or /dev/ttyS0
    Add user to the dialout group for most distros:
    sudo usermod -aG dialout youruser
  • Use systemd service or a screen/tmux session if you go with socat so it auto‑restarts.
  • Check for power management or USB sleep issues if the device disconnects randomly.

5. Helpful resource

If you want a more step by step explanation of Linux to Windows COM port redirection, this guide is actually pretty handy:
Set up Linux to Windows virtual COM ports over Ethernet

It walks through creating virtual serial connections between Linux and Windows and shows how a tool like Serial to Ethernet Connector fits into the picture.

Bottom line

  • If you want minimal hassle and a real COM port in Windows: use Serial to Ethernet Connector on both sides and be done with it.
  • If you want a DIY approach: socat on Linux to expose the port, plus a Windows COM redirector that points to the Linux TCP endpoint. Works, but you’ll babysit it more when something changes or breaks.
3

You’ve already got solid input from @yozora, so I’ll skip repeating the socat + random COM-redirector recipe and the “just install Serial to Ethernet Connector and click next” walkthrough.

Instead, here are some different angles you might actually care about in the real world:

1. Decide what you really need on Windows

Before picking tools, clarify:

  1. Do you absolutely need a real COM port on Windows?

    • Example: Old SCADA, CNC, PLC tools, proprietary config software that only lists COM1–COMx.
    • If yes, you need a COM redirector or something like Serial to Ethernet Connector.

  2. Or can the Windows tool talk directly over TCP?

    • Many modern terminal apps can open a TCP socket (e.g. “connect to host:port”) instead of COM.
    • In that case you don’t need a virtual COM port at all, which simplifies everything.

If your Windows software supports TCP, then:

  • On Linux: expose /dev/ttyUSB0 or /dev/ttyS0 via a TCP server.
  • On Windows: configure the client to connect to linux-ip:port directly.

This avoids the whole “fake COM port driver” mess.

2. Robust option: dedicated serial over IP tool

I slightly disagree with the idea that this is only about “ease.” For production, a commercial serial over Ethernet solution is often not just easier, it’s more predictable:

  • Proper reconnect handling
  • Service mode at boot
  • Survives user logoff
  • Logging and diagnostics
  • Often supports encryption

Serial to Ethernet Connector fits this use case pretty well:

  • On Linux:
    • It exposes your physical serial port (USB or PCI) over the network via TCP or a virtual LAN.
  • On Windows:
    • It creates a virtual COM port that maps to that remote Linux serial over IP endpoint.

Result: your Windows software happily talks to something like COM5, completely unaware that the device lives on /dev/ttyUSB0 on the Linux host.

This is boring and reliable, which in serial-land is exactly what you want.

3. Alternative to socat: ser2net on Linux

If you don’t want to rely only on socat, use ser2net, which is basically built for “serial to TCP”:

  • It runs as a daemon
  • Has a config file
  • Handles multiple ports nicely
  • Usually packaged in most distros

Example idea (not full commands since @yozora already covered CLI stuff):

  • Install ser2net
  • Edit its config to map port 2000 to /dev/ttyUSB0 at your device’s baud rate
  • Restart service

Then on the Windows side, either:

  • Use a COM redirector that maps COMx to linux-ip:2000, or
  • If your app can, just connect via TCP to linux-ip:2000.

Compared to socat, ser2net is less of a one-liner hack and more of a “leave it running for months” style solution.

4. Security & isolation (most people ignore this)

This is the part that always gets skipped and then bites later:

  1. Do not expose your serial forwarding TCP port to the whole network, especially if the device controls something important.
  2. Bind only to the Linux host’s LAN IP or localhost plus SSH tunneling:
    • Example:
      • On Linux, bind serial server to 127.0.0.1 only.
      • From Windows, create an SSH tunnel to linux-ip that forwards local port 5555 to 127.0.0.1:5555.
  3. Or use a serial-over-Ethernet tool that supports built-in authentication or encryption.

If this is production / industrial control, nothing should be casually open on port 5555 to the whole office.

5. Handling disconnects and flaky USB

One thing I’ll push back on a bit: tools alone won’t save you from hardware weirdness.

  • Many USB-serial adapters randomly change device name (/dev/ttyUSB0 to /dev/ttyUSB1) after replug or reboot.
  • Fix that with udev rules tying the device to a stable name like /dev/serial_device_1 using serial number or vendor/product IDs.
  • Then point your sharing tool (ser2net, Serial to Ethernet Connector, whatever) at that stable symlink, so it doesn’t break when Linux decides to reshuffle /dev entries.

Also check:

  • Disable USB power saving if the device drops after idle.
  • For headless servers, make sure your forwarding service starts early and restarts on failure.

6. Clean summary of your practical options

If your Windows software needs a real COM port:

  • Most straightforward and robust:
    • Use Serial to Ethernet Connector
      • Linux: share /dev/ttyUSB0 over TCP
      • Windows: create a virtual COM port bound to that endpoint
  • Or DIY:
    • Linux: ser2net or socat
    • Windows: some COM redirector (these can be fiddly and dated)

If your Windows software supports TCP:

  • Linux: ser2net (or socat as a quick hack)
  • Windows: connect via TCP from your app directly
  • No virtual COM port needed, fewer moving parts.

7. Extra reading that actually helps

There’s a decent, approachable Linux serial over Ethernet guide that walks through exactly this Linux-to-Windows virtual COM scenario, including how Serial to Ethernet Connector fits into the picture and how to avoid the usual traps with configs and permissions.
You can check it out here:
setting up reliable Linux to Windows virtual COM ports

If you just want it to work and not babysit scripts, I’d lean strongly toward a dedicated serial over Ethernet solution and keep the DIY stuff for lab/experiments.

2 Likes
4

You already got the “socat/ser2net + COM redirector” angle from @cazadordeestrellas and the “just use a commercial tool” angle from @yozora, so here’s a different way to look at it: how do you pick between those, and what are you trading off?

1. First decision: protocol vs fake COM

You basically have two layers here:

  1. Physical serial on Linux
    /dev/ttyS0, /dev/ttyUSB0, etc.

  2. Windows side requirement

    • If your Windows software only knows COM ports, you need a virtual COM port driver.
    • If it can talk TCP directly, serial-over-IP becomes much simpler and you can skip creating fake COM ports.

If you can avoid a virtual COM port on Windows, life gets easier and you probably do not need something like Serial to Ethernet Connector at all. You just expose the serial port via TCP on Linux and connect from Windows.

If you are forced to have a real COMx, then a serial-over-IP tool or COM redirector is mandatory.

2. Where I slightly disagree with the others

  • @yozora is right that rolling your own with socat + random redirector works, but in practice it tends to rot over time: driver updates, minor Windows changes, weird reconnect bugs.
  • @cazadordeestrellas is right to highlight “production reliability,” but I would not jump to a full-blown commercial package if your use case is:
    • One device
    • Non critical
    • Used by you only, not a whole operations team

In that light, I’d classify solutions like this:

  • Lab / single-user / non critical: ser2net or socat + app that speaks TCP
  • Legacy Windows app that only knows COM & must be reliable: Serial to Ethernet Connector or a similar mature COM redirector
  • Industrial / multiple devices / remote sites: a proper serial-over-IP stack with monitoring and secure access, often including Serial to Ethernet Connector but combined with VPN/SSH etc.

3. Serial to Ethernet Connector: actual pros & cons

If you go the “commercial tool” way, Serial to Ethernet Connector is a legit option. Not magic, but it solves a bunch of annoying issues.

Pros

  • Real COM ports on Windows
    Old Windows apps see a standard COMx. No patches, no special configuration beyond choosing the COM number.

  • Unified solution
    Same product handles:

    • Linux: exposing /dev/tty* over the network
    • Windows: mapping that to a COM port

  • Reconnect & service mode
    Generally better at:

    • Reconnecting automatically if the network drops
    • Starting at boot and running as a service
    • Working even when nobody is logged in

  • Multiple ports / scaling
    If you later add more devices, it is easier to configure several virtual ports and keep them organized than with a pile of socat commands and registry hacks.

  • Less driver weirdness
    The virtual COM drivers from established vendors are usually better tested than old open source redirectors that have not been updated for years.

Cons

  • Cost
    Obvious one. For a single hobby project or one-off lab tool, paying for Serial to Ethernet Connector might feel like overkill when ser2net + a free TCP client would do.

  • Vendor dependency
    You are tied to their driver and ecosystem. If you later move platforms, you must keep that in mind.

  • More “black box”
    With socat/ser2net you can see and tweak every parameter. With a commercial GUI, you get flexibility but not the same script-level control. That can be annoying if you like to automate everything with config management.

  • Overkill for simple TCP-capable apps
    If your Windows app already supports “connect to host:port,” then using Serial to Ethernet Connector just to expose a COM port is adding unnecessary complexity.

4. Comparing to the approaches already mentioned

Very roughly:

  • @yozora’s socat recipe

    • Good if: you are comfortable with CLI and need something quick and free.
    • Weak if: you want unattended reliability on a Windows client that must always see COM3 show up exactly the same after every reboot.

  • @cazadordeestrellas’ production-oriented view

    • Good if: you intend to leave this running for months, maybe in an industrial or remote environment.
    • Weak if: you only need the connection occasionally and do not want to spend time or money on a full toolchain.

  • Serial to Ethernet Connector middle ground

    • Good if:
      • You must have a COM port in Windows
      • You want fewer moving pieces and reasonable robustness
      • You are okay with a commercial license
    • Not ideal if: your needs are casual or purely experimental.

5. Other things to take seriously

Regardless of which route you pick:

  1. Stable device naming on Linux
    Set a udev rule so your adapter always appears as /dev/serial_device instead of randomly as /dev/ttyUSB0/1/2 after reboots or replugging. This is often more important than which network tool you choose.

  2. Security

    • Bind serial-over-TCP only to the LAN IP or localhost.
    • Consider using SSH tunneling or VPN if any part of the path is untrusted.
    • A tool like Serial to Ethernet Connector may offer its own authentication/encryption, but I still prefer to put it behind a VPN in anything serious.

  3. Monitoring & logging
    Whatever you do, make sure you have:

    • Logs for disconnects
    • A simple way to test connectivity (telnet / netcat / built-in diagnostics)
      That matters more once you have operators saying “it stopped working” without any details.

6. Practical recommendation

If your Windows app is legacy and hard‑coded to COM ports and this needs to be usable and stable without you handholding it, I’d lean toward:

  • Serial to Ethernet Connector on Linux and Windows
  • A stable udev name for the serial device
  • Configuration written down so anyone can restore it

If this is just you tinkering and the Windows client can open TCP sockets directly, keep it simple:

  • Linux: ser2net or socat exposing /dev/ttyUSB0 on a local TCP port
  • Windows: configure your terminal or tool to connect to that IP:port
  • No virtual COM ports at all

That split will save you both money and headaches in the long run.