adding a chapter about capturing, currently only containing the mail from Guy Harris...
authorulfl <ulfl@f5534014-38df-0310-8fa8-9805f1628bb7>
Tue, 19 Oct 2004 18:32:27 +0000 (18:32 +0000)
committerulfl <ulfl@f5534014-38df-0310-8fa8-9805f1628bb7>
Tue, 19 Oct 2004 18:32:27 +0000 (18:32 +0000)
git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@12349 f5534014-38df-0310-8fa8-9805f1628bb7

docbook/developer-guide.xml
docbook/edg_src/EDG_chapter_capture.xml [new file with mode: 0644]

index 7a1fcdb8c2338e9c1a5f06bd03b2e83ac1ac3cc1..845db9fccb00434c9eee5573e697e8253d588943 100644 (file)
@@ -73,6 +73,7 @@ FILE SECTION
   
   <!ENTITY BuildIntroduction SYSTEM "edg_src/EDG_chapter_build_intro.xml">
   <!ENTITY HowEtherealWorks SYSTEM "edg_src/EDG_chapter_works.xml">
+  <!ENTITY Capture SYSTEM "edg_src/EDG_chapter_capture.xml">
   <!ENTITY Dissection SYSTEM "edg_src/EDG_chapter_dissection.xml">
   <!ENTITY UserInterface SYSTEM "edg_src/EDG_chapter_userinterface.xml">
 
@@ -134,6 +135,7 @@ to change the sources (e.g. adding a new dissector).</command>
 </partintro>
 &HowEtherealWorks;
 &BuildIntroduction;
+&Capture;
 &Dissection;
 &UserInterface;
 </part>
diff --git a/docbook/edg_src/EDG_chapter_capture.xml b/docbook/edg_src/EDG_chapter_capture.xml
new file mode 100644 (file)
index 0000000..65b531a
--- /dev/null
@@ -0,0 +1,82 @@
+<!-- EDG Chapter Capture -->\r
+<!-- $Id: EDG_chapter_capture.xml 11816 2004-08-23 19:46:18Z ulfl $ -->\r
+\r
+<chapter id="ChapterCapture">\r
+  <title>Packet capturing</title>\r
+  \r
+  <para>\r
+  XXX - this chapter has to be reviewed and extended!\r
+  </para>\r
+  \r
+  <section id="ChCaptureAddLibpcap">\r
+       <title>How to add a new capture type to libpcap</title>\r
+       <para>\r
+       The following is an excerpt from a developer mailing list mail, about \r
+       adding ISO 9141 and 14230 (simple serial line car diagnostics) to \r
+       Ethereal:\r
+       </para>\r
+       <para>\r
+       For libpcap, the first thing you'd need to do would be to get DLT_ values \r
+       for all the link-layer protocols you'd need.  If ISO 9141 and 14230 use \r
+       the same link-layer protocol, they might be able to share a DLT_ value, \r
+       unless the only way to know what protocols are running above the link \r
+       layer is to know which link-layer protocol is being used, in which case \r
+       you might want separate DLT_ values.\r
+       </para>\r
+       <para>\r
+       For the rest of the libpcap discussion, I'll assume you're working with \r
+       the current top-of-tree CVS version of libpcap, and that this is on a \r
+       UN*X platform.  You probably don't want to work with a version older than \r
+       0.8, even if whatever OS you're using happens to include libpcap - older \r
+       versions are not as friendly towards adding support for devices other than \r
+       standard network interfaces.\r
+       </para>\r
+       <para>\r
+       Then you'd probably add to the "pcap_open_live()" routine, for whatever \r
+       platform or platforms this code should work, something such as a check \r
+       for device names that look like serial port names and, if the check \r
+       succeeds, a call to a routine to open the serial port.\r
+       </para>\r
+       <para>\r
+       See, for example, the "#ifdef HAVE_DAG_API" code in pcap-linux.c and \r
+       pcap-bpf.c.\r
+       </para>\r
+       <para>\r
+       The serial port open routine would open the serial port device, set the \r
+       baud rate and do anything else needed to open the device.  It'd allocate \r
+       a pcap_t, set its "fd" member to the file descriptor for the serial \r
+       device, set the "snapshot" member to the argument passed to the open \r
+       routine, set the "linktype" member to one of the DLT_ values, and set the \r
+       "selectable_fd" member to the same value as the "fd" member.  It should \r
+       also set the "dlt_count" member to the number of DLT_ values to support, \r
+       and allocate an array of "dlt_count" "u_int"s, assign it to the "dlt_list" \r
+       member, and fill in that list with all the DLT_ values.\r
+       </para>\r
+       <para>\r
+       You'd then set the various _op fields to routines to handle the \r
+       operations in question.  read_op is the routine that'd read packets from \r
+       the device.  inject_op would be for sending packets; if you don't care \r
+       about that, you'd set it to a routine that returns an error indication. \r
+       setfilter_op can probably just be set to install_bpf_program. set_datalink \r
+       would just set the "linktype" member to the specified value if it's one \r
+       of the values for OBD, otherwise it should return an error. getnonblock_op \r
+       can probably be set to pcap_getnonblock_fd; setnonblock_op can probably be \r
+       set to pcap_setnonblock_fd.  stats_op would be set to a routine that \r
+       reports statistics.  close_op can probably be set to pcap_close_common.\r
+       </para>\r
+       <para>\r
+       If there's more than one DLT_ value, you definitely want a set_datalink \r
+       routine, so that the user can select the appropriate link-layer type.\r
+       </para>\r
+       <para>\r
+       For Ethereal, you'd add support for those DLT_ values to wiretap/libpcap.c, \r
+       which might mean adding one or more WTAP_ENCAP types to wtap.h and to the \r
+       encap_table[] table in wiretap/wtap.c.  You'd then have to write a \r
+       dissector or dissectors for the link-layer protocols or protocols and have \r
+       them register themselves with the "wtap_encap" dissector table, with the \r
+       appropriate WTAP_ENCAP values, by calling "dissector_add()".\r
+       </para>\r
+  </section>\r
+\r
+</chapter>\r
+<!-- End of EUG Chapter Dissection -->\r