tcpdump equivalent for the serial port

tcpdump equivalent for the serial port

[Nicolae Mihalache]

Hello!

I'm interested if somebody has any ideea how to write a program that is 
able to sniff the data passing through a serial port the same way 
tcpdump is able to show the data passing through the ethernet cable, 
i.e. without disturbing the application that sends/receives the data.
I've seen few programs that basically work as tunnels opening a 
pseudo-console where the application connects and writing on the other 
side to the serial device. This approach is not very useful because I 
want to be able to start/stop my sniffer without interupting the 
communication and also the application can control different settings of 
the serial port which probably will not be forwarded by the tunnel.

Thanks,
mache

RE: tcpdump equivalent for the serial port

[Mariano Moreyra]

Hi Nicolae,
I think that what you want to do is not posible just with a software.
You have to build a special cable to do that (somebody tell me if I'm wrong,
or if knows another option)
In my job we have one of those cables because we needed to see what was
going on between two applications that talk to each other via serial port.
The bad thing is that you need a third computer that would be the sniffer.


-----Mensaje original-----
De: linux-c-programming-owner@vger.kernel.org
[mailto:linux-c-programming-owner@vger.kernel.org]En nombre de Nicolae
Mihalache
Enviado el: Viernes, 12 de Septiembre de 2003 10:37
Para: linux-c-programming@vger.kernel.org
Asunto: tcpdump equivalent for the serial port


Hello!

I'm interested if somebody has any ideea how to write a program that is
able to sniff the data passing through a serial port the same way
tcpdump is able to show the data passing through the ethernet cable,
i.e. without disturbing the application that sends/receives the data.
I've seen few programs that basically work as tunnels opening a
pseudo-console where the application connects and writing on the other
side to the serial device. This approach is not very useful because I
want to be able to start/stop my sniffer without interupting the
communication and also the application can control different settings of
the serial port which probably will not be forwarded by the tunnel.

Thanks,
mache

-
To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tcpdump equivalent for the serial port

[Nicolae Mihalache]

Mariano Moreyra wrote:

>Hi Nicolae,
>
Hi Mariano!

>I think that what you want to do is not posible just with a software.
>You have to build a special cable to do that (somebody tell me if I'm wrong,
>or if knows another option)
>In my job we have one of those cables because we needed to see what was
>going on between two applications that talk to each other via serial port.
>The bad thing is that you need a third computer that would be the sniffer.
>
The problem is that opening the cable and connecting it to a third port 
may introduce some variations in the signals going over the serial 
cable. This is something that I want to avoid as much as possible. The 
other end of the serial cable is not another computer but a device that 
is itself the subject of development and test so it can not be assumed 
as working nor it can be developed with a non-nominal serial cable 
connected to it. Even worse, my serial link is not RS232 but RS422 which 
has a higher speed and it's more difficult to have break-out capability 
without interferences.
This is why I'm looking for a software solution, i.e. something that 
communicates with the serial driver and gets all the messages that pass 
through it.

Nicolae

Re: tcpdump equivalent for the serial port

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

On Fri, 2003-09-12 15:37:24 +0200, Nicolae Mihalache <mache@abcpages.com>
wrote in message <3F61CC14.20607@abcpages.com>:
> Hello!
> 
> I'm interested if somebody has any ideea how to write a program that 
> is able to sniff the data passing through a serial port the same way 
> tcpdump is able to show the data passing through the ethernet cable, 
> i.e. without disturbing the application that sends/receives the data.
> I've seen few programs that basically work as tunnels opening a 
> pseudo-console where the application connects and writing on the other 
> side to the serial device. This approach is not very useful because I 
> want to be able to start/stop my sniffer without interupting the 
> communication and also the application can control different settings 
> of the serial port which probably will not be forwarded by the tunnel.

Your approach won't work, but I can hint you to another. If you don't
need the *wire states*, but only the data your application receives (or
transmits), then this is easy. Simply use strace or a preload lib to
intercept open, close, read and write.

That way, you don't monitor the serial port itself, but the application
using it. For me, that has always been enough:-)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: tcpdump equivalent for the serial port

[Mariano Moreyra]

I'm using that cable between a PC and a Fiscal Printer, but it's a RS232
link...
We didn't have any problem with signal variations. But I understand that
with an RS422 link you could have more problems.
Wish I could help you, but I don't know how to write a software to do this
kind of sniffing.


-----Mensaje original-----
De: Nicolae Mihalache [mailto:mache@abcpages.com]
Enviado el: Viernes, 12 de Septiembre de 2003 11:02
Para: mariano_moreyra@aca.org.ar; linux-c-programming@vger.kernel.org
Asunto: Re: tcpdump equivalent for the serial port


Mariano Moreyra wrote:

>Hi Nicolae,
>
Hi Mariano!

