Watching serial port activity.

[xkenneth]

Hi,

I'm writing a couple python applications that use the serial port
(RS-232) quite extensively. Is there any way I can monitor all activity
on the serial port and have it printed as the transactions occur? I'm
trying to reverse engineer a microcontroller serial routine and I'd
like to see any response the chip sends back.

Regards,
Ken

 

[Grant Edwards]

I'm writing a couple python applications that use the serial port
(RS-232) quite extensively. Is there any way I can monitor all activity
on the serial port and have it printed as the transactions occur? I'm
trying to reverse engineer a microcontroller serial routine and I'd
like to see any response the chip sends back.

What OS?

Under windows you can use portmon from sysinternals.

I don't think there's anything for Linux.

I've noclue about OS X.

 

[xkenneth]

I'm using linux.

 

[Grant Edwards]

I'm using linux.

[It's generally considered good practice to quote enough context
so that your post makes sense to people without access to older
postings.]

Under Linux there isn't really anything. IIRC, many years ago,
somebody had written a kernel module that inserted itself
between application and serial port and logged operations, but
the last time I tried to find it, I was unsuccessful.

If you feel like building a kernel, adding a few printk() calls
to either the low-level serial driver or the tty
line-discipline layer might do what you want.

 

[TheSeeker]

Hi,

