from Julian Onions: add more about protocol dissection to the developer's guide
authorulfl <ulfl@f5534014-38df-0310-8fa8-9805f1628bb7>
Thu, 9 Jun 2005 22:46:41 +0000 (22:46 +0000)
committerulfl <ulfl@f5534014-38df-0310-8fa8-9805f1628bb7>
Thu, 9 Jun 2005 22:46:41 +0000 (22:46 +0000)
git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@14604 f5534014-38df-0310-8fa8-9805f1628bb7

docbook/edg_src/EDG_chapter_dissection.xml

index d13f4742b49e730c9cb496a60cdcab31f96f29ac..ee2503a7ae30c4b9ed3d759f44dde005da45f8c5 100644 (file)
@@ -3,7 +3,7 @@
 \r
 <chapter id="ChapterDissection">\r
   <title>Packet dissection</title>\r
-  \r
+  <!-- Julian Onions additions -->\r
   <section id="ChDissectWorks">\r
        <title>How it works</title>\r
        <para>\r
@@ -116,7 +116,7 @@ plugin_reg_handoff(void){
        <para>\r
        Next we have an int that is initialised to -1 that records our protocol.\r
        This will get updated when we register this plugin with the main program.\r
-       We can use this as a handy way to detect if we've been initalised yet.\r
+       We can use this as a handy way to detect if we've been initialised yet.\r
        Its good practice to make all variables and functions that aren't exported\r
        static to keep name space pollution. Normally this isn't a problem unless your\r
        dissector gets so big it has to span multiple files.\r
@@ -135,7 +135,7 @@ plugin_reg_handoff(void){
        </para>\r
        <para>\r
        The plugin_reg_handoff routine is used when dissecting sub protocols. As our\r
-       hyperthetical protocol will be hyperthetically carried over UDP then we will\r
+       hypothetical protocol will be hypothetically carried over UDP then we will\r
        need to do this.\r
        </para>\r
        <para>\r
@@ -187,7 +187,7 @@ proto_reg_handoff_foo(void)
 }]]>   \r
    </programlisting></example>\r
        <para>\r
-       Whats happening here? We are initialising the dissector if it hasn't\r
+       What's happening here? We are initialising the dissector if it hasn't\r
        been initialised yet. \r
        First we create the dissector. This registers a routine \r
        to be called to do the actual dissecting.\r
@@ -195,7 +195,7 @@ proto_reg_handoff_foo(void)
        so that the main program will know to call us when it gets UDP traffic on that port.\r
        </para>\r
        <para>\r
-       Now at last we finaly get to write some dissecting code. For the moment we'll\r
+       Now at last we finally get to write some dissecting code. For the moment we'll\r
        leave it as a basic placeholder.\r
        </para>\r
           <example><title>Plugin Dissection.</title>\r
@@ -232,7 +232,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
        </para>\r
        <para>\r
        At this point we should have a basic dissector ready to compile and install.\r
-       It doesn't do much at present, than identify the protcol and label it.\r
+       It doesn't do much at present, than identify the protocol and label it.\r
        Compile the dissector to a dll or shared library, and copy it into the plugin\r
        directory of the installation. To finish this off a Makefile of some sort will be \r
        required. A Makefile.nmake for Windows platforms and a Makefile.am for unix/linux\r
@@ -305,7 +305,7 @@ EXTRA_DIST = \
           This will allow us to set up some of the parts we will need.\r
           </para>\r
           <para>\r
-          The first thig we will do is to build a subtree to decode our results into.\r
+          The first thing we will do is to build a subtree to decode our results into.\r
           This helps to keep things looking nice in the detailed display.\r
           Now the dissector is called in two different cases. In one case\r
           it is called to get a summary of the packet, in the other case it is\r
@@ -353,7 +353,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
        and selecting this will highlight the remaining contents of the packet.\r
        </para>\r
        <para>\r
-       Now lets go to the next step and add some protocol disection.\r
+       Now lets go to the next step and add some protocol dissection.\r
        For this step we'll need to construct a couple of tables that help with dissection.\r
        This needs some changes to proto_register_foo. First a couple of statically\r
        declare arrays.\r
@@ -510,7 +510,7 @@ static int hf_foo_initialip = -1;
    </section>\r
    <section><title>Improving the dissection information</title>\r
    <para>\r
