How to forward a single TCP connection to multiple serial ports

[jasr93]

Hello @cminyard,

I’m working on an embedded Linux device and using ser2net to expose a serial interface over TCP.

I would like to know if ser2net supports a configuration where a single TCP connection is linked to multiple serial ports simultaneously, with full bidirectional data flow.

Requirements:

Data written to the TCP socket should be sent to both /dev/tty1 and /dev/tty2.

Data received from each serial device should be forwarded back to the same TCP session.

All traffic should flow through one TCP port (e.g., 13001).

The rotator feature doesn’t seem to work here because it selects only one TTY at a time.

Thanks!

[cminyard]

On Tue, Dec 2, 2025 at 8:14 AM jasr93 ***@***.***> wrote: Hello @cminyard <https://github.com/cminyard>, I’m working on an embedded Linux device and using ser2net to expose a serial interface over TCP. I would like to know if ser2net supports a configuration where a single TCP connection is linked to multiple serial ports simultaneously, with full bidirectional data flow.

That's a new request. No, it can't currently do this. It can connect multiple TCP ports to the same serial port, but that's the opposite of what you want. I'm trying to imagine a use case. There would be no way (unless you added a protocol) to tell which serial port data was coming from which serial port. I'm trying to imagine a use case for this, but I've learned people can be pretty imaginative. This would be moderately difficult to add, and there are some challenges. The biggest challenge is: what happens if one of the serial ports flow controls data being written to it? You have two basic options. You can stop the flow of data to both ports, or you can throw data away.

…

-corey

Requirements: Data written to the TCP socket should be sent to both /dev/tty1 and /dev/tty2. Data received from each serial device should be forwarded back to the same TCP session. All traffic should flow through one TCP port (e.g., 13001). The rotator feature doesn’t seem to work here because it selects only one TTY at a time. Thanks! — Reply to this email directly, view it on GitHub <#150>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBPTGGUP3M7LFIU4QE7AXD37WNCHAVCNFSM6AAAAACNZTDY72VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGIYDAMBTGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jasr93]

In my scenario, the TCP client acts as a master controller and both serial ports are connected to devices that should receive the same transmitted messages (as if it were a broadcast message). At the same time, the TCP client needs to receive whatever response comes from either serial port.

The devices are essentially “listeners” that act independently but must receive identical commands, and the controller must collect any data coming from them.

There is no need for the TCP client to know which serial port produced which data because there is a higher level protocol.

Flow-control considerations

I understand the difficulty with hardware/software flow control when one of the serial ports blocks. In my setup:

Occasional buffer overruns or dropped bytes on one port would be acceptable.

The primary requirement is that the TCP connection should continue flowing regardless of whether one serial port becomes temporarily blocked.

So discarding data for a blocking port would actually be acceptable behavior, as long as the TCP session and the other serial port continue working.

[mhei]

Data received from each serial device should be forwarded back to the same TCP session.

Should the data receive on one serial port also be forwarded to the other serial port, or only to the TCP connection?

[jasr93]

Only to the TCP connection

[cminyard]

On Thu, Dec 4, 2025 at 8:05 AM jasr93 ***@***.***> wrote: In my scenario, the TCP client acts as a master controller and both serial ports are connected to devices that should receive the same transmitted messages (as if it were a broadcast message). At the same time, the TCP client needs to receive whatever response comes from either serial port. The devices are essentially “listeners” that act independently but must receive identical commands, and the controller must collect any data coming from them. There is no need for the TCP client to know which serial port produced which data because there is a higher level protocol.

This will only work if you have something that can say only one serial port can transmit at a time or the responses are just a single character. The data can be intermixed on a byte-by-byte basis, so a protocol really isn't going to help. You don't know which byte came from which serial port.

Flow-control considerations I understand the difficulty with hardware/software flow control when one of the serial ports blocks. In my setup: Occasional buffer overruns or dropped bytes on one port would be acceptable. The primary requirement is that the TCP connection should continue flowing regardless of whether one serial port becomes temporarily blocked. So discarding data for a blocking port would actually be acceptable behavior, as long as the TCP session and the other serial port continue working.

