forked from osmocom/wireshark
102 lines
3.5 KiB
XML
102 lines
3.5 KiB
XML
<!-- WSUG Appendix Messages -->
|
|
<!-- $Id$ -->
|
|
|
|
<appendix id="AppMessages">
|
|
<title>Wireshark Messages</title>
|
|
<para>
|
|
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 [] parentheses.
|
|
</para>
|
|
<section id="AppMessagesList"><title>Packet List Messages</title>
|
|
<para>
|
|
These messages might appear in the packet list.
|
|
</para>
|
|
<section><title>[Malformed Packet]</title>
|
|
<para>
|
|
Malformed packet means that the protocol dissector can't work out the
|
|
contents of the packet any further. This can have various reasons:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<command>Wrong dissector</command>
|
|
Wireshark errorneously has chosen the wrong protocol dissector for
|
|
this packet. This will happen e.g. if you are using a protocol
|
|
not on it's well known TCP or UDP port. You may try Analyze|Decode As
|
|
to circumvent this problem.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Packet not reassembled</command>
|
|
The packet is longer than a single frame and it is not reassembled,
|
|
see <xref linkend="ChAdvReassemblySection"/> for further details.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Packet is malformed</command>
|
|
The packet is actually wrong (malformed), meaning that a part of the
|
|
packet is just not as expected (not following the protocol
|
|
specifications).
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<command>Dissector is buggy</command>
|
|
The corresponding protocol dissector is simply buggy or still
|
|
incomplete.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
Any of the above is possible. You'll have to look into the specific
|
|
situation to determine what it is.
|
|
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 reveil a dissector bug. Or you
|
|
could find out that the packet is indeed wrong.
|
|
</para>
|
|
</section>
|
|
<section><title>[Packet size limited during capture]</title>
|
|
<para>
|
|
The packet size was limited during capture, see "Limit each packet to n
|
|
bytes" at the <xref linkend="ChCapCaptureOptions"/>.
|
|
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.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="AppMessagesDetails"><title>Packet Details Messages</title>
|
|
<para>
|
|
These messages might appear in the packet details.
|
|
</para>
|
|
<section><title>[Response in frame: 123]</title>
|
|
<para>
|
|
The current packet is the request of a detected request/response pair.
|
|
You can directly jump to the corresponding response packet just
|
|
by double clicking on this message.
|
|
</para>
|
|
</section>
|
|
<section><title>[Request in frame: 123]</title>
|
|
<para>
|
|
Same as "Response in frame: 123" above, but the other way round.
|
|
</para>
|
|
</section>
|
|
<section><title>[Time from request: 0.123 seconds]</title>
|
|
<para>
|
|
The time between the request and the response packets.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
</appendix>
|
|
<!-- End of WSUG Appendix Messages -->
|