Appendix A. Wireshark Messages

Table of Contents

A.1. Packet List Messages
A.1.1. [Malformed Packet]
A.1.2. [Packet size limited during capture]
A.2. Packet Details Messages
A.2.1. [Response in frame: 123]
A.2.2. [Request in frame: 123]
A.2.3. [Time from request: 0.123 seconds]
A.2.4. [Stream setup by PROTOCOL (frame 123)]

Wireshark provides you with additional information generated out of the plain packet data or it may need to indicate dissection problems. Messages generated by Wireshark are usually placed in square brackets (“[]”).

A.1. Packet List Messages

These messages might appear in the packet list.

A.1.1. [Malformed Packet]

Malformed packet means that the protocol dissector can’t dissect the contents of the packet any further. There can be various reasons:

  • Wrong dissector: Wireshark erroneously has chosen the wrong protocol dissector for this packet. This will happen e.g. if you are using a protocol not on its well known TCP or UDP port. You may try Analyze|Decode As to circumvent this problem.
  • Packet not reassembled: The packet is longer than a single frame and it is not reassembled, see Section 7.7, “Packet Reassembly” for further details.
  • Packet is malformed: The packet is actually wrong (malformed), meaning that a part of the packet is just not as expected (not following the protocol specifications).
  • Dissector is buggy: The corresponding protocol dissector is simply buggy or still incomplete.

Any of the above is possible. You’ll have to look into the specific situation to determine the reason. You could disable the dissector by disabling the protocol on the Analyze menu and check how Wireshark displays the packet then. You could (if it’s TCP) enable reassembly for TCP and the specific dissector (if possible) in the Edit|Preferences menu. You could check the packet contents yourself by reading the packet bytes and comparing it to the protocol specification. This could reveal a dissector bug. Or you could find out that the packet is indeed wrong.

A.1.2. [Packet size limited during capture]

The packet size was limited during capture, see “Limit each packet to n bytes” at the Section 4.5, “The “Capture Options” dialog box”. While dissecting, the current protocol dissector was simply running out of packet bytes and had to give up. There’s nothing else you can do now, except to repeat the whole capture process again with a higher (or no) packet size limitation.