-   We can certainly improve the display of the protcol with a bit of extra data.\r
+   We can certainly improve the display of the proto with a bit of extra data.\r
    The first step is to add some text labels. Lets start by labelling the packet types.\r
    There is some useful support for this sort of thing by adding a couple of extra things.\r
    First we add a simple table of type to name.\r
@@ -590,7 +590,7 @@ static int hf_foo_priorityflag = -1;
    <para>\r
    This is starting to look fairly full featured now, but there are a couple of other\r
    things we can do to make things look even more pretty. At the moment our dissection\r
-   shows the packets as "Foo Protocol" which whislt correct is a little uninformative.\r
+   shows the packets as "Foo Protocol" which whilst correct is a little uninformative.\r
    We can enhance this by adding a little more detail.\r
    First, lets get hold of the actual value of the protocol type. We can use the handy\r
    function tvb_get_guint8 to do this.\r
@@ -601,6 +601,7 @@ static int hf_foo_priorityflag = -1;
    </para>\r
           <example><title>Enhancing the display.</title>\r
    <programlisting>\r
+   <![CDATA[\r
 static void\r
 dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)\r
 {\r
@@ -628,6 +629,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
                foo_tree = proto_item_add_subtree(ti, ett_foo);\r
                proto_tree_add_item(foo_tree, hf_foo_pdu_type, tvb, offset, 1, FALSE); offset += 1;\r
 ...\r
+]]>\r
    </programlisting></example>\r
    <para>\r
    So here, after grabbing the value of the first 8 bits, we use it with one of the\r
@@ -639,19 +641,486 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 \r
    </section>\r
   </section>\r
