ELX-Serial

One serial device, several network clients

A bridge between a TCP port and a serial port on Linux. One process holds one device — a built-in port, a USB adapter, a pseudo-terminal — and hands it to several network clients at once. There is no protocol on top of the socket: bytes cross in both directions exactly as they are.

v1.6 LinuxARM Free

Coming soon Documentation

Several clients, one line

A serial port can be opened by one program at a time. This bridge opens it once and lets several network clients talk through it, which is the difference between one tool at a time and a monitoring system running alongside your terminal.

Bytes, unchanged

Nothing is framed, escaped, buffered into lines or interpreted. Whatever arrives on the socket goes to the device, and whatever the device says goes back — so any protocol works, including one nobody has documented.

A watchdog that reopens the port

With polling enabled, a line that has gone quiet is probed; three missed answers and the port is closed and reopened with its settings reapplied. About twenty seconds from silence to a working port again, without anybody being on site.

Small enough for any board

Written in C with nothing but the compiler and libc required. The primary target is a 32-bit ARM single-board machine; amd64 and arm64 work equally well.

Built to run for months

There is no state the program cannot recover from on its own and no wait without a timeout. It is meant to be installed on a machine nobody logs into again.

Listen, or dial out

Normally it listens on a TCP port. It can instead connect outward to a machine you name — which is how a device behind a router reaches a server rather than waiting to be reached.

What it is for

The original use was a building-automation controller on /dev/ttyS1 that had to be reachable over the network on port 1824 — by the automation software, by a diagnostic tool and by whoever was investigating a fault, at the same time.

Reaching a serial device from another machine, or from several.
Keeping a monitoring tool connected while an engineer works with the same device.
Putting an old RS-232 instrument on the network without buying a hardware device server.
Exposing a pseudo-terminal so that a program expecting a serial port talks to something across the network.

Command line

Usage

elxserial [options] device

Option	Meaning
`-p port`	TCP port; 23000 by default
`-s "settings"`	Port settings in stty style, for example `"115200 raw"`
`-k seconds`	Watchdog poll interval; 0, the default, disables it
`-m number`	Maximum simultaneous clients; 4 by default
`-r host`	Act as a client: connect outward instead of listening
`-l name`	For `/dev/ptmx`: create a symlink to the slave side
`-w`	Write only; incompatible with the watchdog
`-x level`	Debug output: 0, 1 or 2

A real invocation

elxserial -m 5 -p 1824 -s "115200 raw" -k 60 /dev/ttyS1

How the watchdog behaves

The point of the watchdog is a port that stops working without anything reporting an error — a converter that has locked up, a driver that has lost the device. Nothing fails; data simply stops arriving.

One poll goes out immediately at start-up, so a port that is dead from the first second is found at once rather than a minute later.
After that a poll is sent whenever nothing has arrived from the device for the configured interval. While a client is actively talking, the line is busy and no poll is sent — it cannot interrupt somebody else's transaction.
The answer is awaited for two seconds. A miss is retried after five.
Three misses in a row close and reopen the port, reapply the settings and resume polling. About twenty seconds pass between the line going silent and the port being new again.

Why the reply is recognisableEach poll carries an identifier that changes every time, and the controller returns it unchanged. A late answer to the previous poll therefore cannot be mistaken for an answer to the current one. A packet is treated as the bridge's own only if the delimiter, version, flag, identifier, declared length, command and checksum all agree — and such a packet is removed from the stream, so network clients never see the housekeeping traffic.

A reply that matches in every field but carries an error flag still proves the controller is alive: it is logged as a warning and the port is left alone.

At a glance

Operating system: Linux
Architectures: armhf (primary), arm64, amd64, x86
Windows: Not supported
Written in: C — compiler and libc only
Default port: 23000
Default client limit: 4
Devices: Built-in ports, USB adapters, /dev/ptmx
Service: Runs under systemd

Frequently asked questions

Is there a build for Windows?

No. The program is built around POSIX terminal handling and the way Linux exposes serial devices; a Windows version would be a different program rather than a port.

What happens when two clients send at the same time?

Both streams reach the device, because the bridge does not arbitrate a protocol it knows nothing about. If your protocol cannot tolerate that, let one client write and the others only listen — the write-only option and read-only clients exist for exactly this.

Do I need root?

Not to build it. To open the device you need access to it, which usually means membership of the dialout group rather than root.

Can it connect outward instead of listening?

Yes. Point it at a machine and it dials out, which is how a device behind a router without a public address reaches a central server.

Does the watchdog interfere with my protocol?

No. It polls only when the line has been quiet, and it removes its own replies from the stream before clients see them.

ELX-Serial

One serial device, several network clients

Coming soon

Nearby programs

ELX-MQTT Broker A complete MQTT broker with a live web dashboard v1.0.39 ELX-MODBUS A bridge between the Modbus bus and an MQTT broker v1.2.38 ELX-Terminal A terminal for COM ports, raw TCP and TCP through an SSH tunnel v1.0.0