Initialization Packet in Serial Communication?!

Initialization Packet in Serial Communication?!

[Daniel Kreischer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey guys,

we are trying to make a small embedded sensor device (Crossbow's TelosB mote)[1] talk to a SmartCard reader
via a serial connection.
To do so, we checked which packets are being sent by a open source linux driver to the reader and successfully
replicated the behaviour manually with cutecom[2].
We then implemented a stripped down version of the driver on the mote, but when we attach the reader to it, it
won't answer to the commands sent by the mote.

We recognized a kind of initialization packet received by cutecom and even cat everytime we open a connection:
	00 00 80 00 00 00 80 00 80 80 80 80 80 80 80 80 80 80 80
        80 00 80 80 80 00 00 80 00 00 00 00 80 00 00 80 00 00

We don't seem to receive that packet when connecting the reader to the mote, though.
Connecting the mote via a null modem cable to the PC and imitating the reader's responses with cutecom does
work, so the driver on the mote is ok.

We have already debugged the 8250.c serial kernel driver with printk()s before every outb() and inb() to the
UART's registers and started writing a miniature user space driver to find out what causes the packet, but we
can't exactly replicate the behaviour manually, yet.

The question is: Does anybody of you know what that packet is about, and what triggers it?

Thanks for your help
Daniel



[1] http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/TelosB_Datasheet.pdf
[2] http://cutecom.sourceforge.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSDWKok5eU1rRPXMNAQjXJw//fqsHKntQv9aVyHUF5WSuyE3ZhLHhT6qK
NoOVSJRqFr7iml7sQV/dvLJt3ZWlfWGlhV+N2i3Gg8zGVMrqtwdjV+CwE9tfTRUR
d6EmU17VIAb6Qa0WhSlIb6Ttns6kZwRihSVBK9CoiqAWp9J/dg1RH3Bvc9ZBJ9u2
WEtarWa6PA0zlb9VQ67sgcv640fpGGR910K5EDNEW2TXz2Mm+xXEId5cI0eWlUle
iURG13U9gzjKB2cAPXzTTLy+y+FoLeUHo7N1tUPzQXLkhSzEMWk7uD+4zTeKALC0
pJznBR7lF5lNk+XQLXJq4vHUETwLgs0wR5mptPBIuH/tGWyRrwtrbxp9c52fEbqh
3WZio5w9PdhsZTvDo1Q0zy3QDc/bPIrF2+6cJg+Q/dCjS2grKr5FtYuj9jyd61QU
2Bzvp5Ll1jPX3j1LAIYUKf/Vod9cyGMJPIm/qBdeAl/I/EugS7OolcLVbOnz5g/m
lfMeYj3IBG4UeU0IJ1Quv3l4T+FZTz4yFHS/d/e/y9GpTTSiaT6h3taamJWaAvqS
4EyJx6ekLQBzgqTwGbhAPZMuDRUGJsbdQO3dbdNsOEvpGPyN7XL2vvRpISQyYOC9
zGkyURDHFJPaObX/rVUZLk3PeYaKiJX5xc+PB+m6zyHH8e4B1GLrUylaRp/27DO+
6HahuHOW2jo=
=3lL/
-----END PGP SIGNATURE-----

Re: Initialization Packet in Serial Communication?!

[Paul Fulghum]

Daniel Kreischer wrote:
> we are trying to make a small embedded sensor device (Crossbow's TelosB mote)[1] talk to a SmartCard reader
> via a serial connection.
> To do so, we checked which packets are being sent by a open source linux driver to the reader and successfully
> replicated the behaviour manually with cutecom[2].
> We then implemented a stripped down version of the driver on the mote, but when we attach the reader to it, it
> won't answer to the commands sent by the mote.
> 
> We recognized a kind of initialization packet received by cutecom and even cat everytime we open a connection:
> 	00 00 80 00 00 00 80 00 80 80 80 80 80 80 80 80 80 80 80
>         80 00 80 80 80 00 00 80 00 00 00 00 80 00 00 80 00 00
> 
> We don't seem to receive that packet when connecting the reader to the mote, though.
> Connecting the mote via a null modem cable to the PC and imitating the reader's responses with cutecom does
> work, so the driver on the mote is ok.
> 
> We have already debugged the 8250.c serial kernel driver with printk()s before every outb() and inb() to the
> UART's registers and started writing a miniature user space driver to find out what causes the packet, but we
> can't exactly replicate the behaviour manually, yet.
> 
> The question is: Does anybody of you know what that packet is about, and what triggers it?

If I understand you correctly, the card reader sends this
init packet when connected to cutecom running on Linux
but not when connected to mote?

I don't know the meaning of that packet, but if it is
sent by the reader when a connection is open but no
data has been sent then the card reader is probably
responding to a UART control signal (DTR or RTS) which is
asserted when the tty device is opened.

If the mote does not drive or assert these signals then
the card reader may ignore data sent by the mote.
I would verify that the control signals from the mote
are the same state as the control signals from the Linux box.

-- 
Paul Fulghum
Microgate Systems, Ltd.