How can I monitor serial port traffic?

Question

Is there any port monitoring tool to watch the packets written on the port? I especially want to check if my program written in Java works so I need some kind of tool to see if my little application is writing the messages to the port. How do I do this?

Answer 1

socat is a tool to connect (nearly) everything to (nearly) everything, and tee can duplicate streams.  In your use case you could connect your serial port /dev/ttyS0 to a PTY /tmp/ttyV0, then point your application to the PTY, and have socat tee out Input and Output somewhere for you to observe.

Googling "socat serial port pty tee debug" will point you to several "standard procedure" examples, one being:

socat  /dev/ttyS0,raw,echo=0  \
    SYSTEM:'tee in.txt | socat - "PTY,link=/tmp/ttyV0,raw,echo=0,waitslave" | tee out.txt'

The files in.txt and out.txt will then contain the captured data.

Updated after comments:

• The socat syntax looks confusing at first, but in fact, it's just two nested statements.
  A small price to pay to such a powerful, versatile tool.
• If you need to set up your serial port, or send other ioctls, do so before calling socat, as socat cannot proxy them.
• The single-purpose-tool interceptty from 2006 has slightly simpler syntax, but can only intercept TTYs (while proxying ioctls), and is probably not in your package manager.  (Most Linux distros never added it to their repos.)

Answer 2

I don't think the serial driver has any tracing functionality that would allow you to watch packets. You can use strace to observe all the reads and writes from your application:

strace -s9999 -o myapp.strace -eread,write,ioctl ./myapp

Answer 3

I found projects called Linux Serial Sniffer, jpnevulator, and Moni(Edit: Updated Link). The first two look like they do exactly what you want. The last one calls itself a monitor, but it actually looks like a standard serial communication program.

Answer 4

interceptty does that job:

interceptty /dev/ttyACM0 /dev/ttyDUMMY

or, with a nice output format and with configuring the backend device, and with line buffering:

interceptty -s 'ispeed 19200 ospeed 19200' -l /dev/ttyACM0 /dev/ttyDUMMY | interceptty-nicedump

and then connect with your programme to /dev/ttyDUMMY.

Answer 5

This is the way I finally choose

Thanks to Gilles's answer!

strace -s 9999 -e read -ffp $(sed '/ttyUSB0/s/^.*proc.\([0-9]\+\).fd.*/\1/p;d' <(ls -l /proc/[1-9]*/fd/* 2>/dev/null)) |& perl -e '$|=1;my %qa=(a=>7,b=>10,e=>33,f=>14,n=>12,r=>15,t=>11);sub cnv { my $ch=$_[0];$ch=$qa{$1} if $ch=~/([abefnrt])/;return chr(oct($ch));  };while (<>) { /^read.\d+,\s+"(.*)",\s\d+.*$/ && do { $_=$1;s/\\(\d+|[abefnrt])/cnv($1)/eg;print; };};'

Sorry, I will explain...

#!/bin/bash

strace -s 9999 -e read -ffp $(
    sed "/tty${1:-USB0}/s/^.*proc.\([0-9]\+\).fd.*/\1/p;d" <(
        ls -l /proc/[1-9]*/fd/* 2>/dev/null
    )
) 2>&1 |
    perl -e '
        $|=1;
        my %qa=(a=>7,b=>10,e=>33,f=>14,n=>12,r=>15,t=>11);
        sub cnv {
            my $ch=$_[0];
            $ch=$qa{$1} if $ch=~/([abefnrt])/;
            return chr(oct($ch));
        };
        while (<>) {
            /^read.\d+,\s+"(.*)",\s\d+.*$/ && do {
                $_=$1;
                s/\\(\d+|[abefnrt])/cnv($1)/eg;
                print;
            };
        };
    '

• I use ls -l /proc/[0-9]*/fd/* | grep ttyUSB0 instead of lsof ttyUSB0 because I seen them sometime slow.
• So strace will trace current program using ttyUSB0
• Syntax: tty${1:-USB0} will permit, used as a script or function, to run them with serial device name as argument: ttySniff USB0 or ttySniff S0 and so on.
• Perl script will unbackslash strings logged by strace -s 9999.
• You could replace strace -e read by strace -e read,write or strace -e write depending on your need.

Note: I run them by using syntax:

 script -t ttySniff.log 2>ttySniff.tm -c "./ttySniff.sh USB0"

so I could replay the whole operation and trace timing executions.

Answer 6

When I debug interaction of my application with a serial port, I use moserial.

Answer 7

Try this:

screen /dev/tty.usbserial-blahblah 9600

works for me.

Answer 8

minicom is missing from the list of tools to monitor serial ports. Use it as for example to listen to arduino device:

minicom --device /dev/ttyACM0 --baud 9600

Answer 9

Have a look at ttyUSBSpy. It is on alpha stage, but it works.

Answer 10

There are many answers and approaches to this that each have different properties. A common one is using socat, like the answer Alex gave above that's also discussed in this blog post.

However, if you'd prefer creating a separate device that's just a read-only version of the original device like myself - say, so that you can open minicom on the read-only device and let other software interact with the read-write device normally - I just came up with the following that works nicely.

socat /dev/ttyUSB0,rawer SYSTEM:'tee >(socat - "PTY,link=/tmp/foobar-ro,rawer" >%-) | socat - "PTY,link=/tmp/foobar-rw,rawer,wait-slave"'

That's complicated, so I'll break it down a bit. Logically it's this:

socat /dev/ttyUSB3,rawer SYSTEM:'tee [READ-ONLY PTY] | [READ-WRITE PTY]'

And it works roughly like so:

1. The first socat command sets up a bidirectional pipe between the first address (/dev/ttyUSB0) and second (the SYSTEM command).
2. Inside the SYSTEM command now, tee duplicates its stdin (i.e. the output of /dev/ttyUSB0) to both [READ-ONLY PTY] and to its own stdout, which we then pipe to [READ-WRITE PTY].
3. [READ-ONLY PTY] is created with a 2nd socat command where the first address is - (shorthand for socat's STDIO address type) and the second is a new PTY. We also make sure to close this 2nd socat command's stdout with >%-; this is what makes it read-only.
   • For a reason I don't quite understand, unless the 2nd socat's stdout is closed, tee seems to include the output from the process substitution in its own output. I'm not sure why tee would be reading from its arguments at all.
4. Finally, [READ-WRITE PTY] is created with a 3rd socat command similar to the 2nd. This 3rd socat's stdout becomes the output of the SYSTEM address in the 1st socat and is fed to the original device's input, completing the loop.