0

I'm using socat to route serial input over a network to allow me to control an Arduino device over a virtual COM port setup.

My command to start socat is:

socat /dev/serial0,b500000,raw,echo=0 TCP-LISTEN:9876,nodelay,fork&

This works the first time a device connects to the :9876 port perfectly fine. However, if the connection is dropped from the other end (which is using com2tcp on Windows), any further connections will send serial up the network to the RasPi hosting socat and out the serial device, but data will not be received in from /dev/serial0. I have to kill the original socat process, wait for the port to be released, and then re-run socat. Given the RasPi operates headless, this is an annoyance I'd rather avoid.

Is there any way to allow multiple, non-simultaneous connections to work in this manner? I'm assuming there's some sort of setting to put in after the echo=0, but I can't figure out which one.

(Further notes: the 500000 baud rate is required, as this is the rate required for the software I'm using, called GIMX. The purpose of this setup is to allow me to connect to a game console with devices in another room, using the remote play functionality to play the game. I have this command set in /etc/rc.local to start socat on boot, as the RasPi is also used as a media player using Volumio; this is simply running in the background.)


EDIT: I ended up abandoning the socat/com2tcp route, and implementing an RFC2247-compliant connection. This meant that I didn't have to worry about manually setting the baud rate as necessary, and seems to work in a more stable manner to boot. I based it on the information from https://robosavvy.com/forum/viewtopic.php?t=7578 which basically gives a full overview of setting it up. Although a couple of the links are dead, it has the information needed to get a connection going.

I believe the command I was looking for was "end-close", however I did not test this before having committed to the new setup.

  • The version installed from the distro repository of socat was outdated (v1.7.2.4, while the current source version is v1.7.3.4). Have built from source, and will test again in the next day or two. – redion1992 Jan 13 at 16:42
0

On a local network you probably want to use UDP instead of TCP. You will get a better latency and the connection issue will probably vanish. A quick search leads to a program called COM2UDP.

| improve this answer | |
  • Yes, UDP would be a better design option due to its non-handshaking nature. The issue here is not with the connection - it works. Once. Then when I close it from the remote PC, I can’t fire it up again. As you may have guessed, I’m working on the COM port tunnelling as a way around getting FFB translation over the network. Having looked at the source, I see there’s no easy way to add it in, and it would be a much greater load over WAN transmissions, hence why I didn’t request it being added. (For those who don’t know, matlo is the creator of the GIMX software mentioned in the OP.) – redion1992 Jan 13 at 16:06
  • This is definitely a connection issue since second connection fails. The way the first connection is closed on client/com2tcp side probably leaves the socket on server/socat side in a stale state, and the first connection is probably still pending/closing. This is a bare guess, you can easily diagnose the problem using wireshark. – matlo Jan 14 at 13:32
  • I feel I may have found a switch that I was looking for - "end-close", when applied to the TCP connection, will only close the handle in the fork when the connection terminates, while leaving it open for further traffic. I can't confirm this, however, see my edit on the original question. – redion1992 Jan 17 at 14:31
  • Since the next GIMX version will change the baudrate dynamically, I am planning to add a "proxy" mode to make this use-case easier. – matlo Jan 29 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.