On Sat, Jan 13, 2024 at 08:36:57AM +0100, to...@tuxteam.de wrote: > On Sat, Jan 13, 2024 at 01:20:46AM +0000, phoebus phoebus wrote: > > While 'ser2net' may be a valuable tool for certain purposes, it doesn't > > align with our specific requirements. Nevertheless, I'm grateful for the > > insight and knowledge you've shared. > > to me it's difficult to follow the discussion. Perhaps it is > because traditionally, in UNIX, the TTY functionality and > terminal emulators s are separated entities, whereas in the > DOS/Windows world both functionalities are often conflated. > > Have you had a look at minicom?
The real problem here is that we're all blind men trying to grasp the elephant. Every time someone offers a suggestion, the OP responds with "No, that won't work, because..." and reveals another piece of the elephant. Unfortunately, at no time has the OP ever defined the entire problem. Here's what I've managed to piece together: 1) The OP currently has a working solution using proprietary software under Microsoft Windows, but would like an open source solution. 2) The problem involves at least four distinct pieces of equipment: * A server, accessed by telnet or by ssh (preferred). * A client PC, which accesses the server over the network. * A "printer" which is connected to the PC by serial(?) port. * Another device, not named, which is connected to the "printer" by some unnamed method. 3) Apparently, the client PC is supposed to initiate a connection to the server, to run some interactive application. 4) At some point, the application will initiate a communication session to the "printer" and to the "other device" THROUGH the "printer", all tunneled THROUGH the telnet or ssh session using "bidirectional passthrough printing". 5) This "bidirectional passthrough printing" (which I've never heard of) apparently allows the server application to perform data transfers between itself and the "other device", all while perhaps printing literal ink-on-paper on the "printer", all while still allowing the interactive application to run seamlessly on the client PC. I have dealt with terminals with passthrough printers before, but it was three decades ago, and I've certainly never heard of a printer communicating *back* to the host over this channel, let alone a printer having some other devices hanging off of it. (This makes me think the "printer" is not actually what we'd call a printer, but of course we haven't been told any of the details.)