+\r
+  <section id="ChDissectTransformed">\r
+       <title>How to handle transformed data</title>\r
+       <para>\r
+       Some protocols do clever things with data. They might possibly \r
+       encrypt the data, or compress data, or part of it. If you know\r
+       how these steps are taken it is possible to reverse them within the\r
+       dissector. \r
+       </para>\r
+       <para> \r
+       As encryption can be tricky, lets consider the case of compression.\r
+       These techniques can also work for other transformations of data,\r
+       where some step is required before the data can be examined.\r
+       </para>\r
+       <para> \r
+       What basically needs to happen here, is to identify the data that\r
+       needs conversion, take that data and transform it into a new stream,\r
+       and then call a dissector on it.\r
+       Often this needs to be done "on-the-fly" based on clues in the packet.\r
+       Sometimes this needs to be used in conjunction with other techniques,\r
+       such as packet reassembly. The following shows a technique to\r
+       achieve this effect.\r
+       </para>\r
+          <example><title>Decompressing data packets for dissection.</title>\r
+   <programlisting>\r
+   <![CDATA[\r
+       guint8 flags = tvb_get_guint8(tvb, offset); offset ++;\r
+       if (flags & FLAG_COMPRESSED) { /* the remainder of the packet is compressed */\r
+               guint16 orig_size = tvb_get_ntohs(tvb, offset); offset += 2;\r
+               guchar *decompressed_buffer; /* Buffers for decompression */\r
+               decompressed_buffer = (guchar*) malloc (orig_size);\r
+               decompress_packet (tvb_get_ptr(tvb, offset, -1), tvb_length_remaining(tvb, offset),\r
+                               decompressed_buffer, orig_size);\r
+               /* Now re-setup the tvb buffer to have the new data */\r
+               next_tvb = tvb_new_real_data(decompressed_buffer, orig_size, orig_size);\r
+               tvb_set_child_real_data_tvbuff(tvb, next_tvb);\r
+               add_new_data_source(pinfo, next_tvb, "Decompressed Data");\r
+               tvb_set_free_cb(next_tvb, free);\r
+       } else {\r
+               next_tvb = tvb_new_subset(tvb, offset, -1, -1);\r
+       }\r
+       offset = 0;\r
+       /* process next_tvb from here on */\r
+]]>\r
+   </programlisting></example>\r
+       <para>\r
+       The first steps here are to recognise the compression. In this case\r
+       a flag byte alerts us to the fact the remainder of the packet is compressed.\r
+       Next we retrieve the original size of the packet, which in this case\r
+       is conveniently within the protocol. If its not, it may be part of the \r
+       compression routine to work it out for you, in which case the logic would\r
+       be different.\r
+       </para>\r
+       <para>\r
+       So armed with the size, a buffer is allocated to receive the uncompressed\r
+       data using malloc, and the packet is decompressed into it.\r
+       The tvb_get_ptr function is useful to get a pointer to the raw data of \r
+       the packet from the offset onwards. In this case the \r
+       decompression routine also needs to know the length, which is\r
+       given by the tvb_length_remaining function.\r
+       </para>\r
+       <para>\r
+       Next we build a new tvb buffer from this data, using the tvb_new_real_data\r
+       call. This data is a child of our original data, so we acknowledge that\r
+       in the next call to tvb_set_child_real_data_tvbuff. \r
+       Finally we add this data as a new data source, so that\r
+       the detailed display can show the decompressed bytes as well as the original.\r
+       One procedural step is to add a handler to free the data when its no longer needed.\r
+       In this case as malloc was used to allocate the memory, free is the appropriate\r
+       function.\r
+       </para>\r
+       <para> \r
+       After this has been set up the remainder of the dissector can dissect the\r
+       buffer next_tvb, as its a new buffer the offset needs to be 0 as we start\r
+       again from the beginning of this buffer. To make the rest of the dissector\r
+       work regardless of whether compression was involved or not, in the case that\r
+       compression was not signaled, we use the tvb_new_subset to deliver us\r
+       a new buffer based on the old one but starting at the current offset, and\r
+       extending to the end. This makes dissecting the packet from this point on\r
+       exactly the same regardless of compression.\r
+       </para>\r
+  </section>\r
+  <section id="ChDissectReassemble">\r
+       <title>How to reassemble split packets</title>\r
+       <para>\r
+       Some protocols have times when they have to split a large packet across\r
+       multiple other packets. In this case the dissection can't be carried out correctly\r
+       until you have all the data. The first packet doesn't have enough data,\r
+       and the subsequent packets don't have the expect format.\r
+       To dissect these packets you need to wait until all the parts have\r
+       arrived and then start the dissection.\r
+       </para>\r
+         <section id="ChDissectReassembleUdp">\r
+               <title>How to reassemble split UDP packets</title>\r
+               <para>\r
+               As an example, lets examine a protocol that is layered on\r
+               top of UDP that splits up its own data stream.\r
+               If a packet is bigger than some given size, it will be split into\r
+               chunks, and somehow signaled within its protocol.\r
+               </para>\r
+               <para>\r
+               To deal with such streams, we need several things to trigger\r
+               from. We need to know that this is packet is part of a multi-packet \r
+               sequence. We need to know how many packets are in the sequence.\r
+               We need to also know when we have all the packets.\r
+               </para>\r
+               <para>\r
+               For this example we'll assume there is a simple in-protocol\r
+               signaling mechanism to give details. A flag byte that signals\r
+               the presence of a multi-packet and also the last packet, \r
+               followed by an ID of the sequence,\r
+               a packet sequence number.\r
+               </para>\r
+          <example><title>Reassembling fragments - Part 1</title>\r
+   <programlisting>\r
+   <![CDATA[\r
+#include <epan/reassemble.h>\r
+   ...\r
+save_fragmented = pinfo->fragmented;\r
+flags = tvb_get_guint8(tvb, offset); offset++;\r
+if (flags & FL_FRAGMENT) { // fragmented\r
+       tvbuff_t* new_tvb = NULL;\r
+       fragment_data *frag_msg = NULL;\r
+       guint16 msg_seqid = tvb_get_ntohs(tvb, offset); offset += 2;\r
+       guint16 msg_num = tvb_get_ntohs(tvb, offset); offset += 2;\r
+\r
+       pinfo->fragmented = TRUE;\r
+       frag_msg = fragment_add_seq_check (tvb, offset, pinfo,\r
+               msg_seqid, /* guint32 ID for fragments belonging together */\r
+               msg_fragment_table, /* list of message fragments */\r
+               msg_reassembled_table, /* list of reassembled messages */\r
+               msg_num, /* guint32 fragment sequence number */\r
+               -1, /* guint32 fragment length - to the end */\r
+               flags & FL_FRAG_LAST); /* More fragments? */\r
+]]>\r
+   </programlisting></example>\r
+       <para>\r
+       We start by saving the fragmented state of this packet, so we can restore it later.\r
+       Next comes some protocol specific stuff, to dig the fragment data\r
+       out of the stream if it's present. Having decided it is present, we \r
+       let the function fragment_add_seq_check do its work.\r
+       We need to provide this with a certain amount of data.\r
+       </para>\r
+       <itemizedlist>\r
+       <listitem><para>\r
+       The tvb buffer we are dissecting.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       The offset where the partial packet starts.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       The provided packet info.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       The sequence number of the fragment stream. There may be several \r
+       streams of fragments in flight, and this is used to key the \r
+       relevant one to be used for reassembly.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       The msg_fragment_table and the msg_reassembled_table are variables\r
+       we need to declare. We'll consider these in detail later.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       msg_num is the packet number within the sequence. \r
+       </para></listitem>\r
+       <listitem><para>\r
+       The length here is specified as -1, as we want the rest of the packet data. \r
+       </para></listitem>\r
+       <listitem><para>\r
+       Finally a parameter that signals if this is the last fragment or not.\r
+       This might be a flag as in this case, or there may be a counter in the\r
+       protocol.\r
+       </para></listitem>\r
+       </itemizedlist>\r
+          <example><title>Reassembling fragments part 2</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+       if (msg_tree)\r
+               new_tvb = process_reassembled_data(tvb, offset, pinfo,\r
+               "Reassembled Message", frag_msg, &msg_frag_items,\r
+               NULL, msg_tree);\r
+\r
+       if (frag_msg) { /* Reassembled */\r
+               if (check_col (pinfo->cinfo, COL_INFO))\r
+                       col_append_str (pinfo->cinfo, COL_INFO, \r
+                       " (Message Reassembled)");\r
+       } else {\r
+               /* Not last packet of reassembled Short Message */\r
+               if (check_col (pinfo->cinfo, COL_INFO))\r
+                       col_append_fstr (pinfo->cinfo, COL_INFO,\r
+                       " (Message fragment %u)", msg_num);\r
+       }\r
+       if (new_tvb) { // take it all\r
+               next_tvb = new_tvb;\r
+       }\r
+       else  // make a new subset\r
+               next_tvb = tvb_new_subset(next_tvb, offset, -1, -1);\r
+}\r
+else {\r
+       next_tvb = tvb_new_subset(next_tvb, offset, -1, -1);\r
+}\r
+\r
+offset = 0;\r
+pinfo->fragmented = save_fragmented;\r
+       ]]>\r
+   </programlisting></example>\r
+          <para>\r
+          Having passed the fragment data to the reassembly handler, we can\r
+          now check if we have the whole message. We can only do this if were\r
+          in the display mode, as we need to pass the display tree parameter into this \r
+          routine. If there is enough information, this routine will return the \r
+          newly reassembled data buffer. \r
+          </para>\r
+          <para>\r
+          After that, we add a couple of informative messages to the display\r
+          to show that this is part of a sequence. Then a bit of manipulation\r
+          of the buffers and the dissection can proceed.\r
+          Normally you will probably not bother dissecting further unless the \r
+          fragments have been reassembled as there won't be much to find. Sometimes\r
+          the first packet in the sequence can be partially decoded though if you wish.\r
+          </para>\r
+          <para>\r
+          Now the mysterious data we passed into the fragment_add_seq_check.\r
+          </para>\r
+          <example><title>Reassembling fragments - Initialisation</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+static GHashTable *msg_fragment_table = NULL;\r
+static GHashTable *msg_reassembled_table = NULL;\r
+\r
+\r
+static void\r
+msg_init_protocol(void)\r
+{\r
+       fragment_table_init (&msg_fragment_table);\r
+       reassembled_table_init(&msg_reassembled_table);\r
+}\r
+]]>\r
+   </programlisting></example>\r
+       <para>\r
+       First a couple of hash tables are declared, and these are initialised\r
+       in the protocol initialisation routine.\r
+       Following that, a fragment_items structure is allocated and filled \r
+       in with a series of ett items, hf data items, and a string tag.\r
+       The ett and hf values should be included in the relevant tables like\r
+       all the other variables your protocol may use. The hf variables\r
+       need to be placed in the structure something like the following.\r
+       Of course the names may need to be adjusted.\r
+       </para>\r
+          <example><title>Reassembling fragments - Data</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+static const fragment_items msg_frag_items = {\r
+       /* Fragment subtrees */\r
+       &ett_msg_fragment,\r
+       &ett_msg_fragments,\r
+       /* Fragment fields */\r
+       &hf_msg_fragments,\r
+       &hf_msg_fragment,\r
+       &hf_msg_fragment_overlap,\r
+       &hf_msg_fragment_overlap_conflicts,\r
+       &hf_msg_fragment_multiple_tails,\r
+       &hf_msg_fragment_too_long_fragment,\r
+       &hf_msg_fragment_error,\r
+       /* Reassembled in field */\r
+       &hf_msg_reassembled_in,\r
+       /* Tag */\r
+       "Message fragments"\r
+};\r
+...\r
+{&hf_msg_fragments,\r
+       {"Message fragments", "msg.fragments",\r
+       FT_NONE, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+{&hf_msg_fragment,\r
+       {"Message fragment", "msg.fragment",\r
+       FT_FRAMENUM, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+{&hf_msg_fragment_overlap,\r
+       {"Message fragment overlap", "msg.fragment.overlap",\r
+       FT_BOOLEAN, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+{&hf_msg_fragment_overlap_conflicts,\r
+       {"Message fragment overlapping with conflicting data",\r
+       "msg.fragment.overlap.conflicts",\r
+       FT_BOOLEAN, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+{&hf_msg_fragment_multiple_tails,\r
+       {"Message has multiple tail fragments",\r
+       "msg.fragment.multiple_tails", \r
+       FT_BOOLEAN, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+{&hf_msg_fragment_too_long_fragment,\r
+       {"Message fragment too long", "msg.fragment.too_long_fragment",\r
+       FT_BOOLEAN, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+{&hf_msg_fragment_error,\r
+       {"Message defragmentation error", "msg.fragment.error",\r
+       FT_FRAMENUM, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+{&hf_msg_reassembled_in,\r
+       {"Reassembled in", "msg.reassembled.in",\r
+       FT_FRAMENUM, BASE_NONE, NULL, 0x00, NULL, HFILL } },\r
+]]>\r
+   </programlisting></example>\r
+   <para>\r
+   These hf variables are used internally within the reassembly routines\r
+   to make useful links, and to add data to the dissection. It produces \r
+   links from one packet to another - such as a partial packet having \r
+   a link to the fully reassembled packet. Likewise there are back pointers\r
+   to the individual packets from the reassembled one.\r
+   The other variables are used for flagging up errors.\r
+   </para>\r
+       </section>\r
+  </section>\r
   <section id="ChDissectTap">\r
        <title>How to tap protocols</title>\r
        <para>\r
-       Some info about how to use conversations in a dissector can be \r
-       found in the file doc/README.tapping.\r
+       Adding a Tap interface to a protocol allows it to do some useful things.\r
+       In particular you can produce protocol statistics from teh tap interface.\r
+       </para>\r
+       <para>\r
+       A tap is basically a way of allowing other items to see whats happening as\r
+       a protocol is dissected. A tap is registered with the main program, and\r
+       then called on each dissection. Some arbritary protocol specific data\r
+       is provided with the routine that can be used.\r
+       </para>\r
+       <para>\r
+       To create a tap, you first need to register a tap. \r
+       A tap is registered with an integer handle, and registered \r
+       with the routine register_tap. This takes a string name\r
+       with which to find it again.\r
+       </para>\r
+          <example><title>Initialising a tap</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+#include <epan/tap.h>\r
+\r
+static int foo_tap = -1;\r
+\r
+struct FooTap {\r
+       gint packet_type;\r
+       gint priorty;\r
+       ...\r
+};\r
+...\r
+       foo_tap = register_tap("foo");\r
+]]>\r
+   </programlisting></example>\r
+       <para>\r
+       Whilst you can program a tap without protocol specific data, it\r
+       is generally not very useful. Therefore its a good idea\r
+       to declare a structure that can be passed through the tap.\r
+       This needs to be a static structure as it will be used after the\r
+       dissection routine has returned. Its generally best to pick out some\r
+       generic parts of the protocol you are dissecting into the tap data.\r
+       A packet type, a priority, a status code maybe.\r
+       The structure really needs to be included in a header file so\r
+       that it can be included by other components that want to listen in\r
+       to the tap.\r
+       </para>\r
+       <para>\r
+       Once you have these defined, its simply a case of populating the\r
+       protocol specific structure and then calling tap_queue_packet probably\r
+       as the last part of the dissector.\r
+       </para>\r
+          <example><title>Calling a protocol tap</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+       static struct FooTap pinfo;\r
+       \r
+       pinfo.packet_type = tvb_get_guint8(tvb, 0);\r
+       pinfo.priority = tvb_get_ntohs(tvb, 8);\r
+          ...\r
+       tap_queue_packet(foo_tap, pinfo, &pinfo);\r
+]]>\r
+   </programlisting></example>\r
+       <para>  \r
+       This now enables those interested parties to listen in on the details\r
+       of this protocol conversation.\r
        </para>\r
   </section>\r
   <section id="ChDissectStats">\r
        <title>How to produce protocol stats</title>\r
        <para>\r
-       Some info about how to use conversations in a dissector can be \r
-       found in the file doc/README.stats_tree.\r
+       Given that you have a tap interface for the protocol, you can use this\r
+       to produce some interesting statistics (well presumably interesting!) from\r
+       protocol traces.\r
+       </para>\r
+       <para>\r
+       This can be done in a separate plugin, or in the same plugin that is \r
+       doing the dissection. The latter scheme is better, as the tap and stats\r
+       module typically rely on sharing protocol specific data, which might get out\r
+       of step between two different plugins.\r
        </para>\r
+       <para> \r
+       Here is a mechanism to produce statistics from the above TAP interface.\r
+       </para>\r
+          <example><title>Initialising a stats interface</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+/* register all http trees */\r
+static void register_foo_stat_trees(void) {\r
+       stats_tree_register("foo","foo","Foo/Packet Types", \r
+               foo_stats_tree_packet, foo_stats_tree_init, NULL );\r
+}\r
+#ifndef ENABLE_STATIC\r
+//G_MODULE_EXPORT const gchar version[] = "0.0";\r
+\r
+G_MODULE_EXPORT void plugin_register_tap_listener(void)\r
+{\r
+       register_foo_stat_trees();\r
+}\r
+\r
+#endif\r
+]]>\r
+   </programlisting></example>\r
+       <para>\r
+       Working from the bottom up, first the plugin interface entry point is defined,\r
+       plugin_register_tap_listener. This simply calls the initialisation function\r
+       register_foo_stat_trees.\r
+       </para>\r
+       <para>\r
+       This in turn calls the stats_tree_register function, which takes\r
+       three strings, and three functions.\r
+       </para>\r
+       <orderedlist>\r
+       <listitem><para>\r
+       This is the tap name that is registered.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       An abbreviation of the stats name.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       The name of the stats module. A '/' character can be used to make sub menus.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       The function that will called to generate the stats.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       A function that can be called to initialise the stats data.\r
+       </para></listitem>\r
+       <listitem><para>\r
+       A function that will be called to clean up the stats data.\r
+       </para></listitem>\r
+       </orderedlist>\r
+       <para>\r
+       In this case we only need the first two functions, as there is nothing specific to clean up.\r
+       </para>\r
+          <example><title>Initialising a stats session</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+static const guint8* st_str_packets = "Total Packets";\r
+static const guint8* st_str_packet_types = "FOO Packet Types";\r
+static int st_node_packets = -1;\r
+static int st_node_packet_types = -1;\r
+\r
+static void foo_stats_tree_init(stats_tree* st) {\r
+       st_node_packets = stats_tree_create_node(st, st_str_packets, 0, TRUE);  \r
+               st_node_packet_types = stats_tree_create_pivot(st, st_str_packet_types, st_node_packets);\r
+}\r
+]]>\r
+   </programlisting></example>\r
+       <para>\r
+       In this case we create a new tree node, to handle the total packets,\r
+       and as a child of that we create a pivot table to handle the stats about \r
+       different packet types.\r
+       </para>\r
+          <example><title>Generating the stats</title>\r
+          <programlisting>\r
+          <![CDATA[\r
+static int foo_stats_tree_packet(stats_tree* st, packet_info* pinfo , epan_dissect_t* edt , const void* p) {\r
+       struct FooTap *pi = (struct FooTap *)p;\r
+       tick_stat_node(st, st_str_packets, 0, FALSE);\r
+       stats_tree_tick_pivot(st, st_node_packet_types, \r
+                       val_to_str(pi->packet_type, msgtypevalues, "Unknown packet type (%d)"));\r
+       return 1;\r
+}      \r
+]]>\r
+   </programlisting></example>\r
+       <para>\r
+       In this case the processing of the stats is quite simple.\r
+       First we call the tick_stat_node for the st_str_packets packet node, to count\r
+       packets.\r
+       Then a call to stats_tree_tick_pivot on the st_node_packet_types subtree\r
+       allows us to record statistics by packet type.\r
+       </para>\r
   </section>\r
 \r
   <section id="ChDissectConversation">\r