>I think that what you want to do is not posible just with a software.
>You have to build a special cable to do that (somebody tell me if I'm
wrong,
>or if knows another option)
>In my job we have one of those cables because we needed to see what was
>going on between two applications that talk to each other via serial port.
>The bad thing is that you need a third computer that would be the sniffer.
>
The problem is that opening the cable and connecting it to a third port
may introduce some variations in the signals going over the serial
cable. This is something that I want to avoid as much as possible. The
other end of the serial cable is not another computer but a device that
is itself the subject of development and test so it can not be assumed
as working nor it can be developed with a non-nominal serial cable
connected to it. Even worse, my serial link is not RS232 but RS422 which
has a higher speed and it's more difficult to have break-out capability
without interferences.
This is why I'm looking for a software solution, i.e. something that
communicates with the serial driver and gets all the messages that pass
through it.

Nicolae

Re: tcpdump equivalent for the serial port

[Nicolae Mihalache]

Jan-Benedict Glaw wrote:

>
>Your approach won't work, but I can hint you to another. If you don't
>need the *wire states*, but only the data your application receives (or
>transmits), then this is easy. Simply use strace or a preload lib to
>intercept open, close, read and write.
>
>That way, you don't monitor the serial port itself, but the application
>using it. For me, that has always been enough:-)
>
This seems a good ideea. Probably I will not use exactly strace but 
develop something using the same library it uses.
I will still keep the cable break-out solution as an option but 
definitely I wanted to be able to monitor the data without interfering 
with the electic signaling on the cable.

Thanks a lot!
nicolae

Re: tcpdump equivalent for the serial port

[Jamie Le Tual]

I would probably try to see if I could alter the kernel serial port 
driver,  there may even be an API in the driver for what you want. 
That's where I would start.

Peace,
Jamie

Nicolae Mihalache wrote:

> Hello!
>
> I'm interested if somebody has any ideea how to write a program that 
> is able to sniff the data passing through a serial port the same way 
> tcpdump is able to show the data passing through the ethernet cable, 
> i.e. without disturbing the application that sends/receives the data.
> I've seen few programs that basically work as tunnels opening a 
> pseudo-console where the application connects and writing on the other 
> side to the serial device. This approach is not very useful because I 
> want to be able to start/stop my sniffer without interupting the 
> communication and also the application can control different settings 
> of the serial port which probably will not be forwarded by the tunnel.
>
> Thanks,
> mache
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> .
>

Re: tcpdump equivalent for the serial port

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Fri, 2003-09-12 16:23:32 +0200, Nicolae Mihalache <mache@abcpages.com>
wrote in message <3F61D6E4.2050604@abcpages.com>:
> Jan-Benedict Glaw wrote:
> >That way, you don't monitor the serial port itself, but the 
> >application
> >using it. For me, that has always been enough:-)
> >
> This seems a good ideea. Probably I will not use exactly strace but 
> develop something using the same library it uses.

There isn't really a library involved. strace is basically a hugh
wrapper around the ptrace() system call.

> I will still keep the cable break-out solution as an option but 
> definitely I wanted to be able to monitor the data without interfering 
> with the electic signaling on the cable.

Then you most probably want to go the preload lib way. That is, you
build a small lib containing open(), close(), read() and write() which
you call the original program with:

$ LD_PRELOAD=/path/to/your/lib.so ./serial_app

The lib needs to call the libc routines, of course. You can do this by
dlopen()ing libc (RTLD_NEXT) and get the original function (pointer)
from it (by calling dlsym()).

This way, you get access to all parameters (you're able to get the
open()ed file name, compare it to /dev/ttyS.*) and save the resultin fd
from the libc open() call.

On upcoming read()s and write()s, you simply always compare the supplied
fd with the initial fd() from the open() call to a serial device. It's
really that easy:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: tcpdump equivalent for the serial port

[Nicolae Mihalache]

Jan-Benedict Glaw wrote:

>On Fri, 2003-09-12 16:23:32 +0200, Nicolae Mihalache <mache@abcpages.com>
>wrote in message <3F61D6E4.2050604@abcpages.com>:
>  
>
>>Jan-Benedict Glaw wrote:
>>    
>>
>>>That way, you don't monitor the serial port itself, but the 
>>>application
>>>using it. For me, that has always been enough:-)
>>>
>>>      
>>>
>>This seems a good ideea. Probably I will not use exactly strace but 
>>develop something using the same library it uses.
>>    
>>
>
>  
>
Hello again,

Now that I'm thinking better, this approach is not similar with tcpdump 
because if I monitor the application that reads the data, I won't see it 
until it is actualy read. The idea of my sniffer is to debug the device 
that runs on the other side so it would be interesting to display 
something as soon as it arrives rather than waiting till the application 
reads the data.
I will try to see if there is some support provided in the kernel.

Thanks,
nicolae