Ok, sounds like you have a good grasp on this. This is pretty custom; this is not something that I would just do, and I'm not sure I want to add something this complex with such a narrow use. ser2net can do a lot of things besides talk to serial ports. For instance, you could write a small program that opened two serial ports and did what you wanted to stdio. ser2net could run your program and do the network side of things. If you wanted ser2net to handle the serial port part, too, ser2net could create ptys as accepters and your program would just have to open the two ptys and do the processing. If you want to go that way, I can help a bit with it.

…

Message ID: <cminyard/ser2net/repo-discussions/150/comments/15161461@ github.com>

[jasr93]

Yeah, I totally get that this is a niche use case, so I understand why it wouldn’t make sense to add it directly into ser2net.

Given that ser2net is already based on gensio, do you think it would make sense to implement this intermediary component directly using gensio?

My understanding is that the architecture would be something like this:

Client TCP --->  custom_app  ---> ser2net (PTY1 → serial1)
                             \
                              ---> ser2net (PTY2 → serial2)

Let me know if this seems reasonable or if you see any better way to do it.

[cminyard]

On Fri, Dec 5, 2025 at 7:10 AM jasr93 ***@***.***> wrote: Yeah, I totally get that this is a niche use case, so I understand why it wouldn’t make sense to add it directly into ser2net. Given that ser2net is already based on gensio, do you think it would make sense to implement this intermediary component directly using gensio?

You can, but if you are using ser2net to handle the network and serial I/O, then it's kind of overkill. Unless you need the extra capabilities of ser2net (multiple TCP interfaces, maintenance interface, etc.), if you were going to use gensio, you might as well implement the whole thing in gensio.

My understanding is that the architecture would be something like this: Client TCP ---> custom_app ---> ser2net (PTY1 → serial1) \ ---> ser2net (PTY2 → serial2) Let me know if this seems reasonable or if you see any better way to do it.

I'm assuming "Client TCP" is in ser2net, as I described it. For ser2net, you would have something like (untested): connection: &con1 accepter: tcp,localhost,2000 connector: stdio(noredir-stderr),/path to program/customprogram /tmp/ser1 /tmp/ser2 connection: &ser1 accepter: conacc,pty(link=/tmp/ser1) connector: serialdev,/dev/ttyUSB0,115200n81 connection: &ser2 accepter: conacc,pty(link=/tmp/ser2) connector: serialdev,/dev/ttyUSB1,115200n81 The "conacc" thing is special, it turns a connecting gensio into an accepting gensio. This will create two ptys with links to /tmp/ser1 and /tmp/ser2 (you can, of course, put those where you like). You can connect to them to test them with: gensiot serialdev,/tmp/ser1 If a connection comes in to port 2000, it runs your program with the given parameters. When it runs, stdin and stdout will be connected to the received connection through ser2net. The noredir-stderr thing tells ser2net to not do anything with stdio, so it will go to normal stdout to help you with debugging. You will need to open /tmp/ser1 and /tmp/ser2 and any input from stdin should go to the two serial ports, and any input from a serial port should go to stdout. If you get a close on stdin, then you terminate the program, since that means the socket connection was closed. It might be easier with gensio, it handles all the messiness of dealing with poll() and such, but you would have to learn how to use the gensio library. If you have existing code that deals with poll and file descriptors, then that's probably easier to modify. If you want to use gensio, you would create and open three gensios: stdio(self) which opens your local stdin and stdout and presents it as a gensio. serialdev(/tmp/ser1) serialdev(/tmp/ser2) which handles the ptys. There are some examples to help you. You can do it in C, C++, python (if the gensio python code is installed correctly, which is a bit of a trick) if that's easier, or even go or rust.

…

Message ID: <cminyard/ser2net/repo-discussions/150/comments/15172326@ github.com>

[jasr93]

Thanks, I'll check it out.

One more question. For the con1, can I use another pty instead of stdout as the connector?

[cminyard]

On Fri, Dec 5, 2025 at 11:32 AM jasr93 ***@***.***> wrote: Thanks, I'll check it out. One more question. For the first con1, can I use another pty instead of stdout as the connector?

You can, but you cannot separate out stderr then. stderr will go to the pty the same as stdout. I think for your purposes stdout would be a better choice. The main reason to use pty is to get a normal looking tty device for your program, which you shouldn't need.

…

— Reply to this email directly, view it on GitHub <#150 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBPTGCJMEJ2D6FB52PSSSD4AG6TNAVCNFSM6AAAAACNZTDY72VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJXGUZDCMI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jasr93]

Ok, understood