Serial to network and back to serial flow. Should be easy, but I'm struggling

I am trying to use a serial device connected to a Raspberry Pi, an ethernet switch (will eventually be replaced with a satellite network, but not right now), to another Raspberry Pi then to a computer. Here is my setup:

Serial device --> (serial to usb) --> Pi Server --> (ethernet switch) --> Pi Client --> (usb to serial) --> computer reading serial port

I am locked into this setup and my task is to allow serial data to flow back and forth between the computer and the device. Unfortunately my serial device does not send data unless it first receives a command from the computer, which makes it difficult to troubleshoot because the whole chain has to be working.

I know next to nothing about networking but have been reading a ton online and it seems like socat and ser2net will work for my use. However I cannot get the setup to work. Am I on the right track here? Am I missing something? This should be easy, right? I just want to make sure this will theoretically work before I continue banging my head against the wall. Thank you for any advice and tips.

In principle this should work, yes. Things I would recommend:

  • Start with the “computer to Pi Client” part, so you can test immediately. Once you can receive data over the serial connection look at the network part, and so on.
  • Write an application instead of chaining command line tools. I’d probably use Python for this kind of thing, but any language you’re familiar with should work as long as it has suitable network and serial libraries.
  • You said the communication should eventually run over a satellite link instead of inside a lab setup, so consider security from the start. TLS is likely a good way to protect the transferred data, what kind of authentication is suitable depends on who is supposed to access the system under which circumstances.
  • Think about the communication protocol in general. Sure, you could just copy data from serial to network and vice versa, but depending on circumstances being able to transfer additional information might be useful (e.g. error messages or authentication).
1 Like

Awesome, thank you so much for your input and advice. I really appreciate it. With your recommendation of using the computer side to start for easier troubleshooting I was able to get the serial data flowing into the Pi and can view it. I also am using port_publisher.py program (from ser2net page) to pass the serial data to TCP port 7000 and into the other Pi. I think it is working because the ethernet switch lights start flashing when it runs. However I cannot figure out how to view the data that was sent (or just pass it to serial) If you have any recommendations on that I would appreciate it.

I appreciate also your suggestion of writing a program, this will be much easier and less clunky to deal with later. As far as the security protocols go I have a meeting today to learn about the requirements but am just trying to do a “proof of concept” for now over the ethernet switch. I’m sure the security part will be its own beast especially since I have no experience with this. Thank you again.

@malyghost wrote:

I also am using port_publisher.py program (from ser2net page) to pass the serial data to TCP port 7000 and into the other Pi. I think it is working because the ethernet switch lights start flashing when it runs. However I cannot figure out how to view the data that was sent (or just pass it to serial)

Which side is supposed to be client, which server? I suppose it’d make sense to have the server on the second Pi, the one labeled “Pi Server”. If you just want to see data as it arrives look at netcat, with the “-l” option you can start a simple server. The blinking isn’t much of an indication, it could also be caused by failed connection attempts or completely unrelated activity.

Wanting to have a proof of concept before building a secure connection is perfectly valid, but when going from there to a prototype you should already include (or at least plan for) the basics, like a secure connection and possibly authentication. It’s a lot harder (AKA bug-prone) to add that stuff on an otherwise complete system.