remove the former description of the dialog boxes, which is pretty useless as the dialogs should be (or improved to be) self explaining.

explain the messages in the packet list and packet details (e.g. [Malformed Packet])

svn path=/trunk/; revision=16918

1 files changed, 88 insertions, 21 deletions

diff --git a/docbook/eug_src/EUG_app_messages.xml b/docbook/eug_src/EUG_app_messages.xml
index 602d867a29..752014864b 100644
--- a/docbook/eug_src/EUG_app_messages.xml
+++ b/docbook/eug_src/EUG_app_messages.xml
@@ -2,33 +2,100 @@
 <!-- $Id$ -->
 
 <appendix id="AppMessages">
-  <title>Ethereal Warnings and Messages</title>
-  <section>
-    <title>Capture file format not understood</title>
-    <para>
-      If <application>Ethereal</application> cannot decode the capture 
-      file format of the file you have asked it to load, you will receive 
-      a warning box similar to that shown in <xref linkend="AppErr01"/>.
-	<figure id="AppErr01">
-	  <title>Read File Format warning</title>
-	  <graphic entityref="EtherealFormatError" format="PNG"/>
-	</figure>
+  <title>Ethereal Messages</title>
+  <para>
+  Ethereal provides you with additional information generated out of 
+  the plain packet data or it may need to indicate dissection problems.
+  Messages generated by Ethereal 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>
+	    Ethereal 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 Ethereal 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>Save file error</title>
+  <section><title>[Packet size limited during capture]</title>
     <para>
-      If <application>Ethereal</application> cannot open the file you 
-      requested it to save captured packets in, you will receive a 
-      warning box similar to that shown in <xref linkend="AppErr02"/>.
-	<figure id="AppErr02"><title>Save Error warning</title>
-	  <graphic scale="60" entityref="EtherealSaveError" format="JPG"/>
-	</figure>
+	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>
 
-  <!-- Simply add more sections above here ... -->
+  <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 EUG Appendix Messages -->