Convert three more WSDG chapters: works, build, and capture.

Start adding references to Qt and wsutil. Fix a file extension in
CMakeLists.txt.

Change-Id: I0cbe7e802d88a05effff40b5de72669e22c0df53
Reviewed-on: https://code.wireshark.org/review/79
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Tested-by: Gerald Combs <gerald@wireshark.org>
This commit is contained in:
Gerald Combs 2014-02-02 11:00:30 -08:00 committed by Gerald Combs
parent 06510129bb
commit 1b2145d931
9 changed files with 259 additions and 329 deletions

View File

@ -182,8 +182,8 @@ set(WSUG_GRAPHICS
)
set(WSDG_FILES
wsdg_src/WSDG_chapter_build_intro.xml
wsdg_src/WSDG_chapter_capture.xml
wsdg_generated_src/WSDG_chapter_build_intro.xml
wsdg_generated_src/WSDG_chapter_capture.xml
wsdg_src/WSDG_chapter_dissection.xml
wsdg_generated_src/WSDG_chapter_env_intro.xml
wsdg_generated_src/WSDG_chapter_libraries.xml
@ -191,18 +191,21 @@ set(WSDG_FILES
wsdg_generated_src/WSDG_chapter_sources.xml
wsdg_generated_src/WSDG_chapter_tools.xml
wsdg_src/WSDG_chapter_userinterface.xml
wsdg_src/WSDG_chapter_works.xml
wsdg_generated_src/WSDG_chapter_works.xml
wsdg_src/WSDG_meta_info.xml
wsdg_generated_src/WSDG_preface.xml
ws.css
)
set(WSDG_ASCIIDOC_FILES
wsdg_src/WSDG_chapter_build_intro.asciidoc
wsdg_src/WSDG_chapter_capture.asciidoc
wsdg_src/WSDG_chapter_env_intro.asciidoc
wsdg_src/WSDG_chapter_libraries.asciidoc
wsdg_src/WSDG_chapter_quick_setup.xml
wsdg_src/WSDG_chapter_quick_setup.asciidoc
wsdg_src/WSDG_chapter_sources.asciidoc
wsdg_src/WSDG_chapter_tools.asciidoc
wsdg_src/WSDG_chapter_works.asciidoc
wsdg_src/WSDG_preface.asciidoc
)

View File

@ -159,8 +159,8 @@ WSUG_GRAPHICS = \
wsug_graphics/toolbar/stock_zoom_out_24.png
WSDG_FILES = \
wsdg_src/WSDG_chapter_build_intro.xml \
wsdg_src/WSDG_chapter_capture.xml \
wsdg_src/WSDG_chapter_build_intro.asciidoc \
wsdg_src/WSDG_chapter_capture.asciidoc \
wsdg_src/WSDG_chapter_dissection.xml \
wsdg_src/WSDG_chapter_env_intro.asciidoc \
wsdg_src/WSDG_chapter_libraries.asciidoc \
@ -168,17 +168,20 @@ WSDG_FILES = \
wsdg_src/WSDG_chapter_sources.asciidoc \
wsdg_src/WSDG_chapter_tools.asciidoc \
wsdg_src/WSDG_chapter_userinterface.xml \
wsdg_src/WSDG_chapter_works.xml \
wsdg_src/WSDG_chapter_works.asciidoc \
wsdg_src/WSDG_meta_info.xml \
wsdg_src/WSDG_preface.asciidoc \
ws.css
WSDG_GENERATED_SOURCE = \
wsdg_src/WSDG_chapter_build_intro.xml \
wsdg_src/WSDG_chapter_capture.xml \
wsdg_src/WSDG_chapter_env_intro.xml \
wsdg_src/WSDG_chapter_libraries.xml \
wsdg_src/WSDG_chapter_quick_setup.xml \
wsdg_src/WSDG_chapter_sources.xml \
wsdg_src/WSDG_chapter_tools.xml \
wsdg_src/WSDG_chapter_works.xml \
wsdg_src/WSDG_preface.xml
WSDG_GRAPHICS = \

View File

@ -109,12 +109,12 @@ FILE SECTION
<title>Wireshark Build Environment</title>
<partintro>
<para>
<command>Part I. Wireshark Build Environment</command>
Part I. Wireshark Build Environment
</para>
<para>
<command>The first part describes how to set up the tools, libraries and
The first part describes how to set up the tools, libraries and
source needed to generate Wireshark, and how to do some typical development
tasks.</command>
tasks.
</para>
<para>
Part II. Wireshark Development

View File

@ -0,0 +1,54 @@
++++++++++++++++++++++++++++++++++++++
<!-- WSDG Chapter Build Introduction -->
++++++++++++++++++++++++++++++++++++++
[[ChapterBuildIntro]]
== Introduction
[[ChCodeOverview]]
=== Source overview
Wireshark consists of the following major parts:
* Packet dissection - in the '/epan/dissector' and '/plugin/*' directories
* File I/O - using Wireshark's own wiretap library
* Capture - using the libpcap/winpcap library, in /wiretap
* User interface - using the Qt or $$GTK+$$ and associated libraries
* Utilities - miscellaneous helper code
* Help - using an external web browser and GTK text output
[[ChCodeStyle]]
=== Coding Style
The coding style guides for Wireshark can be found in the "Code style"
section of the file 'doc/README.developer'.
[[ChCodeGLib]]
=== The GLib library
Glib is used as a basic platform abstraction library. It's doesn't provide
any direct GUI functionality.
To quote the Glib Reverence Manual:
____
GLib provides the core application building blocks for libraries and
applications written in C. It provides the core object system used in GNOME, the
main loop implementation, and a large set of utility functions for strings and
common data structures.
____
GLib contains lots of useful things for platform independent development.
See https://developer.gnome.org/glib/[] for details about GLib.
++++++++++++++++++++++++++++++++++++++
<!-- End of WSDG Chapter Build Introduction -->
++++++++++++++++++++++++++++++++++++++

View File

@ -1,69 +0,0 @@
<!-- WSDG Chapter Build Introduction -->
<!-- $Id$ -->
<chapter id="ChapterBuildIntro">
<title>Introduction</title>
<section id="ChCodeOverview">
<title>Source overview</title>
<para>
Wireshark consists of the following major parts:
<itemizedlist>
<listitem><para>
Packet dissection - in the /epan/dissector and /plugin/* directory
</para></listitem>
<listitem><para>
File I/O - using Wireshark's own wiretap library
</para></listitem>
<listitem><para>
Capture - using the libpcap/winpcap library, in /wiretap
</para></listitem>
<listitem><para>
User interface - using the GTK+ (and corresponding) libraries
</para></listitem>
<listitem><para>
Help - using an external webbrowser and GTK text output
</para></listitem>
</itemizedlist>
Beside this, some other minor parts and additional helpers exist.
</para>
<para>
Currently there's no clean separation of the modules in the code.
However, as the development team switched from Concurrent Versions System
(CVS) to Subversion (SVN) some time ago,
directory cleanup is much easier now. So there's a chance that
the directory structure will become clean in the future.
</para>
</section>
<section id="ChCodeStyle">
<title>Coding styleguides</title>
<para>
The coding styleguides for Wireshark can be found in the "Code style"
section of the file <filename>doc/README.developer</filename>.
</para>
</section>
<section id="ChCodeGLib">
<title>The GLib library</title>
<para>
Glib is used as a basic platform abstraction library, it's not related to
GUI things.
</para>
<para>
To quote the Glib documentation: <quote>GLib is a general-purpose utility
library, which provides many useful
data types, macros, type conversions, string utilities, file utilities,
a main loop abstraction, and so on. It works on many UNIX-like platforms,
Windows, OS/2 and BeOS. GLib is released under the GNU Library General
Public License (GNU LGPL).</quote>
</para>
<para>
GLib contains lot's of useful things for platform independent development.
See <ulink url="http://developer.gnome.org/doc/API/2.0/glib/index.html"/>
for details about GLib.
</para>
</section>
</chapter>
<!-- End of WSDG Chapter Build Introduction -->

View File

@ -0,0 +1,74 @@
++++++++++++++++++++++++++++++++++++++
<!-- WSDG Chapter Capture -->
++++++++++++++++++++++++++++++++++++++
[[ChapterCapture]]
== Packet capturing
****
This chapter needs to be reviewed and extended.
****
[[ChCaptureAddLibpcap]]
=== How to add a new capture type to libpcap
The following is an updated excerpt from a developer mailing list mail about
adding ISO 9141 and 14230 (simple serial line card diagnostics) to Wireshark:
For libpcap, the first thing you'd need to do would be to get +$$DLT_*$$+ values
for all the link-layer protocols you'd need. If ISO 9141 and 14230 use the same
link-layer protocol, they might be able to share a +$$DLT_*$$+ value, unless the
only way to know what protocols are running above the link layer is to know
which link-layer protocol is being used, in which case you might want separate
+$$DLT_*$$+ values.
For the rest of the libpcap discussion, I'll assume you're working with libpcap
1.0 or later and that this is on a UN*X platform. You probably don't want to
work with a version older than 1.0, even if whatever OS you're using happens to
include libpcap - older versions are not as friendly towards adding support for
devices other than standard network interfaces.
Then you'd probably add to the +pcap_open_live()+ routine, for whatever
platform or platforms this code should work, something such as a check
for device names that look like serial port names and, if the check
succeeds, a call to a routine to open the serial port.
See, for example, the +#ifdef HAVE_DAG_API+ code in 'pcap-linux.c' and
'pcap-bpf.c'.
The serial port open routine would open the serial port device, set the baud
rate and do anything else needed to open the device. It'd allocate a +pcap_t+,
set its +fd+ member to the file descriptor for the serial device, set the
+snapshot+ member to the argument passed to the open routine, set the +linktype+
member to one of the +$$DLT_*$$+ values, and set the +selectable_fd+ member to
the same value as the +fd+ member. It should also set the +dlt_count+ member to
the number of +$$DLT_*$$+ values to support, and allocate an array of
+dlt_count+ +u_int+s, assign it to the +dlt_list+ member, and fill in that list
with all the +$$DLT_*$$+ values.
You'd then set the various +$$*_op$$+ fields to routines to handle the operations in
question. +read_op+ is the routine that'd read packets from the device. +inject_op+
would be for sending packets; if you don't care about that, you'd set it to a
routine that returns an error indication. +setfilter_op+ can probably just be set
to +install_bpf_program+. +set_datalink+ would just set the +linktype+ member to the
specified value if it's one of the values for OBD, otherwise it should return an
error. +getnonblock_op+ can probably be set to +pcap_getnonblock_fd+. +setnonblock_op+
can probably be set to +pcap_setnonblock_fd+. +stats_op+ would be set to a routine
that reports statistics. +close_op+ can probably be set to +pcap_close_common+.
If there's more than one +$$DLT_*$$+ value, you definitely want a +set_datalink+
routine so that the user can select the appropriate link-layer type.
For Wireshark, you'd add support for those +$$DLT_*$$+ values to
'wiretap/libpcap.c', which might mean adding one or more +WTAP_ENCAP+ types to
'wtap.h' and to the +$$encap_table[]$$+ table in 'wiretap/wtap.c'. You'd then
have to write a dissector or dissectors for the link-layer protocols or
protocols and have them register themselves with the +wtap_encap+ dissector
table, with the appropriate +WTAP_ENCAP+ values by calling
+dissector_add_uint()+.
++++++++++++++++++++++++++++++++++++
<!-- End of WSDG Chapter Capture -->
++++++++++++++++++++++++++++++++++++

View File

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

View File

@ -0,0 +1,115 @@
++++++++++++++++++++++++++++++++++++++
<!-- WSDG Chapter Works -->
++++++++++++++++++++++++++++++++++++++
[[ChapterWorks]]
== How Wireshark Works
[[ChWorksIntro]]
=== Introduction
This chapter will give you a short overview of how Wireshark works.
[[ChWorksOverview]]
=== Overview
The following will give you a simplified overview of Wireshark's function blocks:
[[ChWorksFigOverview]]
.Wireshark function blocks
image::wsdg_graphics/ws-function-blocks.png[]
****
This image is out of date. It is missing the utility library in 'wsutil' and
the Qt UI in 'ui/qt'.
****
The function blocks in more detail:
$$GTK+ 2$$:: Handling of all user input/output (all windows, dialogs and such).
Source code can be found in the 'ui/gtk' directory.
Core:: Main "glue code" that holds the other blocks together. Source
code can be found in the root directory.
Epan:: Ethereal Packet ANalyzer -- the packet analyzing engine.
Source code can be found in the 'epan' directory. Epan provides
the following APIs:
* Protocol Tree. Dissection information for an individual packet.
* Dissectors. The various protocol dissectors in
'epan/dissectors'.
* Dissector Plugins - Support for implementing dissectors as separate modules.
Source code can be found in 'plugins'.
* Display Filters - The display filter engine at
'epan/dfilter'.
Wiretap:: The wiretap library is used to read andwrite capture files in libpcap,
pcapng, and many other file formats. Source code is in the
'wiretap' directory.
Capture:: The interface with the capture engine. Source code in the
root directory.
Dumpcap:: The capture engine itself. This is the only part that is to execute
with elevated privileges. Source code in the root directory.
WinPcap and libpcap:: These are separate libraries that provide packet capture
and filtering support on different platforms. The filtering WinPcap and libpcap
works at a much lower level than Wireshark's display filters and uses a
significantly different mechanism. That's why we have different display and
capture filter syntaxes.
[[ChWorksCapturePackets]]
=== Capturing packets
Capturing takes packets from a network adapter and saves them to a file
on your hard disk.
Since raw network adapter access requires elevated privileges these functions
are isolated into the `dumpcap` program. It's only this program that needs these
privileges, allowing the main part of the code (dissectors, user interface,
etc) to run with normal user privileges.
To hide all the low-level machine dependent details from Wireshark, the libpcap
and WinPcap (see <<ChLibsPcap>>) libraries is used. These libraries provide a
general purpose interface to capture packets and are used by a wide variety of
applications.
[[ChWorksCaptureFiles]]
=== Capture Files
Wireshark can read and write capture files in its natural file formats, pcapng
and pcap, which are used by many other network capturing tools, such as tcpdump.
In addition to this, as one of its strengths, Wireshark can read and write files
in many different file formats of other network capturing tools. The wiretap
library, developed together with Wireshark, provides a general purpose interface
to read and write all the file formats. If you need to add support for another
capture file format this is the place to start.
[[ChWorksDissectPackets]]
=== Dissect packets
While Wireshark is loading packets from a file each packet is dissected.
Wireshark tries to detect the packet type and gets as much information from the
packet as possible. In this run though, only the information shown in the packet
list pane is needed.
As the user selects a specific packet in the packet list pane this packet will
be dissected again. This time, Wireshark tries to get every single piece of
information and put it into the packet details pane.
++++++++++++++++++++++++++++++++++++++
<!-- End of WSDG Chapter Works -->
++++++++++++++++++++++++++++++++++++++

View File

@ -1,168 +0,0 @@
<!-- WSDG Chapter Works -->
<!-- $Id$ -->
<chapter id="ChapterWorks">
<title>How Wireshark Works</title>
<section id="ChWorksIntro">
<title>Introduction</title>
<para>
This chapter will give you a short overview of how Wireshark works.
</para>
</section>
<section id="ChWorksOverview">
<title>Overview</title>
<para>
The following will give you a simplified overview of Wireshark's function blocks:
<figure id="ChWorksFigOverview">
<title>
<application>Wireshark</application> function blocks.
</title>
<graphic entityref="WiresharkFunctionBlocks" format="PNG"/>
</figure>
</para>
<para>
The function blocks in more detail:
<variablelist>
<varlistentry><term><command>GTK+ 2</command></term>
<listitem>
<para>
Handling of all user input/output (all windows, dialogs and such).
Source code can be found in the <filename>gtk</filename> directory.
</para>
</listitem>
</varlistentry>
<varlistentry><term><command>Core</command></term>
<listitem>
<para>
Main "glue code" that holds the other blocks together. Source
code can be found in the root directory.
</para>
</listitem>
</varlistentry>
<varlistentry><term><command>Epan</command></term>
<listitem>
<para>
Ethereal Packet ANalyzer - the packet analyzing engine.
Source code can be found in the <filename>epan</filename> directory.
</para>
<itemizedlist>
<listitem>
<para>
Protocol-Tree - Keep data of the capture file protocol information.
</para>
</listitem>
<listitem>
<para>
Dissectors - The various protocol dissectors in
<filename>epan/dissectors</filename>.
</para>
</listitem>
<listitem>
<para>
Dissector-Plugins - Some of the protocol dissectors are implemented
as plugins. Source code can be found in <filename>plugins</filename>.
</para>
</listitem>
<listitem>
<para>
Display-Filters - the display filter engine at
<filename>epan/dfilter</filename>.
</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry><term><command>Wiretap</command></term>
<listitem>
<para>
The wiretap library is used to read/write capture files in libpcap
and a lot of other file formats. Source code in the
<filename>wiretap</filename> directory.
</para>
</listitem>
</varlistentry>
<varlistentry><term><command>Capture</command></term>
<listitem>
<para>
The interface with the capture engine. Source code in the
root directory.
</para>
</listitem>
</varlistentry>
<varlistentry><term><command>Dumpcap</command></term>
<listitem>
<para>
The capture engine itself. This is the only part that is to execute
with elevated privileges. Source code in the root directory.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>WinPcap / libpcap (not part of the Wireshark package)</command></term>
<listitem>
<para>
The platform dependent packet capture library, including the capture
filter engine. That's the reason why we still have different display
and capture filter syntax, as two different filtering engines are used.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</section>
<section id="ChWorksCapturePackets">
<title>Capturing packets</title>
<para>
Capturing will take packets from a network adapter, and save them to a file
on your harddisk.
</para>
<para>
Since raw network adapter access requires elevated privileges these functions
are isolated into the dumpcap program. It's only this program that needs these
privileges, allowing the main part of the code (dissectors, user interface,
etc) to run as normal user program.
</para>
<para>
To hide all the lowlevel machine dependent details from
Wireshark, the libpcap/WinPcap (see <xref linkend="ChLibsPcap"/>) library
is used. This library provides a general purpose interface to capture
packets from a lot of different network interface types (Ethernet,
Token Ring, ...).
</para>
</section>
<section id="ChWorksCaptureFiles">
<title>Capture Files</title>
<para>
Wireshark can read and write capture files in its natural file format, the
libpcap format, which is used by many other network capturing tools,
e.g. tcpdump. In addition to this, as one of its strengths,
Wireshark can read/write files in many different file formats of other
network capturing tools. The wiretap library, developed together with
Wireshark, provides a general purpose interface to read/write all the file
formats. If you need to add another capture file format, this is the place
to start.
</para>
</section>
<section id="ChWorksDissectPackets">
<title>Dissect packets</title>
<para>
While Wireshark is loading packets from a file, each packet is dissected.
Wireshark tries to detect the packet type and gets as much
information from the packet as possible. In this run though, only the information shown
in the packet list pane is needed.
</para>
<para>
As the user selects a specific packet in the packet list pane, this packet
will be dissected again. This time, Wireshark tries to
get every single piece of information and put it into
the packet details pane.
</para>
</section>
</chapter>
<!-- End of WSDG Chapter Works -->