Documentation

Remote serial port: RS-232 and USB-serial over IP, virtual COM port

Serial over IP is a need as old as industry itself: the maintenance console, the instrument, the test bench is over there, and the tool that must talk to it is here. The market answers with serial-to-Ethernet converter hardware or COM port redirection software. Virtual-IO, the remote serial feature of VIGIL-MESH, builds that extension into the private network itself: the machine that owns the port shares it, and authorized machines mount a virtual COM port (Windows) or a pty (Linux) — end-to-end encrypted, with no extra hardware.

The need: talking to a serial port that is not in the room

RS-232 and its descendants have not disappeared: they have dug in where they are irreplaceable. Four situations come up constantly.

The maintenance console

UPS, switch, PLC, drive: the vendor’s diagnostic interface is a serial port, and the equipment sits on another site.

The sensor or instrument

Scale, measurement unit, analyzer, GPS: the instrument streams its frames over a serial link, and the acquisition software runs somewhere else.

The test bench

The board under validation exposes its serial output on the bench, in the workshop — and the team debugging it works remotely.

The legacy equipment

The machine is thirty years old, its control software only knows COM1 through COM9, and no “network” version exists. Nobody will replace it over that.

The classic answer: a serial-to-Ethernet converter (Moxa NPort, Perle IOLAN, Digi PortServer…) installed next to the equipment, plus COM redirection software on the client workstation, plus a network path between the two — site VPN, port forwarding, or worse. It works, but it means one box to buy and maintain per port, one network setup per site, and encryption that depends on the model. Virtual-IO removes the hardware layer and the network-path question: remote serial is a function of the mesh, protected by its end-to-end encryption.

DemonstratedHow it works: one provider, several consumers

The machine that owns the physical port — the provider — shares a device path: /dev/ttyUSB0 on Linux, COM3 on Windows. Authorized machines — the consumers — then mount a local virtual port, which their applications open like any serial port.

Role	Platform	What the machine sees
Provider	Windows or Linux	Its usual physical port (`COM3`, `/dev/ttyUSB0`…); its device path is what gets shared.
Consumer	Linux	A pseudo-terminal `/dev/ttyVIGIL-<name>`, usable by any software that can open a serial port.
Consumer	Windows	A real COM port, created by the “VIGIL Mesh Virtual Serial Port” driver (UMDF 2, user mode): visible to Device Manager and to the oldest vendor tools.

The transport is latency-first: bytes leave in records of at most 4 KiB, with no aggregation timer that would delay a short frame. A 32 KiB credit window protects the device on the provider side; on the consumer side, a 64 KiB receive queue absorbs bursts — on overflow, lost bytes are counted and the application is never blocked. Everything travels end-to-end encrypted inside the mesh session: relays see nothing. After an outage, the session reconnects automatically and the configuration survives.

The access model separates reading from writing: the stream received from the device is fanned out to every reader (up to 8 attachments per share), but only one machine writes at a time — exclusive write, the others get “writer busy”. Several people can watch the same console while a single one types.

Step-by-step setup, from the console

Everything is configured in the web console, in a network’s Virtual-IO tab — there is no CLI. And everything is off by default: nothing is shared until an operator creates a share.

1
Enroll the machines involvedThe provider (the machine with the port) and each consumer must be machines of the network — see enrolling a machine.
2
Open the network's Virtual-IO tabIn the console, pick the network then the Virtual-IO tab: it lists existing shares and lets you create one.
3
Create the shareGive it a name, pick the provider machine, enter the device path (/dev/ttyUSB0, COM3…), then the serial parameters: baud rate, parity, flow control.
4
Assign rights, machine by machineFor each machine of the network: none, read or read-write. Access is decided machine by machine — no whole-subnet grants.
5
SaveThe controller pushes the configuration to the nodes involved; it survives reboots and outages.
6
Open the port on the consumerOn Linux, the share appears as /dev/ttyVIGIL-<name>; on Windows, a COM port is created by the driver shipped with the client installer. Your tools open it like a local port.

Machines page of the VIGIL-MESH console: the list of enrolled machines of the network, each with its name and status. — Prerequisite for sharing: the provider and the consumers appear in the network's machine list.

# The share "bench" appears as a pseudo-terminal
screen /dev/ttyVIGIL-bench 115200
# or: minicom -D /dev/ttyVIGIL-bench -b 115200

Real case: the instrument is 500 miles away, the tool only speaks COM

An analyzer installed on a site 500 miles away exposes its configuration and diagnostics on an RS-232 port. The vendor’s tool — a Windows executable from another era — can only open a local COM port: no TCP, no network option, nothing.

The classic options all carry a cost: ship and install a serial-to-Ethernet converter and then build it a network path (site VPN, port forwarding…); remote-control a PC on site and hope one sits near the instrument; or send someone over with a laptop.

Serial parameters and supported signals

Parameter	Supported values
Baud rate	115,200 by default; accepted by the configuration up to 4,000,000
Parity	None, even, odd
Flow control	None, hardware RTS/CTS, software XON/XOFF
Frame format	8 data bits, 1 stop bit (the UI's setting)
Modem signals	DTR, RTS, CTS, DSR, CD, RI propagated between consumer and provider (RFC 2217-style semantics)
Break	Propagated

Limits and beta status

Virtual-IO is included in the product; plans and quotas are detailed on the pricing page.

Frequently asked questions

Do I need a serial-to-Ethernet converter (Moxa, Perle, Digi)?

No. The machine that owns the physical port shares its device path directly (/dev/ttyUSB0, COM3…). No box to buy, power or manage: the serial extension is part of the VIGIL-MESH network, with its encryption and its per-machine access rights.

Do USB-serial adapters work?

Yes. Virtual-IO shares a device path, not a specific controller: a native RS-232 port or a USB-serial adapter (FTDI, CP210x, CH340…) are shared the same way.

How many machines can read the same port?

Up to 8 simultaneous attachments per share: the stream received from the device is fanned out to every reader. Writing, however, is exclusive — one machine writes at a time, the others get a “writer busy” answer while the write side is taken.

Is the serial stream encrypted?

Yes, end to end inside the mesh session, like all VIGIL-MESH traffic: any relay on the path carries opaque packets and never sees the content of the serial link.

What happens if the Internet connection drops?

The session reconnects automatically and the share's configuration survives the outage. If data arrives faster than it is consumed, the 64 KiB receive queue overflows while counting the lost bytes — the application is never blocked.