linux howto - fabio de lorenzo personal informations and experiences

[serial_sniffer]

interessante !!!:
http://nst.sourceforge.net/nst/docs/user/ch11s02.html


Monitoring Session - Using Basic Linux Utility Programs
Prev Chapter 11. Serial Traffic Monitoring Next
Monitoring Session - Using Basic Linux Utility Programs

I will now demonstrate a serial monitoring session using the custom Serial Tap Cable. The setup environment consists of a NST Probe desktop system connected to a Magellan Color GPS device on serial port: "/dev/ttyS0". See Figure: 2. I used the terminal emulation program: "Minicom" for serial communication to the GPS. The discussion that follows shows various monitoring techniques that can be used with standard Linux utility programs.

After connecting the cable, you can use utility programs cat and hexdump to start viewing results:

In this example the DTE Serial Tap (NST Probe) is connected to serial device: /dev/ttyS1 and the DCE Serial Tap (Magellan Color GPS) is connected to serial device: /dev/ttyUSB0.

First we need to setup serial communication parameters on devices: /dev/ttyS0 and /dev/ttyUSB0. Note that these serial devices need to be put in "raw" mode with an 8 bit character length ("cs8") in order for a binary capture to occur. We do not want any character translations occurring. If even or odd parity is required, use the parenb and [-]parodd control setting where appropriate.

** Note: I have found that it is best to zero out all stty parameters and settings prior to starting a capture on a serial device. With USB serial converters this is necessary or a Kernel Panic will occur when the serial device is closed out. This is a known bug in the USBserial Kernel Module for Kernel Version: 2.4.20-20.9. This should be fixed in Kernel Version: 2.4.23.

A NST utility program reset_serial was written to reset a serial device's communication parameters and settings. It uses the stty readable format. This format consist of 36 zeroes delimitied by a colon ":"


[root@probe tmp]# /bin/stty -F /dev/ttyUSB0 \
0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Now lets initialize the serial devices for capturing serial traffic at: 4800N81.


[root@probe tmp]# /usr/local/bin/reset_serial /dev/ttyS1
[root@probe tmp]# /usr/local/bin/reset_serial /dev/ttyUSB0
[root@probe tmp]# /bin/stty -F /dev/ttyS1 speed 4800 raw cs8
[root@probe tmp]# /bin/stty -F /dev/ttyUSB0 speed 4800 raw cs8

Print out current communication parameter settings for devices: /dev/ttyS1 and /dev/ttyUSB0:


[root@probe tmp]# /bin/stty -a -F /dev/ttyS1
speed 4800 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>;
eof = <undef>; eol = <undef>; eol2 = <undef>; start = <undef>;
stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>;
lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb -cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl
-noflsh -xcase -tostop -echoprt -echoctl -echoke

[root@probe tmp]# /bin/stty -g -F /dev/ttyS1
0:0:3c:0:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

[root@probe tmp]# /bin/stty -a -F /dev/ttyUSB0
speed 4800 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>;
eof = <undef>; eol = <undef>; eol2 = <undef>; start = <undef>;
stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>;
lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb -cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl
-noflsh -xcase -tostop -echoprt -echoctl -echoke

[root@probe tmp]# /bin/stty -g -F /dev/ttyUSB0
0:0:3c:0:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Now start your capture on device: /dev/ttyS1


[root@probe tmp]# cat < /dev/ttyS1 >| /tmp/nema_cmd_version_request.txt

Now start your capture on device: /dev/ttyUSB0


[root@probe tmp]# cat < /dev/ttyUSB0 >| /tmp/nema_cmd_version_response.txt

We will issue a Magellan private command to get the version of the GPS device as our example for this monitoring session. The command is: "$PMGNCMD,VERSION*28\r\n". The command is now sent within the Minicom session.

View the actual serial data sent to the GPS device:


[root@probe tmp]# hexdump -C nema_cmd_version_request.txt
00000000 24 50 4d 47 4e 43 4d 44 2c 56 45 52 53 49 4f 4e |$PMGNCMD,VERSION|
00000010 2a 32 38 0d 0a |*28..|
00000015

The reason I initially could not get my GPS device to respond was that Minicom program does not append a needed Linefeed (Newline - 0x0d) character to the data sent out the serial port when the Enter Key is pressed. I determined this from analyzing the above serial traffic data. As you can see from the syntax of the Magellan Version Command above, the transmission protocol for Magellan GPS devices is very strict and a Carriage Return/Linefeed termination sequence is required for all commands sent to the GPS device. In order to send out a Linefeed character from the Minicom program, a "Ctrl-j" key sequence needs to be typed. Once I did this the version command executed properly.

View the actual serial data received from the GPS device:


[root@probe tmp]# hexdump -C nema_cmd_version_response.txt
00000000 24 50 4d 47 4e 56 45 52 2c 30 33 39 2c 56 45 52 |$PMGNVER,039,VER|
00000010 20 34 20 30 32 2c 4d 65 72 69 64 69 61 6e 20 43 | 4 02,Meridian C|
00000020 6f 6c 6f 72 2a 37 38 0d 0a |olor*78..|
00000029

Prev Up Next
Chapter 11. Serial Traffic Monitoring Home Monitoring Session - Using NST Utility Program: "monitor_serial"

[sniffatore fino]

A way to sniff the serial traffic is hacking the serial kernel module.

So you have 2 pre-requisities:

a) compile the kernel serial drivers as module
b) have a compiled and working kernel sources

What I did is:
in file: serial_core.c
in function: uart_write(struct tty_struct *tty, const unsigned char * buf, int count)
...
if (!circ->buf) return 0;

// my code
if (count > 0) {
int fdl_i;
//char temp_buff[count*3 + 6 ];
char *temp_buff;
temp_buff = kmalloc( (count*3 + 6) , GFP_KERNEL);
sprintf(temp_buff,"\n-(%d)-> ", count );
for (fdl_i=0;fdl_i<count;fdl_i++) sprintf( (temp_buff+fdl_i+ 8 ) ,"%x ",buf[fdl_i] );
printk( "%s", temp_buff );
kfree(temp_buff);
}
....

in the file: 8250.c
in fuction: static _INLINE_ void
receive_chars(struct uart_8250_port *up, int *status, struct pt_regs *regs)

...
ch = serial_inp(up, UART_RX);
flag = TTY_NORMAL;
up->port.icount.rx++;
// my code
printk (" <-( %x)",(unsigned char) ch );

#ifdef CONFIG_SERIAL_8250_CONSOLE
/*
* Recover the break flag from console xmit
*/
...



after that, compile both modules, than remove precedent modules:
rmmod 8250; sleep 1 ; rmmod serial_core

load new modules:
insmod ./serial_core.ko;
insmod ./8250.ko

That's all:
you'll get all the traffic via dmesg