Монитор ком порта линукс

Содержание

How can I monitor serial port traffic?
10 Answers 10
This is the way I finally choose
Федоренко на связи

How can I monitor serial port traffic?

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?

10 Answers 10

socat is a tool to connect (nearly) everything to (nearly) everything, and tee can duplicate streams.
In your usecase 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.

The socat syntax looks confusing at first, but in fact, it’s just 2 nested statements.
A small price to pay to such a powerful, versatile tool.
If you need to setup 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)

@peterh-ReinstateMonica What do you need to proxy the ioctl calls for? If it’s just changing the baudrate, try stty -F /dev/ttyS0 19200 . Technically, it should be possible by intercepting the system call using LD_PRELOAD, same as padsp .

@alex-stragies: I like socat , but the syntax is just too cumbersome. For this simple problem, I found the interceptty solution posted below to be much simpler: interceptty /dev/ttyS0 is all you need to create a PTY called /tmp/interceptty that can then be used by any program as a serial port.

@hackerb9 As of 03/2020, interceptty is not in debian package management, not even testing , so -for me and some others- not a viable solution for many situations. And the syntax is only cumbersome the first 5-8 times 😉

Fair enough. I also tend to stick with software that’s been vetted by Debian. Interceptty, despite the author disappearing, seems to be well written. A simple ./configure && make && sudo make install worked for me.

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

strace will tell you if it tried to send characters to the port, and what the kernel responded with when it tried. depending on your flow control settings characters may arrive at the disconnected TXD pin or may not.

This works, but is an overkill in the sense that it’ll monitor accesses to all files instead of the single /dev/tty* we’re interested in.

This got me going in the direction I needed. I have a hardware widget with a serial interface that I can only find an ancient Windows-32 app to control, and I was looking to monitor all of it’s traffic while running under wine to try and reverse-engineer it in hopes of making a new library. I found that adding the -P option limits strace to only my device, and I also needed -f to watch the child/fork processes: strace -o wine.strace -f -s 9999 -x -P /dev/ttyUSB0 wine start ‘c:/Program Files (x86)/mydir/myapp.exe’

I found projects called Linux Serial Sniffer, jpnevulator, and Moni. 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.

thanks for that !! i will give it a try. by the way i solved the issue from my java side. i was missing a \r, so that prevented my message from writing on to the port. thanks for that anyways!!

The «LInux Serial Sniffer» is buggy, it absolutely takes out incoming data, thus another application which is actually listen to serial see nothing. But, at least, the data that goes outside seems to go without problem.

From the jpnevulator FAQ: «Jpnevulator was never built to sit in between the kernel and your application.»

-1 because of 3 comments: LInux Serial Sniffer is buggy, then Jpnevulator was never built to sit in between kernel and app and finaly Moni is dead. This answer just point to 3 externals links and don’t give a real solution. (3 fail on 3 link, left nothing!)

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 .

I had to download it (using wget since clicking on the .tar.gz file seemed to corrupt it somehow), install gcc and make , then run ./configure and make install . Does exactly what the OP and I want though.

Worked great on Debian GNU/Linux. Was able to intercept a Windows program (running in Wine) with a simple ln -s /tmp/interceptty ~/.wine/dosdevices/com5 . Excellent answer.

This is the way I finally choose

strace -s 9999 -e read -ffp $(sed '/ttyUSB0/s/^.*proc.\(7\+\).fd.*/\1/p;d' <(ls -l /proc/4*/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; >;>;'

#!/bin/bash strace -s 9999 -e read -ffp $( sed "/tty$/s/^.*proc.\(4\+\).fd.*/\1/p;d" <( ls -l /proc/2*/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/3*/fd/* | grep ttyUSB0 instead of lsof ttyUSB0 because I seen them sometime slow.
So strace will trace current program using ttyUSB0
Syntax: tty$ 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.

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

screen /dev/tty.usbserial-blahblah 9600

This opens the port and assumes control over it, so nothing else can use it. This does not «monitor» or «sniff» the traffic.

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

OP wrote «monitor», but meant «sniffer» ( = is able to read traffic in transit), while minicom is a serial port «client», and as such is not an answer to this question. The answer below from mike made the same mistake, and the comment there explains the terminology problem as well.

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

It doesn’t. It is written in python, and the code does import some import pcopy , which is even Google gave up to find.

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:

The first socat command sets up a bidirectional pipe between the first address ( /dev/ttyUSB0 ) and second (the SYSTEM command).
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] .
[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.
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.

Источник

Федоренко на связи

В этой заметке я расскажу про то, как можно проверить COM порт в Linux.

Для этого нам понадобятся:

права на чтение и запись в COM порт
программа minicom
кусок толстого многожильного кабеля

Права доступа

проверяем какие у нас в системе есть COM порты, а также наши права на них:

# ls -l /dev/ttyS* /dev/ttyUSB*
crw-rw—- 1 root dialout 4 , 64 Дек 21 11 : 46 / dev / ttyS0
crw-rw—- 1 root dialout 4 , 65 Дек 8 15 : 43 / dev / ttyS1
crw-rw—- 1 root dialout 4 , 66 Дек 8 15 : 43 / dev / ttyS2
crw-rw—- 1 root dialout 4 , 67 Дек 8 15 : 43 / dev / ttyS3
crw-rw—- 1 root dialout 188 , 0 Дек 21 07: 27 / dev / ttyUSB0

/dev/ttyS0 это первый COM порт
/dev/ttyS1 соответственно второй COM порт
/dev/ttyUSB0 специальный кабель-переходник из USB в COM (Gembird UAS111)

Как мы видим для работы с COM портом необходимы права root либо пользователь должен входить в группу dialout

Провод для связи

Берём многожильный кабель в оплётке длиной 4-6 см, и соединяем 2 и 3 выводы COM порта перемычкой из этого кусочка провода. Оплётка будет удерживать провод на контактах, а металлические жилы внутри будут проводниками.
Для любителей паять можно предложить спаять полный loop-back тестер. В нём соединить не только контакты приёма передачи, но и аппаратный контроль потока и готовность терминала.

Работа с программой minicom

Для начала необходимо настроить программу minicom

Выбираем «Настройка последовательного порта»

Если нужно, меняем СОМ порт, нажимая «A»
Отключаем аппаратное управление потоком, нажимая «F»
Выходим из настроек «Enter»
Сохраняем настройки по умолчанию «Сохранить настройки как dfl»
Выходим из minicom

Собственно проверка СОМ порта

Запускаем minicom без параметров.

Пробуем нажимать на клавиши. В ответ на экране должны появляться символы.
Проверка COM порта под linux завершена.

Эта запись была сделана 21.12.2010, 13:50 под рубрикой Разное. Вы можете подписаться на эту запись с помощью RSS 2.0. Both comments and pings are currently closed.

Источник