why are ascii characters used in serial sniffers ?

[labium]

portsniffer.GIF (11.29 KiB) Viewed 4826 times

i saw some portsniffer results on plugwise on the web, but why are ascii characters used and not the hex or byte representation ?

labium

[Digit]

Because they can have a special meaning. STX=Start of text, ETX= End of text, LF=Line Feed etcetera.
Some people prefer to see LF instead of 0A.
I know that sniffer, you can turn it off if you want to.
Kind of depends on what you're sniffin' ...

[labium]

i have a little selfmade "sniffer" on a fez spider board , to make a bridge between a usb serial port attached to computer and on the otherside a usbhost to a plugwise stick . this with an attempt to attach the plugwise stick to a serial port on the computer and not to a usb port, this to able to attach it to a serial server. the sniffer part is to debug the fez spider board over the extra cdc serial port with debugging. plugwise wont make a serial counterpart of their usb stick.

when it works i can very easy replace the usb serial port with a real serial port

I compared my results with that of mister damen to see if it works and i noticed his sniffer uses ascii characters i have simple bytes.

labium

[roheve]

i saw some portsniffer results on plugwise on the web, but why are ascii characters used and not the hex or byte representation ?

labium

Because ASCII is what the device ´talks´. Most PlugwiseDevice messages are ASCII coded Hexadecimal digits. Also the relevant protocol mesages are between a start marker and an end marker. That way it is easier to find the relevant messages for the receiver.

Plugwise also sends some other messages, but they seem not relevant for the software, more debugging hints... You could switch the sniffer to all HEX output where each byte is coded into two hex digits, but that makes it more difficult to see what is going on, as the device talks mostly ´readable` ASCII.

Here a small example of the raw code the sniffer outputs...

Code: Select all

83  20:37:28  PlugwisePC.exe  IRP_MJ_WRITE  VCP0  Length 14: ....000AB43C..
88  20:37:28  PlugwisePC.exe  IRP_MJ_READ  VCP0  Length 83
88  20:37:28  SUCCESS  Length 83: ....0000000100C1FEED......00110001000D6F0000B835CB01018A0D6F0000B1B64B3B8AFF75CC...
90  20:37:28  PlugwisePC.exe  IRP_MJ_WRITE  VCP0  Length 30: ....0023000D6F0000B835CB5C5C..
94  20:37:28  PlugwisePC.exe  IRP_MJ_READ  VCP0  Length 47
94  20:37:28  SUCCESS  Length 47: ....0000000200C1103F......00240002000D6F0000B83

Where an ASCII is not 'printable' you see a dot ( '.') and other messages from the capture process.

Here an example of some other messages in the stream

Code: Select all

390  20:37:39  PlugwisePC.exe  IRP_MJ_READ  VCP0  Length 36
390  20:37:39  SUCCESS  Length 36: ....0000001C00C1E248..# APSRequestNo
394  20:37:39  PlugwisePC.exe  IRP_MJ_READ  VCP0  Length 96
394  20:37:39  SUCCESS  Length 96: deInfo: Source MAC: 000D6F0000B835CB# APSRequestNodeInfo: Destination MAC: ..000D6F0000AF65AA...

Here a debug message`# APSRequestNodeInfo: Source MAC: 000D6F0000B835CB` is in the stream (and another one `#APSRequestNodeInfo: Destination MAC: ..000D6F0000AF65AA...`)
What bytes are send for the dot´s is unknown in this capture.

Roelof

[labium]

thank you for your replies, it is clear to mee now.

labium