This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Thanks in advance for the help! I am new to using wireshark and am struggling to use it in my particular application.

I have a desktop PC that communicates to a controller, which sends commands to a robot. I'm trying to understand the communication between the PC and the controller. I'm attempting to use the setup below to monitor the communications. I'm capturing the packets on my laptop using USBPcap and viewing them using Wireshark.

alt text

When I capture while sending a few commands from the PC to the controller to move the robot, I recieve packets like in the image below. Numbers 1-618 occur every time the USB is plugged in, so numbers 619-621 contain the communication between the PC and the controller. And this is where I am stuck. Is the process I am using to monitor communication correct? How do I interpret this information? I'm concerned something is wrong with my process since I received the message "Malformed Packet".

alt text

Thanks!

asked 16 Nov '16, 09:58

moelleea's gravatar image

moelleea
6112
accept rate: 0%

Assuming that the communication from the PC to the Controller is RS232, why don't you capture the comms traffic on the PC?

And what is the OS on the PC?

(16 Nov '16, 10:32) grahamb ♦

Assuming that, for whatever reason, you cannot capture the serial traffic using a software running on the desktop PC as @grahamb suggests, the way you took is still quite complex.

Whatever method you use to capture the data, the first thing to do when analysing serial communication is to identify the data speed and format on the wire. Of course it is best if you know them in advance, but if you don't, an oscilloscope is your best friend, as it can show you whether the communication is "asynchronous" (most likely if one of the ends is a standard serial port of a standard PC) or "synchronous" if some kind of specialized adaptor is used, what is the duration of a single bit on the line (which is the inverse of the transmission speed, 10 bits per second mean that a single bit is present on the line for 0.1 second).

For standard serial adaptors, possible speeds are 50, 100, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, or even faster with newer hardware. So the inverse value of the bit duration measured (quite inaccurately) using the oscilloscope should be close to one of these. If asynchronous mode is used and the signal is not modulated onto any carrier, the line is at the same voltage level (stop bit, i.e. logical 1) if no transmission is ongoing, so you need a memorizing oscilloscope.

Next, for an asynchronous communication, you have to determine

  • how many data bits are used (5 to 8 are typical values),
  • whether a parity bit is used, and if it is, whether it is odd or even,
  • how many stop bits are used (1, 1.5 and 2 are typical values).

For synchronous communication, the task would be more complex as in such case, the boundaries of individual bytes are not marked as clearly as in the asynchronous case (using start bit and stop bit(s)) but either some kind of bit oriented protocol like HDLC is used or some multi-byte synchronisation pattern is occasionally present in the data stream.

Knowing all the above, you can set the serial adaptor you use to monitor accordingly. Then, you can use some own software to read the incoming data from that port and dump them in hex and ASCII for further analysis. If there is a gap longer than one byte time, this may indicate a message boundary, so you may want to print a newline and a timestamp before printing the first byte after the gap, so you'd get something like

10:00:03.20 41=A 62=b 63=c
10:00:04.15 43=C 30=0 35=5 FE=.
10:00:07.11 41=A 63=c 65=e

If you want to use Wireshark's ability to dump USB communication, you have to understand how the serial to USB adaptor packs the data into the bulk transfer. I'm afraid that no dissector capable of extracting the serial data from communication of the serial-to-USB adaptor with its driver exists so you would have to write it yourself.

If you insist on going that way, I'd recommend you to do the following:

  • disconnect the RS-232 side of the USB to serial adaptor from the monitored cable and the USB side of it from the PC
  • connect pins 2 and 3 on the RS-232 connector of the adaptor
  • start capturing
  • insert the USB end of the USB to serial adaptor back to the PC
  • configure the serial port representing the adaptor for "no handshake" and for some speed, parity, number of stop bits etc.
  • connect a text terminal software to the serial port and type some string like "hello world", you should see it echoed
  • stop the capture.

In the capture, you should see the enumeration phase, including the vendor and product id, which you would later use to tell Wireshark to use your dissector to dissect USB bulk transfers of this vendor and product. You should also see in the bulk transfers' payload substrings of what you typed on the terminal. The substrings may be as small as a single character or they may be longer; they may be even encoded in some unexpected way so you won't be able to match the bulk transfer payload to what you wrote at all.

Your own dissector, if properly registered for the vendor and product id, would then receive the bulk data from Wireshark for analysis, and it would be up to you how you would reassemble them into some logical units. A typical behaviour of Wireshark dissectors is that if a protocol data unit (PDU) is spread across several frames of a transport protocol, the complete reassembled PDU is added to the dissection tree of the last one of the transport frames carrying it.

So after writing your dissector, Wireshark would show you about the same as suggested above - chunks of bytes with timestamps.

permanent link

answered 17 Nov '16, 00:31

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×24

question asked: 16 Nov '16, 09:58

question was seen: 2,238 times

last updated: 17 Nov '16, 00:31

p​o​w​e​r​e​d by O​S​Q​A