Have you looked into slsnif
(http://www.dakotacom.net/~ymg/software.html)

Duane

 

[Peter Corlett]

Under Linux there isn't really anything. IIRC, many years ago, somebody
had written a kernel module that inserted itself between application and
serial port and logged operations, but the last time I tried to find it, I
was unsuccessful.

A dirty hack that might work is to rename /dev/ttyS* off somewhere else and
replace them with named pipes. Have a process monitor the named pipes and
relay data back and forth to the actual serial ports while logging it. The
serial ioctls won't work to the named pipe, but the application might not
notice it failed.

But this is probably way too advanced for the OP.

 

[Grant Edwards]

Have you looked into slsnif
(http://www.dakotacom.net/~ymg/software.html)

FYI, slsnif won't work for any serial program that needs to use
parity, 7 data bits, or any of the modem control/status lines.

Since all of the serial applications I use need to use actual
serial ports, I've never found slsnif to be useful. It's
really a shame that pty devices don't support the same set of
ioctl calls that tty devices do.

 

[Grant Edwards]

A dirty hack that might work is to rename /dev/ttyS* off somewhere else and
replace them with named pipes. Have a process monitor the named pipes and
relay data back and forth to the actual serial ports while logging it. The
serial ioctls won't work to the named pipe, but the application might not
notice it failed.

If so, then that would be one pretty crappy application.

The slsnif program uses a pty so it will support at least some
of the ioctl calls that a serial port does.

 

[Cameron Laird]

I'm using linux.

[It's generally considered good practice to quote enough context
so that your post makes sense to people without access to older
postings.]

Under Linux there isn't really anything. IIRC, many years ago,
somebody had written a kernel module that inserted itself
between application and serial port and logged operations, but
the last time I tried to find it, I was unsuccessful.

If you feel like building a kernel, adding a few printk() calls
to either the low-level serial driver or the tty
line-discipline layer might do what you want.

.
.
.
!? I hadn't realized there's no such monitor ... What do you
think of <URL: http://wiki.tcl.tk/moni >?

 

[Cameron Laird]

.
.
.
!? I hadn't realized there's no such monitor ... What do you
think of <URL: http://wiki.tcl.tk/moni >?

Ugh. Please ignore, all; this was a first draft of
what was intended for private e-mail. It escaped
the corral through a mistake. I apologize for the
distraction.

 

[Grant Edwards]

.
.
.
!? I hadn't realized there's no such monitor ... What do you
think of <URL: http://wiki.tcl.tk/moni >?

It's yet another a terminal program (written in TCL).

_If_ the pty device didn't force parity=None and bits=8, and
_if_ it implemented the modem control/status ioctl() calls, and
_if_ it went through the line discipline layer like a real
serial port does, then something like slsnif would be workable
for "real" serial port applications.

In a more general sense, it would mean you could actually
simulate a serial port with user-space code. That allows you
to do cool stuff like create virtual serial ports in user-space
that are connected via Ethernet to physical (or virtual) serial
ports on other hosts. [OK, I admit there are only a few of us
who think that's a cool thing to do.]

Currently, if you want to create a virtual serial port under
Linux you have to write a kernel-mode device driver. The only
practical way to do that is to write a virtual "low level"
serial driver that uses the line-discipline layer in the normal
manner. And that's a real bitch to maintain because the API
between the line-discipline layer and the driver you've just
written is constantly changing (it seems to get major overhauls
even between minor versions of a "stable" kernel).

Someday I'll write a pty driver that actually allows simulation
of a serial port...

 

[nikie]

Hi,

I'm writing a couple python applications that use the serial port
(RS-232) quite extensively. Is there any way I can monitor all activity
on the serial port and have it printed as the transactions occur? I'm
trying to reverse engineer a microcontroller serial routine and I'd
like to see any response the chip sends back.

I've done similar things in the past, and the best tools I found at
that time were:
- Serial Port sniffer from www.hhdsoftware.com
Similar to portmon, but (in my experience) more stable. Windows only,
though.
- VMWare
You can run your serial port app in a VMWare and connect the virtual
serial port to a file or named pipe on the host system. But this won't
help you if the app uses serial commands not available for files/pipes.
- Hardware cable
If you know how to use a soldering iron, this might be the best way: a
serial cable has an RX and a TX wire, connect each of them to the RX
wires of two separate serial cables, that way you can "wiretap" the
whole communication to two different serial ports (e.g. on your laptop)
in a running system. Dead useful for debugging!

 

[nikie]

Hi,

I'm writing a couple python applications that use the serial port
(RS-232) quite extensively. Is there any way I can monitor all activity
on the serial port and have it printed as the transactions occur? I'm
trying to reverse engineer a microcontroller serial routine and I'd
like to see any response the chip sends back.

I've done similar things in the past, and the best tools I found at
that time were:
- Serial Port sniffer from www.hhdsoftware.com
Similar to portmon, but (in my experience) more stable. Windows only,
though.
- VMWare
You can run your serial port app in a VMWare and connect the virtual
serial port to a file or named pipe on the host system. But this won't
help you if the app uses serial commands not available for files/pipes.
- Hardware cable
If you know how to use a soldering iron, this might be the best way: a
serial cable has an RX and a TX wire, connect each of them to the RX
wires of two separate serial cables, that way you can "wiretap" the
whole communication to two different serial ports (e.g. on your laptop)
in a running system. Dead useful for debugging!

 

[Sergei Organov]

FYI, slsnif won't work for any serial program that needs to use
parity, 7 data bits, or any of the modem control/status lines.

Since all of the serial applications I use need to use actual
serial ports, I've never found slsnif to be useful. It's
really a shame that pty devices don't support the same set of
ioctl calls that tty devices do.

It seems that sniff on a real tty device could be implemented using the
same technique strace uses to intercept and show syscalls, though I'm
not aware of any sniffer application that does it.

 

[Grant Edwards]

It seems that sniff on a real tty device could be implemented using the
same technique strace uses to intercept and show syscalls, though I'm
not aware of any sniffer application that does it.

Using strace you can indeed trace read/write calls on
user-specified file descriptors. Figuring out which file
descriptors to trace is the tricky part.

 

[Sergei Organov]

Using strace you can indeed trace read/write calls on user-specified
file descriptors.

I've actually meant to take strace in source code and modify it for
particular purpose. The fact that it almost can do it in unmodified form
is quite impressive though.

Figuring out which file descriptors to trace is the tricky part.

Provided I have port name, say, /dev/ttyM0, and have running application:

osv@osv ~$ fuser /dev/ttyM0
/dev/ttyM0: 5134
osv@osv ~$ ls -l /proc/5134/fd | grep /dev/ttyM0
lrwx------ 1 osv osv 64 2006-05-29 15:33 8 -> /dev/ttyM0
osv@osv ~$

so I need to track fd #8 of the process with pid 5134. Guess one can
attach to a running process as gdb does it.

Alternatively, if the process to be sniffed sporadically opens/closes
the port at run-time, it is required to track open()/close() syscalls as
well as read()/write() ones, I think. Overall, seems not that trivial
but doable.