Converting serial port data to TCP/IP in a Linux environment

Question

I need to get data from the serial port of a Linux system and convert it to TCP/IP to send to a server. Is this difficult to do? I have some basic programming experience, but not much experience with Linux. Is there an open source application that do this?

Answer 1

You don't need to write a program to do this in Linux. Just pipe the serial port through netcat:

netcat www.example.com port </dev/ttyS0 >/dev/ttyS0

Just replace the address and port information. Also, you may be using a different serial port (i.e. change the /dev/ttyS0 part). You can use the stty or setserial commands to change the parameters of the serial port (baud rate, parity, stop bits, etc.).

Answer 2

I stumbled upon this question via a Google search for a very similar one (using the serial port on a server from a Linux client over TCP/IP), so, even though this is not an answer to exact original question, some of the code might be useful to the original poster, I think:

• Making a Linux box with a serial port listen on the TCP port to share the modem: ser2net
• Using this "shared" modem from another Linux workstation: remtty

Answer 3

You can create a serial-over-LAN (SOL) connection by using socat. It can be used to 'forward' a ttyS to another machine so it appears as a local one or you can access it via a TCP/IP port.

Answer 4

All the tools you would need are already available to you on most modern distributions of Linux.

As several have pointed out you can pipe the serial data through netcat. However you would need to relaunch a new instance each time there is a connection. In order to have this persist between connections you can create a xinetd service using the following configuration:

service testservice
{
    port        = 5900
    socket_type = stream
    protocol    = tcp
    wait        = yes
    user        = root
    server      = /usr/bin/netcat
    server_args = "-l 5900 < /dev/ttyS0"
}

Be sure to change the /dev/ttyS0 to match the serial device you are attempting to interface with.

Answer 5

Open a port in your server with netcat and start listening:

nc -lvp port number

And on the machine you are reading the serial port, send it with netcat as root:

nc <IP address> portnumber < /dev/ttyACM0

If you want to store the data on the server you can redirect the data to a text file.

First create a file where you are saving the data:

touch data.txt

And then start saving data

nc -lvp port number > data.txt

Answer 6

I had the same problem.

I'm not quite sure about open source applications, but I have tested command line Serial over Ethernet for Linux and... it works for me.

Also thanks to Judge Maygarden for the instructions.

Answer 7

I have been struggling with the problem for a few days now.

The problem for me originated with VirtualBox/Ubuntu. I have lots of USB serial ports on my machine. When I tried to assign one of them to the VM it clobbered all of them - i.e. the host and other VMs were no longer able to use their USB serial devices.

My solution is to set up a stand-alone serial server on a netbook I happen to have in the closet.

I tried ser2net and it worked to put the serial port on the wire, but remtty did not work. I need to get the port as a tty on the VM.

socat worked perfectly.

There are good instructions here:

Example for remote tty (tty over TCP) using socat

Answer 8

I think your question isn't quite clear. There are several answers here on how to catch the data coming into a Linux's serial port, but perhaps your problem is the other way around?

If you need to catch the data coming out of a Linux's serial port and send it to a server, there are several little hardware gizmos that can do this, starting with the simple serial print server such as this Lantronix gizmo.

No, I'm not affiliated with Lantronix in any way.

Answer 9

You might find Perl or Python useful to get data from the serial port. To send data to the server, the solution could be easy if the server is (let's say) an HTTP application or even a popular database. The solution would be not so easy if it is some custom/proprietary TCP application.