osmith
/
wireshark
forked from osmocom/wireshark
1
0
Fork 0
Code Pull Requests Releases Wiki Activity

Docs: Make our AsciiDoc markup more compatible with AsciiDoctor. 

Start using markup that is preferred by Asciidoctor but compatible with
both generators.

Add a missing "cpp" attribute and set a couple of Asciidoctor-specific
compatibility attributes.

Change-Id: Iff4c31362e4493b97a85f46db2c39b18c336536f
Reviewed-on: https://code.wireshark.org/review/25600
Reviewed-by: Gerald Combs <gerald@wireshark.org>
This commit is contained in:
Gerald Combs 2018-02-04 11:39:56 -08:00
parent bb2680d9b4
commit df088de18b
24 changed files with 401 additions and 386 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docbook/asciidoctor-asciidoc.conf
View File

@ -22,6 +22,7 @@ caret=^
plus=&#43;
space=" "
tilde=~
cpp=C++
user-home={eval:os.path.expanduser('~')}
vbar=|
# NOTE use -a no-inline-literal to set compat-mode to default when using AsciiDoc Python

4
docbook/attributes.asciidoc
View File

@ -1,6 +1,10 @@
// Common attributes
:wireshark-version: 2.5.0
// We're migrating from AsciiDoc.
:compat-mode:
// Required for btn, kbd:, and menu: macros.
:experimental:
//
// URLs

9
docbook/common_src/typographic_conventions.asciidoc
View File

@ -6,11 +6,18 @@ The following table shows the typographic conventions that are used in this guid
// https://github.com/oreillymedia/orm_book_samples/blob/master/asciidoc_only/preface.asciidoc
// AsciiDoc allows alternative markup for some styles, specifially
// 'single quotes' and _underlines_ for italics and +plus signs+ and
// `backticks` for monospaces.
// Asciidoctor's modern mode is more strict, and only allows _underline_
// italics and `backtick` monospaces.
// http://asciidoctor.org/docs/migration/
.Typographic Conventions
[options="header",cols="1,3,3"]
|===============
|Style|Description|Example
|'Italic' |File names, folder names, and extensions |'C:\Development\wireshark'.
|_Italic_ |File names, folder names, and extensions |_C:\Development\wireshark_.
|`Monospace` |Commands, flags, and environment variables|CMake's `-G` option.
|**`Bold Monospace`** |Commands that should be run by the user|Run **`cmake -G Ninja ..`**.
|btn:[Button] |Dialog and window buttons |Press btn:[Launch] to go to the Moon.

5
docbook/developer-guide.asciidoc
View File

@ -3,6 +3,11 @@
:doctype: book
include::attributes.asciidoc[]
// Convenience attribute.
// XXX This should be surrounded by single quotes in the text. It's
// currently surrounded by plus signs for AsciiDoc compatibility.
:dlt-glob: DLT_*
[[Preface]]
["preface",id="Preface"]
== Preface

6
docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
View File

@ -12,11 +12,11 @@
Wireshark consists of the following major parts:
* Packet dissection - in the '/epan/dissector' and '/plugin/*' directories
* 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'
* Capture - using the libpcap/winpcap library, in _/wiretap_
* User interface - using the Qt or $$GTK+$$ and associated libraries
@ -29,7 +29,7 @@ Wireshark consists of the following major parts:
=== Coding Style
The coding style guides for Wireshark can be found in the "Code style"
section of the file 'doc/README.developer'.
section of the file _doc/README.developer_.
[[ChCodeGLib]]

60
docbook/wsdg_src/WSDG_chapter_capture.asciidoc
View File

@ -1,7 +1,7 @@
++++++++++++++++++++++++++++++++++++++
<!-- WSDG Chapter Capture -->
++++++++++++++++++++++++++++++++++++++
[[ChapterCapture]]
== Packet capturing
@ -17,12 +17,12 @@ This chapter needs to be reviewed and extended.
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 libpcap, the first thing you'd need to do would be to get +{dlt-glob}+ 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
link-layer protocol, they might be able to share a +{dlt-glob}+ 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.
+{dlt-glob}+ 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
@ -30,45 +30,45 @@ 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
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'.
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.
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-glob}+ 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-glob}+ 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-glob}+ 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+
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
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+.
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+
If there's more than one +{dlt-glob}+ 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
For Wireshark, you'd add support for those +{dlt-glob}+ 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()+.
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 -->
++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++

132
docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
View File

@ -36,7 +36,7 @@ the finished code may make more sense as a built-in dissector.
[NOTE]
.Read README.dissector
====
The file 'doc/README.dissector' contains detailed information about implementing
The file _doc/README.dissector_ contains detailed information about implementing
a dissector. In many cases it is more up to date than this document.
====
@ -93,18 +93,18 @@ proto_register_foo(void)
Let's go through this a bit at a time. First we have some boilerplate
include files. These will be pretty constant to start with.
Next we have an int that is initialised to +$$-1$$+ that records our protocol.
Next we have an int that is initialised to `-1` that records our protocol.
This will get updated when we register this dissector with the main program.
It's good practice to make all variables and functions that aren't exported
static to keep name space pollution down. Normally this isn't a problem unless your
dissector gets so big it has to span multiple files.
Then a +#define+ for the UDP port that carries _foo_ traffic.
Then a `#define` for the UDP port that carries _foo_ traffic.
Now that we have the basics in place to interact with the main program, we'll
start with two protocol dissector setup functions.
First we'll call +proto_register_protocol()+ which registers the protocol. We
First we'll call `proto_register_protocol()` which registers the protocol. We
can give it three names that will be used for display in various places. The
full and short name are used in e.g. the "Preferences" and "Enabled protocols"
dialogs as well as the generated field name list in the documentation. The
@ -132,8 +132,8 @@ be called to do the actual dissecting. Then we associate the handle with a UDP
port number so that the main program will know to call us when it gets UDP
traffic on that port.
The standard Wireshark dissector convention is to put +proto_register_foo()+ and
+proto_reg_handoff_foo()+ as the last two functions in the dissector source.
The standard Wireshark dissector convention is to put `proto_register_foo()` and
`proto_reg_handoff_foo()` as the last two functions in the dissector source.
Now at last we get to write some dissecting code. For the moment we'll
leave it as a basic placeholder.
@ -168,19 +168,19 @@ At this point we should have a basic dissector ready to compile and install.
It doesn't do much at present, other than identify the protocol and label it.
In order to compile this dissector and create a plugin a couple of support files
are required, besides the dissector source in 'packet-foo.c':
are required, besides the dissector source in _packet-foo.c_:
* 'Makefile.am' - The UNIX/Linux makefile template.
* _Makefile.am_ - The UNIX/Linux makefile template.
* 'CMakeLists.txt' - Contains the CMake file and version info for this plugin.
* _CMakeLists.txt_ - Contains the CMake file and version info for this plugin.
* 'packet-foo.c' - Your dissector source.
* _packet-foo.c_ - Your dissector source.
* 'plugin.rc.in' - Contains the DLL resource template for Windows. (optional)
* _plugin.rc.in_ - Contains the DLL resource template for Windows. (optional)
You can find a good example for these files in the gryphon plugin directory.
'Makefile.am' has to be modified to reflect the relevant files and dissector
name. 'CMakeLists.txt' has to be modified with the correct
_Makefile.am_ has to be modified to reflect the relevant files and dissector
name. _CMakeLists.txt_ has to be modified with the correct
plugin name and version info, along with the relevant files to compile.
In the main top-level source directory, copy CMakeListsCustom.txt.example to
CMakeListsCustom.txt and add the path of your plugin to the list in
@ -226,7 +226,7 @@ up the display when not required.
We are also marking the area of data that is being consumed by this
protocol. In our case it's all that has been passed to us, as we're assuming
this protocol does not encapsulate another.
Therefore, we add the new tree node with +proto_tree_add_item()+,
Therefore, we add the new tree node with `proto_tree_add_item()`,
adding it to the passed in tree, label it with the protocol, use the passed in
tvb buffer as the data, and consume from 0 to the end (-1) of this data.
ENC_NA ("not applicable") is specified as the "encoding" parameter.
@ -236,11 +236,11 @@ and selecting this will highlight the remaining contents of the packet.
Now let's go to the next step and add some protocol dissection. For this step
we'll need to construct a couple of tables that help with dissection. This needs
some additions to the +proto_register_foo()+ function shown previously.
some additions to the `proto_register_foo()` function shown previously.
Two statically allocated arrays are added at the beginning of
+proto_register_foo()+. The arrays are then registered after the call to
+proto_register_protocol()+.
`proto_register_foo()`. The arrays are then registered after the call to
`proto_register_protocol()`.
.Registering data structures.
====
@ -274,7 +274,7 @@ proto_register_foo(void)
----
====
The variables +hf_foo_pdu_type+ and +ett_foo+ also need to be declared somewhere near the top of the file.
The variables `hf_foo_pdu_type` and `ett_foo` also need to be declared somewhere near the top of the file.
.Dissector data structure globals.
====
@ -300,34 +300,34 @@ Now the dissection is starting to look more interesting. We have picked apart
our first bit of the protocol. One byte of data at the start of the packet
that defines the packet type for foo protocol.
The +proto_item_add_subtree()+ call has added a child node
The `proto_item_add_subtree()` call has added a child node
to the protocol tree which is where we will do our detail dissection.
The expansion of this node is controlled by the +ett_foo+
The expansion of this node is controlled by the `ett_foo`
variable. This remembers if the node should be expanded or not as you move
between packets. All subsequent dissection will be added to this tree,
as you can see from the next call.
A call to +proto_tree_add_item()+ in the foo_tree,
this time using the +hf_foo_pdu_type+ to control the formatting
A call to `proto_tree_add_item()` in the foo_tree,
this time using the `hf_foo_pdu_type` to control the formatting
of the item. The pdu type is one byte of data, starting at 0. We assume it is
in network order (also called big endian), so that is why we use +ENC_BIG_ENDIAN+.
in network order (also called big endian), so that is why we use `ENC_BIG_ENDIAN`.
For a 1-byte quantity, there is no order issue, but it is good practice to
make this the same as any multibyte fields that may be present, and as we will
see in the next section, this particular protocol uses network order.
If we look in detail at the +hf_foo_pdu_type+ declaration in
If we look in detail at the `hf_foo_pdu_type` declaration in
the static array we can see the details of the definition.
* 'hf_foo_pdu_type' - The index for this node.
* _hf_foo_pdu_type_ - The index for this node.
* 'FOO PDU Type' - The label for this item.
* _FOO PDU Type_ - The label for this item.
* 'foo.type' - This is the filter string. It enables us to type constructs such
as +foo.type=1+ into the filter box.
* _foo.type_ - This is the filter string. It enables us to type constructs such
as `foo.type=1` into the filter box.
* 'FT_UINT8' - This specifies this item is an 8bit unsigned integer.
* _FT_UINT8_ - This specifies this item is an 8bit unsigned integer.
This tallies with our call above where we tell it to only look at one byte.
* 'BASE_DEC' - For an integer type, this tells it to be printed as a decimal
* _BASE_DEC_ - For an integer type, this tells it to be printed as a decimal
number. It could be hexadecimal (BASE_HEX) or octal (BASE_OCT) if that made more sense.
We'll ignore the rest of the structure for now.
@ -425,7 +425,7 @@ static const value_string packettypenames[] = {
This is a handy data structure that can be used to look up a name for a value.
There are routines to directly access this lookup table, but we don't need to
do that, as the support code already has that added in. We just have to give
these details to the appropriate part of the data, using the +VALS+ macro.
these details to the appropriate part of the data, using the `VALS` macro.
.Adding Names to the protocol.
====
@ -498,7 +498,7 @@ proto_register_foo(void) {
====
Some things to note here. For the flags, as each bit is a different flag, we use
the type +FT_BOOLEAN+, as the flag is either on or off. Second, we include the flag
the type `FT_BOOLEAN`, as the flag is either on or off. Second, we include the flag
mask in the 7th field of the data, which allows the system to mask the relevant bit.
We've also changed the 5th field to 8, to indicate that we are looking at an 8 bit
quantity when the flags are extracted. Then finally we add the extra constructs
@ -509,7 +509,7 @@ other things we can do to make things look even more pretty. At the moment our
dissection shows the packets as "Foo Protocol" which whilst correct is a little
uninformative. We can enhance this by adding a little more detail. First, let's
get hold of the actual value of the protocol type. We can use the handy function
+tvb_get_guint8()+ to do this. With this value in hand, there are a couple of
`tvb_get_guint8()` to do this. With this value in hand, there are a couple of
things we can do. First we can set the INFO column of the non-detailed view to
show what sort of PDU it is - which is extremely helpful when looking at
protocol traces. Second, we can also display this information in the dissection
@ -543,7 +543,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
====
So here, after grabbing the value of the first 8 bits, we use it with one of the
built-in utility routines +val_to_str()+, to lookup the value. If the value
built-in utility routines `val_to_str()`, to lookup the value. If the value
isn't found we provide a fallback which just prints the value in hex. We use
this twice, once in the INFO field of the columns -- if it's displayed, and
similarly we append this data to the base of our dissecting tree.
@ -598,16 +598,16 @@ within the protocol. If it's not, it may be part of the compression routine to
work it out for you, in which case the logic would be different.
So armed with the size, a buffer is allocated to receive the uncompressed data
using +wmem_alloc()+ in pinfo->pool memory, and the packet is decompressed into
it. The +tvb_get_ptr()+ function is useful to get a pointer to the raw data of
using `wmem_alloc()` in pinfo->pool memory, and the packet is decompressed into
it. The `tvb_get_ptr()` function is useful to get a pointer to the raw data of
the packet from the offset onwards. In this case the decompression routine also
needs to know the length, which is given by the
+tvb_captured_length_remaining()+ function.
`tvb_captured_length_remaining()` function.
Next we build a new tvb buffer from this data, using the
+tvb_new_child_real_data()+ call. This data is a child of our original data, so
`tvb_new_child_real_data()` call. This data is a child of our original data, so
calling this function also acknowledges that. No need to call
+tvb_set_free_cb()+ as the pinfo->pool was used (the memory block will be
`tvb_set_free_cb()` as the pinfo->pool was used (the memory block will be
automatically freed when the pinfo pool lifetime expires). Finally we add this
tvb as a new data source, so that the detailed display can show the
decompressed bytes as well as the original.
@ -616,7 +616,7 @@ After this has been set up the remainder of the dissector can dissect the buffer
next_tvb, as it's a new buffer the offset needs to be 0 as we start again from
the beginning of this buffer. To make the rest of the dissector work regardless
of whether compression was involved or not, in the case that compression was not
signaled, we use +tvb_new_subset_remaining()+ to deliver us a new buffer based
signaled, we use `tvb_new_subset_remaining()` to deliver us a new buffer based
on the old one but starting at the current offset, and extending to the end.
This makes dissecting the packet from this point on exactly the same regardless
of compression.
@ -634,7 +634,7 @@ arrived and then start the dissection.
The following sections will guide you through two common cases. For a
description of all possible functions, structures and parameters, see
'epan/reassemble.h'.
_epan/reassemble.h_.
[[ChDissectReassembleUdp]]
@ -694,10 +694,10 @@ if (flags & FL_FRAGMENT) { /* fragmented */
We start by saving the fragmented state of this packet, so we can restore it
later. Next comes some protocol specific stuff, to dig the fragment data out of
the stream if it's present. Having decided it is present, we let the function
+fragment_add_seq_check()+ do its work. We need to provide this with a certain
`fragment_add_seq_check()` do its work. We need to provide this with a certain
amount of parameters:
* The +msg_reassembly_table+ table is for bookkeeping and is described later.
* The `msg_reassembly_table` table is for bookkeeping and is described later.
* The tvb buffer we are dissecting.
@ -709,7 +709,7 @@ amount of parameters:
fragments in flight, and this is used to key the relevant one to be used for
reassembly.
* Optional additional data for identifying the fragment. Can be set to +NULL+
* Optional additional data for identifying the fragment. Can be set to `NULL`
(as is done in the example) for most dissectors.
* msg_num is the packet number within the sequence.
@ -760,7 +760,7 @@ unless the fragments have been reassembled as there won't be much to find.
Sometimes the first packet in the sequence can be partially decoded though if
you wish.
Now the mysterious data we passed into the +fragment_add_seq_check()+.
Now the mysterious data we passed into the `fragment_add_seq_check()`.
.Reassembling fragments - Initialisation
====
@ -776,14 +776,14 @@ proto_register_msg(void)
----
====
First a +reassembly_table+ structure is declared and initialised in the protocol
First a `reassembly_table` structure is declared and initialised in the protocol
initialisation routine. The second parameter specifies the functions that should
be used for identifying fragments. We will use
+addresses_ports_reassembly_table_functions+ in order to identify fragments by
the given sequence number (+msg_seqid+), the source and destination addresses
`addresses_ports_reassembly_table_functions` in order to identify fragments by
the given sequence number (`msg_seqid`), the source and destination addresses
and ports from the packet.
Following that, a +fragment_items+ structure is allocated and filled in with a
Following that, a `fragment_items` structure is allocated and filled in with a
series of ett items, hf data items, and a string tag. The ett and hf values
should be included in the relevant tables like all the other variables your
protocol may use. The hf variables need to be placed in the structure something
@ -883,7 +883,7 @@ from the reassembled one. The other variables are used for flagging up errors.
==== How to reassemble split TCP Packets
A dissector gets a +tvbuff_t+ pointer which holds the payload
A dissector gets a `tvbuff_t` pointer which holds the payload
of a TCP packet. This payload contains the header and data
of your application layer protocol.
@ -897,8 +897,8 @@ More than one messages can be transmitted in one TCP packet,
so that a message can start at an arbitrary position.
This sounds complicated, but there is a simple solution.
+tcp_dissect_pdus()+ does all this tcp packet reassembling for you.
This function is implemented in 'epan/dissectors/packet-tcp.h'.
`tcp_dissect_pdus()` does all this tcp packet reassembling for you.
This function is implemented in _epan/dissectors/packet-tcp.h_.
.Reassembling TCP fragments
====
@ -942,12 +942,12 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
----
====
As you can see this is really simple. Just call +tcp_dissect_pdus()+ in your
As you can see this is really simple. Just call `tcp_dissect_pdus()` in your
main dissection routine and move you message parsing code into another function.
This function gets called whenever a message has been reassembled.
The parameters tvb, pinfo, tree and data are just handed over to
+tcp_dissect_pdus()+. The 4th parameter is a flag to indicate if the data should
`tcp_dissect_pdus()`. The 4th parameter is a flag to indicate if the data should
be reassembled or not. This could be set according to a dissector preference as
well. Parameter 5 indicates how much data has at least to be available to be
able to determine the length of the foo message. Parameter 6 is a function
@ -973,7 +973,7 @@ then called on each dissection. Some arbitrary protocol specific data
is provided with the routine that can be used.
To create a tap, you first need to register a tap. A tap is registered with an
integer handle, and registered with the routine +register_tap()+. This takes a
integer handle, and registered with the routine `register_tap()`. This takes a
string name with which to find it again.
.Initialising a tap
@ -1007,7 +1007,7 @@ included in a header file so that it can be included by other components that
want to listen in to the tap.
Once you have these defined, it's simply a case of populating the protocol
specific structure and then calling +tap_queue_packet+, probably as the last part
specific structure and then calling `tap_queue_packet`, probably as the last part
of the dissector.
.Calling a protocol tap
@ -1063,17 +1063,17 @@ WS_DLL_PUBLIC_DEF void plugin_register_tap_listener(void)
====
Working from the bottom up, first the plugin interface entry point is defined,
+plugin_register_tap_listener()+. This simply calls the initialisation function
+register_foo_stat_trees()+.
`plugin_register_tap_listener()`. This simply calls the initialisation function
`register_foo_stat_trees()`.
This in turn calls the +stats_tree_register_plugin()+ function, which takes three
This in turn calls the `stats_tree_register_plugin()` function, which takes three
strings, an integer, and three callback functions.
. This is the tap name that is registered.
. An abbreviation of the stats name.
. The name of the stats module. A $$'/'$$ character can be used to make sub menus.
. The name of the stats module. A `/' character can be used to make sub menus.
. Flags for per-packet callback
@ -1121,8 +1121,8 @@ static int foo_stats_tree_packet(stats_tree* st, packet_info* pinfo, epan_dissec
====
In this case the processing of the stats is quite simple. First we call the
+tick_stat_node+ for the +st_str_packets+ packet node, to count packets. Then a
call to +stats_tree_tick_pivot()+ on the +st_node_packet_types+ subtree allows
`tick_stat_node` for the `st_str_packets` packet node, to count packets. Then a
call to `stats_tree_tick_pivot()` on the `st_node_packet_types` subtree allows
us to record statistics by packet type.
[[ChDissectConversation]]
@ -1130,7 +1130,7 @@ us to record statistics by packet type.
=== How to use conversations
Some info about how to use conversations in a dissector can be found in the file
'doc/README.dissector', chapter 2.2.
_doc/README.dissector_, chapter 2.2.
[[ChDissectIdl2wrs]]
@ -1146,7 +1146,7 @@ file and attempts to build a dissector that can decode the IDL traffic over
GIOP. The resulting file is ``C'' code, that should compile okay as a Wireshark
dissector.
+idl2wrs+ parses the data struct given to it by the `omniidl` compiler,
`idl2wrs` parses the data struct given to it by the `omniidl` compiler,
and using the GIOP API available in packet-giop.[ch], generates get_CDR_xxx
calls to decode the CORBA traffic on the wire.
@ -1183,9 +1183,9 @@ It is also COOL to work on a great Open Source project such as the case with
To use the idl2wrs to generate Wireshark dissectors, you need the following:
* Python must be installed. See link:$$http://python.org/$$[]
* Python must be installed. See link:http://python.org/[]
* +omniidl+ from the omniORB package must be available. See link:$$http://omniorb.sourceforge.net/$$[]
* `omniidl` from the omniORB package must be available. See link:http://omniorb.sourceforge.net/[]
* Of course you need Wireshark installed to compile the code and tweak it if
required. idl2wrs is part of the standard Wireshark distribution

10
docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
View File

@ -128,7 +128,7 @@ Wireshark mailing lists available.
==== Programming languages used
Most of Wireshark is implemented in plain ANSI C. A notable exception is
the code in 'ui/qt', which is written in $$C++$$.
the code in _ui/qt_, which is written in {cpp}.
The typical task for a new Wireshark developer is to extend an existing,
or write a new dissector for a specific network protocol. As (almost) any
@ -375,15 +375,15 @@ typically more up to date and the HTML format is easier to use.
If you don't find the information you need inside this book, there are
various other sources of information:
* The file 'doc/README.developer' and all the other README.xxx files in the
* The file _doc/README.developer_ and all the other README.xxx files in the
source code. These are various documentation files on different topics
[NOTE]
.Read the README
====
'README.developer' is packed full with all kinds of details relevant
_README.developer_ is packed full with all kinds of details relevant
to the developer of Wireshark source code. Its companion file
'README.dissector' advises you around common
_README.dissector_ advises you around common
pitfalls, shows you basic layout of dissector code, shows details of the
APIs available to the dissector developer, etc.
====
@ -538,7 +538,7 @@ echoed. The ^D
(Control-D, that is, press the Control key and the D key
together) will cause `gdb` to exit. This will
leave you with a file called
'bt.txt' in the current directory.
_bt.txt_ in the current directory.
Include the file with your bug report.
If you do not have `gdb` available, you

12
docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
View File

@ -13,11 +13,11 @@
Several libraries are needed to build and run Wireshark. Most of them
are split into three packages:
. 'Runtime'. System and third party libraries such as 'MSVCR110.dll' and 'libglib-2.0-0.dll'.
. _Runtime_. System and third party libraries such as _MSVCR110.dll_ and _libglib-2.0-0.dll_.
. 'Developer'. Documentation, header files, import libraries, and other files needed for compilation.
. _Developer_. Documentation, header files, import libraries, and other files needed for compilation.
. 'Source'. Library sources, which are usually not required to
. _Source_. Library sources, which are usually not required to
build Wireshark.
[TIP]
@ -99,8 +99,8 @@ For more information on the Qt libraries, see <<ChUIQt>>.
Most Linux distributions provide Qt and its development libraries as standard packages.
The required libraries and tools will likely be split across several packages. For example,
building on Ubuntu requires 'qttools5-dev', 'qttools5-dev-tools', 'libqt5svg5-dev,
'qtmultimedia5-dev', and possibly others.
building on Ubuntu requires _qttools5-dev_, _qttools5-dev-tools_, _libqt5svg5-dev_,
_qtmultimedia5-dev_, and possibly others.
The Qt Project provides an installation tool for macOS, similar to Windows.
It is available at https://www.qt.io/download-open-source/#section-2[].
@ -243,7 +243,7 @@ platform, you can get it at {tcpdump-main-url}.
==== Win32 MSVC: WinPcap
You can get the "Windows packet capture library" at:
You can get the ``Windows packet capture library'' at:
https://www.winpcap.org/install/[]
[[ChLibsGNUTLS]]

38
docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
View File

@ -65,7 +65,7 @@ You need to install, in exactly this order:
. C compiler:
https://go.microsoft.com/fwlink/?LinkId=532606&clcid=0x409[Download]
and install "Microsoft Visual Studio 2015 Community Edition." This is a small
and install ``Microsoft Visual Studio 2015 Community Edition.'' This is a small
download that then downloads all the other required parts (which are quite large).
Select the "Custom" install and then uncheck all the optional components other
@ -120,9 +120,9 @@ Note that installation of separate Qt components are required for 32 bit
and 64 bit builds, e.g. ``msvc2015 32-bit'' and ``msvc2015 64-bit''. The
environment variable `QT5_BASE_DIR` should be set as appropriate for your
environment and should point to the Qt directory that contains the bin
directory, e.g. 'C:\Qt\5.9.1\msvc2015_64'
directory, e.g. _C:\Qt\5.9.1\msvc2015_64_
The Qt maintenance tool ('C:\Qt\MaintenanceTool.exe') can be used to
The Qt maintenance tool (_C:\Qt\MaintenanceTool.exe_) can be used to
upgrade Qt to newer versions.
[[ChSetupCygwin]]
@ -177,7 +177,7 @@ PS$>choco install cyg-get
----
//PS$>choco install sed asciidoc [...] -source cygwin
Chocolatey installs Cygwin in 'C:\tools\cygwin' by default.
Chocolatey installs Cygwin in _C:\tools\cygwin_ by default.
You can directly download packages via `cyg-get`
@ -197,9 +197,9 @@ PS$>choco install winflexbison
==== Install Python
Get the Python 3.5 or 2.7 installer from http://python.org/download/[] and
install Python into the default location ('C:\Python35' or 'C:\Python27').
install Python into the default location (_C:\Python35_ or _C:\Python27_).
Why is this recommended? Cygwin's '/usr/bin/python' is a Cygwin-specific
Why is this recommended? Cygwin's _/usr/bin/python_ is a Cygwin-specific
symbolic link which cannot be run from Windows. The native package is faster
as well.
@ -215,7 +215,7 @@ or
PS$>choco install python2
----
Chocolatey installs Python in 'C:\tools\python3' and 'C:\tools\python2' by default.
Chocolatey installs Python in _C:\tools\python3_ and _C:\tools\python2_ by default.
[[ChSetupGit]]
@ -235,9 +235,9 @@ available at the URLs below or via https://chocolatey.org/[Chocolatey].
Note that many of the GUI interfaces depend on the command line version.
If installing the Windows version of git select the
'Use Git from the Windows Command Prompt' (in chocolatey the '/GitOnlyOnPath'
option). Do *not* select the 'Use Git and optional Unix tools from the Windows Command Prompt'
option (in chocolatey the '/GitAndUnixToolsOnPath' option).
_Use Git from the Windows Command Prompt_ (in chocolatey the _/GitOnlyOnPath_
option). Do *not* select the _Use Git and optional Unix tools from the Windows Command Prompt_
option (in chocolatey the _/GitAndUnixToolsOnPath_ option).
===== The Official Windows Installer
@ -296,7 +296,7 @@ Git Extensions but any other Git client should work as well.
// XXX -
*Download sources* Download Wireshark sources into
'C:\Development\wireshark' using either the command line or Git Extensions:
_C:\Development\wireshark_ using either the command line or Git Extensions:
Using the command line:
@ -316,9 +316,9 @@ Using Git extensions:
+
Repository to clone: *`https://code.wireshark.org/review/wireshark`*
+
Destination: Your top-level development directory, e.g. 'C:\Development'.
Destination: Your top-level development directory, e.g. _C:\Development_.
+
Subdirectory to create: Anything you'd like. Usually 'wireshark'.
Subdirectory to create: Anything you'd like. Usually _wireshark_.
+
[TIP]
.Check your paths
@ -478,7 +478,7 @@ to build Wireshark.
version, e.g.: Version {wireshark-version}-myprotocol123
congratulations! You have compiled your own version of Wireshark!
You may also open the Wireshark solution file ('Wireshark.sln') in the Visual Studio IDE and build there.
You may also open the Wireshark solution file (_Wireshark.sln_) in the Visual Studio IDE and build there.
TIP: If compilation fails for suspicious reasons after you changed some source
files try to clean the build files by running *`msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln /t:Clean`*
@ -494,7 +494,7 @@ on using the <<ChToolsDebugger, Debugger Tools>>.
==== Optional: Create User's and Developer's Guide
Detailed information to build these guides can be found in the file
'docbook\README.txt' in the Wireshark sources.
_docbook\README.txt_ in the Wireshark sources.
==== Optional: Create a Wireshark Installer
@ -502,7 +502,7 @@ Note: You should have successfully built Wireshark
before doing the following.
If you want to build your own
'Wireshark-win32-{wireshark-version}-myprotocol123.exe',
_Wireshark-win32-{wireshark-version}-myprotocol123.exe_,
you'll need NSIS.
. NSIS:
@ -512,13 +512,13 @@ Note that the 32-bit version of NSIS will work for both 32-bit and
64-bit versions of Wireshark. NSIS v3 is recommended and may be required
in the future.
Note: If you do not yet have a copy of vcredist_x86.exe or vcredist_x64.exe in './wireshark-win**XX**-libs' (where *'XX'* is 32 or 64) you will need to download the appropriate file and place it in './wireshark-win**XX**-libs' before starting this step.
Note: If you do not yet have a copy of vcredist_x86.exe or vcredist_x64.exe in _./wireshark-win**XX**-libs_ (where *_XX_* is 32 or 64) you will need to download the appropriate file and place it in _./wireshark-win**XX**-libs_ before starting this step.
If building an x86 version using a Visual Studio "Express" edition or an x64 version with any edition, then you must have the appropriate vcredist file for your compiler in the support libraries directory ('vcredist_x86.exe' in 'wireshark-32-libs' or 'vcredist_x64.exe' in 'wireshark-win64-libs').
If building an x86 version using a Visual Studio "Express" edition or an x64 version with any edition, then you must have the appropriate vcredist file for your compiler in the support libraries directory (_vcredist_x86.exe_ in _wireshark-32-libs_ or _vcredist_x64.exe_ in _wireshark-win64-libs_).
The files can be located in the Visual Studio install directory for non-Express edition builds, or downloaded from Microsoft for Expresss edition builds.
Note you must use the correct version of vcredist for your compiler, unfortunately they all have the same name ('vcredist_x86.exe' or 'vcredist_x64.exe'). You can use Windows Explorer and examine the `Properties -> Details' tab for a vcredist file to determine which compiler version the file is for use with.
Note you must use the correct version of vcredist for your compiler, unfortunately they all have the same name (_vcredist_x86.exe_ or _vcredist_x64.exe_). You can use Windows Explorer and examine the `Properties -> Details' tab for a vcredist file to determine which compiler version the file is for use with.
. If you've closed the Visual Studio Command Prompt <<ChSetupPrepareCommandCom,prepare>> it again.

80
docbook/wsdg_src/WSDG_chapter_sources.asciidoc
View File

@ -84,8 +84,8 @@ http://en.wikipedia.org/wiki/Branching_%28revision_control%29[branching] to
manage different copies of the source code and allow parallel development.
Wireshark uses the following branches for official releases:
* 'master': Main feature development and odd-numbered "feature" releases.
* 'master-x.y': Stable release maintenance. For example, master-1.10 is used
* _master_: Main feature development and odd-numbered "feature" releases.
* _master-x.y_: Stable release maintenance. For example, master-1.10 is used
to manage the 1.10.x official releases.
[[ChSrcObtain]]
@ -155,7 +155,7 @@ select _Settings_.
. Under _Profile_ set a username. This will be the username that
you use for SSH access. For the steps below we'll assume that your
username is +henry.perry+.
username is `henry.perry`.
. Select _SSH Public Keys_ and add one or more keys. You will typically
upload a key for each computer that you use.
@ -361,7 +361,7 @@ error-prone than using Git.
The sources contain several documentation files. It's a good idea to read these
files first. After obtaining the sources, tools and libraries, the first place
to look at is 'doc/README.developer'. Inside you will find the latest
to look at is _doc/README.developer_. Inside you will find the latest
information for Wireshark development for all supported platforms.
.Build Wireshark before changing anything
@ -731,15 +731,15 @@ as described at <<ChSrcGit>>.
Some tips that will make the merging of your changes into Git much more likely
(and you want exactly that, don't you?):
* 'Use the latest Git sources.' It's a good idea to work with the same
* _Use the latest Git sources._ It's a good idea to work with the same
sources that are used by the other developers. This usually makes it much
easier to apply your patch. For information about the different ways to get
the sources, see <<ChSrcObtain>>.
* 'Update your sources just before making a patch.' For the same reasons as the
* _Update your sources just before making a patch._ For the same reasons as the
previous point.
* 'Inspect your patch carefully.' Run `git diff` and make sure you aren't
* _Inspect your patch carefully._ Run `git diff` and make sure you aren't
adding, removing, or omitting anything you shouldn't.
// * 'Do a "make clean" before generating the patch.' This removes a lot of
@ -748,11 +748,11 @@ Some tips that will make the merging of your changes into Git much more likely
// the patch again.
// XXX - What *are* good topic names?
* 'Find a good descriptive topic name for your patch.' Short, specific
names are preferred. 'snowcone-machine-protocol' is good, your name or
* _Find a good descriptive topic name for your patch._ Short, specific
names are preferred. _snowcone-machine-protocol_ is good, your name or
your company name isn't.
* 'Don't put unrelated things into one large patch.' A few smaller patches are
* _Don't put unrelated things into one large patch._ A few smaller patches are
usually easier to apply (but also don't put every changed line into a separate
patch.
@ -785,13 +785,13 @@ Ignoring the code requirements will make it very likely that your patch will
be rejected.
====
* 'Follow the Wireshark source code style guide.' Just because something
* _Follow the Wireshark source code style guide._ Just because something
compiles on your platform, that doesn't mean it'll compile on all of the other
platforms for which Wireshark is built. Wireshark runs on many platforms, and
can be compiled with a number of different compilers. See <<ChCodeStyle>>for
details.
* 'Submit dissectors as built-in whenever possible.' Developing a new dissector
* _Submit dissectors as built-in whenever possible._ Developing a new dissector
as a plugin is a good idea because compiling and testing is quicker, but it's
best to convert dissectors to the built-in style before submitting for check in.
This reduces the number of files that must be installed with Wireshark and
@ -802,7 +802,7 @@ can easily be put into "the big pile", while some are ASN.1 based which takes a
different approach, and some multiple source file dissectors are more suitable to
be placed separately as plugins.
* 'Ensure Wireshark Git Pre-Commit Hook is in the repository.' In your local
* _Ensure Wireshark Git Pre-Commit Hook is in the repository._ In your local
repository directory, there will be a .git/hooks/ directory, with sample git hooks
for running automatic actions before and after git commands. You can also
optionally install other hooks that you find useful.
@ -823,7 +823,7 @@ change, you can run git commit --no-verify to skip running the hooks. Warning: u
Change-ID to your commit. In case you are not updating an existing patch you may generate
a Change-ID by running git review -i (or git commit --amend if don't use git review).
* 'Fuzz test your changes!' Fuzz testing is a very
* _Fuzz test your changes!_ Fuzz testing is a very
effective way to automatically find a lot of dissector related bugs.
You'll take a capture file containing packets affecting your dissector
and the fuzz test will randomly change bytes in this file, so that unusual
@ -943,11 +943,11 @@ of the patch and your source files match.
==== Using patch
Given the file 'new.diff' containing a unified diff,
Given the file _new.diff_ containing a unified diff,
the right way to call the patch tool depends on what the pathnames in
'new.diff' look like.
_new.diff_ look like.
If they're relative to the top-level source directory (for example, if a
patch to 'prefs.c' just has 'prefs.c' as the file name) you'd run it as:
patch to _prefs.c_ just has _prefs.c_ as the file name) you'd run it as:
----
$ patch -p0 < new.diff
@ -955,24 +955,24 @@ $ patch -p0 < new.diff
If they're relative to a higher-level directory, you'd replace 0 with the
number of higher-level directories in the path, e.g. if the names are
'wireshark.orig/prefs.c' and
'wireshark.mine/prefs.c', you'd run it with:
_wireshark.orig/prefs.c_ and
_wireshark.mine/prefs.c_, you'd run it with:
----
$ patch -p1 < new.diff
----
If they're relative to a 'subdirectory' of the top-level
directory, you'd run `patch` in 'that' directory and run it with `-p0`.
If they're relative to a _subdirectory_ of the top-level
directory, you'd run `patch` in _that_ directory and run it with `-p0`.
If you run it without `-pat` all, the patch tool
flattens path names, so that if you
have a patch file with patches to 'Makefile.am' and
'wiretap/Makefile.am',
have a patch file with patches to _Makefile.am_ and
_wiretap/Makefile.am_,
it'll try to apply the first patch to the top-level
'Makefile.am' and then apply the
'wiretap/Makefile.am' patch to the top-level
'Makefile.am' as well.
_Makefile.am_ and then apply the
_wiretap/Makefile.am_ patch to the top-level
_Makefile.am_ as well.
At which position in the filesystem should the patch tool be called?
@ -981,11 +981,11 @@ directory above that directory, you'd run it in the top-level source
directory.
If they're relative to a *subdirectory* -- for example,
if somebody did a patch to 'packet-ip.c' and ran `diff` or `git diff` in
the 'epan/dissectors' directory -- you'd run it in that subdirectory.
if somebody did a patch to _packet-ip.c_ and ran `diff` or `git diff` in
the _epan/dissectors_ directory -- you'd run it in that subdirectory.
It is preferred that people *not* submit patches like
that, especially if they're only patching files that exist in multiple
directories such as 'Makefile.am'.
directories such as _Makefile.am_.
[[ChSrcBinary]]
@ -1073,7 +1073,7 @@ installing the _qt-devel_ package.
==== macOS: .dmg packages
The macOS Package is built using macOS packaging tools, based on information
found in the source tree under 'packaging/macosx'. It must be built using
found in the source tree under _packaging/macosx_. It must be built using
CMake. In your build directory, type:
----
@ -1089,10 +1089,10 @@ to build the macOS Package.
The _Nullsoft Install System_ is a free installer generator for Windows
systems. Instructions on installing it can be found in <<ChToolsNSIS>>.
NSIS is script based. You can find the main Wireshark installer
generation script at 'packaging/nsis/wireshark.nsi'.
generation script at _packaging/nsis/wireshark.nsi_.
When building with CMake you must first build the 'nsis_package_prep' target,
followed by the 'nsis_package' target, e.g.
When building with CMake you must first build the _nsis_package_prep_ target,
followed by the _nsis_package_ target, e.g.
----
> msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
@ -1109,8 +1109,8 @@ It might take some time, even on fast machines.
====
If everything went well, you will now find something like:
'wireshark-setup-{wireshark-version}.exe' in
the 'packaging/nsis' directory in the source tree.
_wireshark-setup-{wireshark-version}.exe_ in
the _packaging/nsis_ directory in the source tree.
[[ChSrcPortableApps]]
@ -1119,7 +1119,7 @@ the 'packaging/nsis' directory in the source tree.
_PortableApps.com_ is an environment that lets users run popular applications
from portable media such as flash drives and cloud drive services.
Install the 'PortableApps.com Platform'. Install for ``all users``, which
Install the _PortableApps.com Platform_. Install for ``all users'', which
will place it in `C:\PortableApps`. Add the following apps:
- NSIS Portable (Unicode)
@ -1127,9 +1127,9 @@ will place it in `C:\PortableApps`. Add the following apps:
- PortableApps.com Launcher
- PortableApps.com AppCompactor
When building with CMake you must first build the 'nsis_package_prep' target
When building with CMake you must first build the _nsis_package_prep_ target
(which takes care of general packaging dependencies), followed by the
'portableapps_package' target, e.g.
_portableapps_package_ target, e.g.
----
> msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
@ -1144,8 +1144,8 @@ It might take some time, even on fast machines.
====
If everything went well, you will now find something like:
'WiresharkPortable_{wireshark-version}.paf.exe' in
the 'packaging/portableapps' directory.
_WiresharkPortable_{wireshark-version}.paf.exe_ in
the _packaging/portableapps_ directory.
++++++++++++++++++++++++++++++++++++++
<!-- End of WSDG Chapter Sources -->

132
docbook/wsdg_src/WSDG_chapter_tools.asciidoc
View File

@ -55,18 +55,18 @@ many of the packages required for Wireshark development. Chocolatey can be
obtained from the http://chocolatey.org[website] or from a Command Prompt:
----
C:\>@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
C:\>@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(_https://chocolatey.org/install.ps1_))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
----
or a Powershell prompt:
----
PS:\>iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
PS:\>iex ((new-object net.webclient).DownloadString(_https://chocolatey.org/install.ps1_))
----
Chocolatey sometimes installs packages in unexpected locations. Cygwin is a notable
example -- recent versions of the Cygwin package are installed in 'C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin' instead of Cygwin's default location
('C:\cygwin' or 'C:\cygwin64').
example -- recent versions of the Cygwin package are installed in _C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin_ instead of Cygwin's default location
(_C:\cygwin_ or _C:\cygwin64_).
[[ChToolsCygwin]]
@ -75,29 +75,29 @@ example -- recent versions of the Cygwin package are installed in 'C:\ProgramDat
Cygwin provides a lot of UNIX based tools on the Windows platform. It uses a UNIX
emulation layer which might be a bit slower compared to the native Windows tools,
but at an acceptable level. The installation and update is pretty easy and done
through a single utility, 'setup-x86.exe' for 32-bit Windows and
'setup-x86_64.exe' for 64-bit Windows.
through a single utility, _setup-x86.exe_ for 32-bit Windows and
_setup-x86_64.exe_ for 64-bit Windows.
Over time the Wireshark development toolchain has been migrating away from Cygwin
toward native tools and we hope to eliminate it as a requirement someday.
Although Cygwin consists of several separate packages, the installation
and update is done through a single utility, 'setup-x86.exe' or
'setup-x86_64.exe', which acts similarly to other web based installers.
and update is done through a single utility, _setup-x86.exe_ or
_setup-x86_64.exe_, which acts similarly to other web based installers.
You can install Cygwin and its packages using Chocolatey, but this is not
recommended due to Chocolatey's default installation location, described
in the previous section.
==== Installing Cygwin using the Cygwin installer
You will find 'setup-x86.exe', for 32-bit systems, and
'setup-x86_64.exe', for 64-bit systems, at
You will find _setup-x86.exe_, for 32-bit systems, and
_setup-x86_64.exe_, for 64-bit systems, at
http://www.cygwin.com/install.html[]. Click on the link for the
appropriate setup utility to download it. After the download completes,
run it.
All tools will be installed into one base folder. The default is
'C:\cygwin' for the 32-bit installer and 'C:\cygwin64' for the 64-bit
_C:\cygwin_ for the 32-bit installer and _C:\cygwin64_ for the 64-bit
installer.
The setup utility will ask you for some settings. The defaults
@ -134,15 +134,15 @@ number will be displayed, so it will be automatically updated. You can
change the current setting by simply clicking at it, it will change
between:
* 'A specific version number.' This specific package version will be installed.
* _A specific version number._ This specific package version will be installed.
* 'Skip.' Not installed, no changes.
* _Skip._ Not installed, no changes.
* 'Keep.' Already installed, no changes.
* _Keep._ Already installed, no changes.
* 'Uninstall.' Uninstall this package.
* _Uninstall._ Uninstall this package.
* 'Reinstall.' Reinstall this package.
* _Reinstall._ Reinstall this package.
==== Installing Cygwin using Chocolatey
@ -155,7 +155,7 @@ PS$>choco install cygwin
PS$>choco install cyg-get
----
Chocolatey installs Cygwin in 'C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin' by default.
Chocolatey installs Cygwin in _C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin_ by default.
One or more Cygwin packages can be installed using `cyg-get`:
@ -208,7 +208,7 @@ In particular, the macOS and Windows packages are built using CMake.
Building with CMake typically includes creating a build directory and
specifying a *generator*, aka a build tool. For example, to build
Wireshark using Ninja in the directory 'wireshark-ninja' you might
Wireshark using Ninja in the directory _wireshark-ninja_ you might
run the following commands:
----
@ -235,7 +235,7 @@ using the `-D` flag. Useful variables and generators include the following:
-DENABLE_HTML_GUIDES=ON -DENABLE_PDF_GUIDES=ON:: Build documentation
-DCMAKE_C_FLAGS='-Qunused-arguments':: Make ccache and clang work together
+++-DCMAKE_C_FLAGS='-Qunused-arguments'+++:: Make ccache and clang work together
-DPYTHON_EXECUTABLE=c:/Python27/python:: Force the Python path. Useful on Windows since Cygwin's /usrbin/python is a symlink.
@ -364,52 +364,52 @@ Your version string may vary, of course.
=== Microsoft compiler toolchain (Windows native)
To compile Wireshark on Windows using the Microsoft C/$$C++$$
To compile Wireshark on Windows using the Microsoft C/{cpp}
compiler, you'll need:
. C compiler ('cl.exe')
. C compiler (_cl.exe_)
. Assembler ('ml.exe' for 32-bit targets and 'ml64.exe' for 64-bit targets)
. Assembler (_ml.exe_ for 32-bit targets and _ml64.exe_ for 64-bit targets)
. Linker ('link.exe')
. Linker (_link.exe_)
. Resource Compiler ('rc.exe')
. Resource Compiler (_rc.exe_)
. C runtime headers and libraries (e.g. 'stdio.h', 'msvcrt.lib')
. C runtime headers and libraries (e.g. _stdio.h_, _msvcrt.lib_)
. Windows platform headers and libraries (e.g.
'windows.h', 'WSock32.lib')
_windows.h_, _WSock32.lib_)
+
// Can we drop support for CHM?
. HTML help headers and libraries ('htmlhelp.h', 'htmlhelp.lib')
. HTML help headers and libraries (_htmlhelp.h_, _htmlhelp.lib_)
==== Official Toolchain Packages And Alternatives
The official Wireshark 2.4.x releases are compiled using Microsoft Visual $$C++$$ 2015.
The Wireshark 2.2.x and 2.0.x releases are compiled using Microsoft Visual $$C++$$ 2013.
The official Wireshark 2.4.x releases are compiled using Microsoft Visual {cpp} 2015.
The Wireshark 2.2.x and 2.0.x releases are compiled using Microsoft Visual {cpp} 2013.
The Wireshark 1.12.x and 1.10.x releases were compiled using
Microsoft Visual $$C++$$ 2010 SP1.
Microsoft Visual {cpp} 2010 SP1.
The 1.8 releases were compiled using
Microsoft Visual $$C++$$ 2010 SP1 as well.
Microsoft Visual {cpp} 2010 SP1 as well.
The 1.6, 1.4, and 1.2 releases were compiled using
Microsoft Visual $$C++$$ 2008 SP1.
Microsoft Visual {cpp} 2008 SP1.
Other past releases, including the 1.0 branch,
were compiled using Microsoft Visual $$C++$$ 6.0.
were compiled using Microsoft Visual {cpp} 6.0.
Using the release compilers is recommended for Wireshark development work.
The older "Express
Edition" compilers such as Visual $$C++$$ 2010 Express Edition SP1 can be
Edition" compilers such as Visual {cpp} 2010 Express Edition SP1 can be
used but any PortableApps packages you create with them
will require the installation of a separate Visual $$C++$$
will require the installation of a separate Visual {cpp}
Redistributable package on any machine on which the PortableApps
package is to be used. See
<<msvc-runtime-redistributable>> below for more details.
However, you might already have a different Microsoft $$C++$$ compiler
However, you might already have a different Microsoft {cpp} compiler
installed. It should be possible to use any of the following with the considerations listed:
.Visual $$C++$$ 2013 Community Edition
.Visual {cpp} 2013 Community Edition
IDE + Debugger?:: Yes
@ -419,7 +419,7 @@ SDK required for 64-bit builds?:: No
CMake Generator: *`Visual Studio 12`*
.Visual $$C++$$ 2010 Express Edition
.Visual {cpp} 2010 Express Edition
IDE + Debugger?:: Yes
@ -429,13 +429,13 @@ SDK required for 64-bit builds?:: Yes.
CMake Generator: *`Visual Studio 10`*
Remarks:: Installers created using express editions require a $$C++$$ redistributable
'$$vcredist_x86.exe$$' (3MB free
Remarks:: Installers created using express editions require a {cpp} redistributable
_vcredist_x86.exe_ (3MB free
download) is required to build
Wireshark-win32-{wireshark-version}.exe, and
'$$vcredist_x64.exe$$' is required to build
_vcredist_x64.exe_ is required to build
Wireshark-win64-{wireshark-version}.exe. The version of
'$$vcredist_x86.exe$$' or '$$vcredist_x64.exe$$' _must_ match the version for your
_vcredist_x86.exe_ or _vcredist_x64.exe_ _must_ match the version for your
compiler including any service packs installed for the compiler.]
.Visual Studio 2010
@ -449,8 +449,8 @@ SDK required for 64-bit builds?:: No
CMake Generator: *`Visual Studio 10`*
Remarks:: Building a 64-bit installer
requires a a $$C++$$ redistributable
('$$vcredist_x86.exe$$').footnoteref[vcredist]
requires a a {cpp} redistributable
(_vcredist_x86.exe_).footnoteref[vcredist]
You can use Chocolatey to install Visual Studio, e.g:
@ -482,7 +482,7 @@ at the Visual Studio Command line prompt (cmd.exe):
should result in something like:
----
Microsoft (R) C/$$C++$$ Optimizing Compiler Version 18.00.31101 for x86
Microsoft (R) C/{cpp} Optimizing Compiler Version 18.00.31101 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption...
@ -531,12 +531,12 @@ they are available - but they might not be available on a user machine!
This is especially true for the C runtime DLL (msvcr*.dll), which contains the
implementation of ANSI and alike functions, e.g.: fopen(), malloc(). The DLL is
named like: msvcr'version'.dll, an abbreviation for "MicroSoft Visual C
named like: _msvcr**version**.dll_, an abbreviation for "Microsoft Visual C
Runtime". For Wireshark to work, this DLL must be available on the users
machine.
Starting with MSVC7, it is necessary to ship the C runtime DLL
(msvcr'version'.dll) together with the application installer somehow, as that
(_msvcr**version**.dll_) together with the application installer somehow, as that
DLL is possibly not available on the target system.
@ -554,7 +554,7 @@ interested reader:
* http://msdn.microsoft.com/en-us/library/ms235299.aspx[Redistributing Visual C++ Files]
In all cases where '$$vcredist_x86.exe$$' or '$$vcredist_x64.exe$$' is
In all cases where _vcredist_x86.exe_ or _vcredist_x64.exe_ is
downloaded it should be downloaded to the directory into which the support
libraries for Wireshark have been downloaded and installed. This directory is
specified by the WIRESHARK_BASE_DIR or WIRESHARK_LIB_DIR environment variables.
@ -566,42 +566,42 @@ There are three redistribution methods that MSDN
mentions for MSVC 2013 (see:
http://msdn.microsoft.com/en-us/library/vstudio/ms235316(v=vs.120).aspx["Choosing a Deployment Method"]):
. 'Using Visual $$C++$$ Redistributable Package'.
. _Using Visual {cpp} Redistributable Package._
The Microsoft libraries are installed by copying
'$$vcredist_x64.exe$$' or
'$$vcredist_x86.exe$$' to the target
_vcredist_x64.exe_ or
_vcredist_x86.exe_ to the target
machine and executing it on that machine (MSDN recommends
this for applications built with Visual Studio 2013)
. 'Using Visual $$C++$$ Redistributable Merge Modules'.
. _Using Visual {cpp} Redistributable Merge Modules._
(Loadable modules for building msi installers.
Not suitable for Wireshark's NSIS based installer)
. 'Install a particular Visual $$C++$$ assembly as a
private assembly for the application'. The
. _Install a particular Visual {cpp} assembly as a
private assembly for the application._ The
Microsoft libraries are installed by copying the folder
content of 'Microsoft.VC120.CRT' to
the target directory (e.g. 'C:\Program Files\Wireshark')
content of _Microsoft.VC120.CRT_ to
the target directory (e.g. _C:\Program Files\Wireshark_)
To save installer size, and to make a portable
version of Wireshark (which must be completely self-contained,
on a medium such as a flash drive, and not require that an
installer be run to install anything on the target machine)
possible, when building 32-bit Wireshark with MSVC2013, method
3 (copying the content of 'Microsoft.VC120.CRT')
3 (copying the content of _Microsoft.VC120.CRT_)
is used (this produces the smallest package).
==== Windows (Platform) SDK
The Windows Platform SDK (PSDK) or Windows SDK is a free
(as in beer) download and contains platform specific headers and
libraries (e.g. 'windows.h', 'WSock32.lib', etc.). As new Windows
libraries (e.g. _windows.h_, _WSock32.lib_, etc.). As new Windows
features evolve in time, updated SDK's become available that
include new and updated APIs.
When you purchase a commercial Visual Studio or use the Community Edition, it will
include an SDK. The free Express (as in beer) downloadable C compiler
versions (V$$C++$$ 2012 Express, V$$C++$$ 2012 Express, etc.) do not
versions (V{cpp} 2012 Express, V{cpp} 2012 Express, etc.) do not
contain an SDK -- you'll need to download a PSDK in order to
have the required C header files and libraries.
@ -628,7 +628,7 @@ have a look at the HHC_DIR setting in the file docbook/Makefile.
===== HTML Help Build Files (htmlhelp.c / htmlhelp.lib)
The files 'htmlhelp.c' and 'htmlhelp.lib' are required to
The files _htmlhelp.c_ and _htmlhelp.lib_ are required to
be able to open .chm files from Wireshark and show the
online help. Both files are part of the SDK (standalone (P)SDK or MSVC
since 2002).
@ -759,7 +759,7 @@ Python 2.5 or later (including Python 3) should work fine and Python 3.5 and
Python is either included or available as a package on most UNIX-like platforms.
Windows packages and source are available at http://python.org/download/[].
The Cygwin Python package is *not* recommended since '/usr/bin/python' is
The Cygwin Python package is *not* recommended since _/usr/bin/python_ is
a symbolic link, which causes confusion outside Cygwin.
You can also use Chocolatey to install Python:
@ -774,7 +774,7 @@ or
PS:\> choco install Python2
----
Chocolatey installs Python into 'C:\tools\python3' or 'C:\tools\python2' by
Chocolatey installs Python into _C:\tools\python3_ or _C:\tools\python2_ by
default. You can verify your Python version by running
----
@ -934,7 +934,7 @@ Your version string may vary.
A native Windows version of bison is available in the _winflexbison_
https://chocolatey.org/[Chocolatey] package. Note that the executable is named
'win_bison'.
_win_bison_.
Native packages are available from other sources such as
http://gnuwin32.sourceforge.net/packages/bison.htm[GnuWin]. They aren't
@ -977,7 +977,7 @@ Your version string may vary.
A native Windows version of flex is available in the _winflexbison_
https://chocolatey.org/[Chocolatey] package. Note that the executable is named
'win_flex'.
_win_flex_.
----
PS:\>choco install winflexbison
@ -1141,7 +1141,7 @@ installation should be straightforward.
=== Windows: NSIS (optional)
The NSIS (Nullsoft Scriptable Install System) is used to generate
'Wireshark-win32-{wireshark-version}.exe' from all the files
_Wireshark-win32-{wireshark-version}.exe_ from all the files
needed to be installed, including all required DLLs, plugins, and supporting
files.
@ -1158,7 +1158,7 @@ You can find more instructions on using NSIS in <<ChSrcNSIS>>.
=== Windows: PortableApps (optional)
The PortableApps.com Installer is used to generate
'WiresharkPortable-{wireshark-version}.paf.exe' from all the files
_WiresharkPortable-{wireshark-version}.paf.exe_ from all the files
needed to be installed, including all required DLLs, plugins, and supporting
files.

52
docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
View File

@ -80,12 +80,12 @@ adding new UI features much easier. It doesn't work well on Windows at
the present time, so it's recommended that you use it on macOS or Linux.
To edit and build Wireshark using Qt Cretor, open the top-level
'CMakeLists.txt' within Qt Creator. It should ask you to choose a build
_CMakeLists.txt_ within Qt Creator. It should ask you to choose a build
location. Do so. It should then ask you to run CMake. Fill in any
desired build arguments (e.g. "-D CMAKE_BUILD_TYPE=Debug" or "-D
ENABLE_GTK3=OFF") and click the ``Run CMake'' button. When that
completes select ``Build → Open Build and Run Kit Selector...'' and make
sure 'wireshark' is selected.
sure _wireshark_ is selected.
Note that Qt Creator uses output created by CMake's *CodeBlocks*
generator. If you run CMake outside of Qt Creator you should use the
@ -94,19 +94,19 @@ prompt you to re-run CMake.
==== Source Code Overview
Wireshark's `main` entry point is in 'wireshark-qt.cpp'. Command-line arguments
Wireshark's `main` entry point is in _wireshark-qt.cpp_. Command-line arguments
are processed there and the main application class (`WiresharkApplication`)
instance is created there along with the main window.
The main window along with the rest of the application resides in 'ui/qt'. Due
to its size the main window code is split into two modules, 'main_window.cpp'
and 'main_window_slots.cpp'.
The main window along with the rest of the application resides in _ui/qt_. Due
to its size the main window code is split into two modules, _main_window.cpp_
and _main_window_slots.cpp_.
Most of the modules in 'ui/qt' are dialogs. Although we follow Qt naming
Most of the modules in _ui/qt_ are dialogs. Although we follow Qt naming
conventions for class names, we follow our own conventions by separating file
name components with underscores. For example, ColoringRulesDialog is defined in
'coloring_rules_dialog.cpp', 'coloring_rules_dialog.h', and
'coloring_rules_dialog.ui'.
_coloring_rules_dialog.cpp_, _coloring_rules_dialog.h_, and
_coloring_rules_dialog.ui_.
General-purpose dialogs are subclasses of `QDialog`. Dialogs that rely on the
current capture file can subclass `WiresharkDialog`, which provides methods and
@ -117,7 +117,7 @@ open when the capture file closes.
===== Names
The code in 'ui/qt' directory uses three APIs: Qt (which uses
The code in _ui/qt_ directory uses three APIs: Qt (which uses
InterCapConvention), GLib (which uses underscore_convention), and the Wireshark
API (which also uses underscore_convention). As a general rule Wireshark's Qt
code uses InterCapConvention for class names, interCapConvention for methods,
@ -175,18 +175,18 @@ QStrings are generally *much* safer and easier to use. They also make
translations easier.
If you need to pass strings between Qt and GLib you can use a number
of convenience routines which are defined in 'ui/qt/qt_ui_utils.h'.
of convenience routines which are defined in _ui/qt/qt_ui_utils.h_.
If you're calling a function that returns wmem-allocated memory it might make
more sense to add a wrapper function to 'qt_ui_utils' than to call wmem_free in
more sense to add a wrapper function to _qt_ui_utils_ than to call wmem_free in
your code.
===== Mixing C and $$C++$$
===== Mixing C and {cpp}
Sometimes we have to call $$C++$$ functions from one of
Wireshark's C callbacks and pass $$C++$$ objects to or from C. Tap
listeners are a common example. The $$C++$$ FAQ link:$$http://www.
parashift.com/c++-faq/mixing-c-and-cpp.html$$:[describes how to do this
Sometimes we have to call {cpp} functions from one of
Wireshark's C callbacks and pass {cpp} objects to or from C. Tap
listeners are a common example. The {cpp} FAQ link:http://www.
parashift.com/c++-faq/mixing-c-and-cpp.html:[describes how to do this
safely].
Tapping usually involves declaring static methods for callbacks, passing `this`
@ -197,10 +197,10 @@ as the tap data.
Qt provides a convenient method for translating text: `Qobject::tr()`,
usually available as `tr()`.
However, please avoid using `tr()` for static strings and define them in '*.ui'
However, please avoid using `tr()` for static strings and define them in _*.ui_
files instead. `tr()` on manually created objects like `QMenu` are not
automatically retranslated and must instead be manually translated using
`changeEvent()` and `retranslateUi()`. See 'summary_dialog.[ch]' for an example
`changeEvent()` and `retranslateUi()`. See _summary_dialog.[ch]_ for an example
of this.
NOTE: If your object life is short and your components are (re)created
@ -212,16 +212,16 @@ In most cases you should handle the changeEvent in order to catch
Qt makes translating the Wireshark UI into different languages easy. To add a new
translation, do the following:
- Add your translation ('ui/qt/wireshark_XX.ts') to 'ui/qt/Makefile.am' and 'ui/qt/CMakeLists.txt'
- (Recommended) Add a flag image for your language in 'images/languages/XX.svg'. Update 'image/languages/languages.qrc' accordingly.
- Add your translation (_ui/qt/wireshark_XX.ts_) to _ui/qt/Makefile.am_ and _ui/qt/CMakeLists.txt_
- (Recommended) Add a flag image for your language in _images/languages/XX.svg_. Update _image/languages/languages.qrc_ accordingly.
- Run `lupdate ui/qt -ts ui/qt/wireshark_XX.ts` to generate/update your translation file.
- Translate with Qt Linguist: `linguist ui/qt/wireshark_XX.ts`.
- Do a test build and make sure the generated 'wireshark_XX.qm' binary file is included.
- Do a test build and make sure the generated _wireshark_XX.qm_ binary file is included.
- Push your translation to Gerrit for review. See <<ChSrcContribute>> for details.
Alternatively you can put your QM and flag files in the 'languages'
Alternatively you can put your QM and flag files in the _languages_
directory in the Wireshark user configuration directory
('$XDG_CONFIG_HOME/wireshark/languages/' or '$HOME/.wireshark/languages/' on
(_$XDG_CONFIG_HOME/wireshark/languages/_ or _$HOME/.wireshark/languages/_ on
UNIX).
For more information about Qt Linguist see
@ -254,7 +254,7 @@ doesn't meet your needs.
==== Other Issues and Information
The main window has many QActions which are shared with child widgets. See
'ui/qt/proto_tree.cpp' for an example of this.
_ui/qt/proto_tree.cpp_ for an example of this.
http://www.kdab.com/kdab-products/gammaray/[GammaRay] lets you inspect
the internals of a running Qt application similar to $$Spy++$$ on Windows.
@ -335,7 +335,7 @@ GTK 3.x depends on the following libraries:
==== Compatibility GTK versions
The GTK library itself defines some values which makes it easy to distinguish
between the versions, e.g. +GTK_MAJOR_VERSION+ and +GTK_MINOR_VERSION+ will be
between the versions, e.g. `GTK_MAJOR_VERSION` and `GTK_MINOR_VERSION` will be
set to the GTK version at compile time inside the gtkversion.h header.
[[ChUIGTKWeb]]

12
docbook/wsdg_src/WSDG_chapter_works.asciidoc
View File

@ -26,29 +26,29 @@ image::wsdg_graphics/ws-function-blocks.png[{pdf-scaledwidth}]
The function blocks in more detail:
GUI:: Handling of all user input/output (all windows, dialogs and such).
Source code can be found in the 'ui/qt' and 'ui/gtk' directory.
Source code can be found in the _ui/qt_ and _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
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'.
_epan/dissectors_.
* Dissector Plugins - Support for implementing dissectors as separate modules.
Source code can be found in 'plugins'.
Source code can be found in _plugins_.
* Display Filters - The display filter engine at
'epan/dfilter'.
_epan/dfilter_.
Wiretap:: The wiretap library is used to read and write capture files in libpcap,
pcapng, and many other file formats. Source code is in the
'wiretap' directory.
_wiretap_ directory.
Capture:: The interface with the capture engine. Source code is in the
root directory.

46
docbook/wsluarm.asciidoc
View File

@ -174,19 +174,19 @@ This Part of the User Guide describes the Wireshark specific functions in the em
Classes group certain functionality, the following notational conventions are
used:
* 'Class.function()' represents a class method (named 'function') on class
'Class', taking no arguments.
* _Class.function()_ represents a class method (named _function_) on class
_Class_, taking no arguments.
* 'Class.function(a)' represents a class method taking one argument.
* _Class.function(a)_ represents a class method taking one argument.
* 'Class.function(...)' represents a class method taking a variable number of
* _Class.function(...)_ represents a class method taking a variable number of
arguments.
* 'class:method()' represents an instance method (named 'method') on an instance
of class 'Class', taking no arguments. Note the lowercase notation in the
* _class:method()_ represents an instance method (named _method_) on an instance
of class _Class_, taking no arguments. Note the lowercase notation in the
documentation to clarify an instance.
* 'class.prop' represents a property 'prop' on the instance of class 'Class'.
* _class.prop_ represents a property _prop_ on the instance of class _Class_.
Trying to access a non-existing property, function or method currently gives an
error, but do not rely on it as the behavior may change in the future.
@ -210,7 +210,7 @@ include::{build_dir}/wsluarm_src/wslua_struct.asciidoc[]
=== GLib Regular Expressions
Lua has its own native 'pattern' syntax in the string library, but sometimes a
Lua has its own native _pattern_ syntax in the string library, but sometimes a
real regex engine is more useful. Wireshark comes with GLib's Regex
implementation, which itself is based on Perl Compatible Regular Expressions
(PCRE). This engine is exposed into Wireshark's Lua engine through the
@ -219,23 +219,23 @@ Lrexlib PCRE implementation, with a few differences as follows:
* There is no support for using custom locale/chartables
* 'dfa_exec()' doesn't take 'ovecsize' nor 'wscount' arguments
* _dfa_exec()_ doesn't take _ovecsize_ nor _wscount_ arguments
* 'dfa_exec()' returns boolean true for partial match, without subcapture info
* _dfa_exec()_ returns boolean true for partial match, without subcapture info
* Named subgroups do not return name-keyed entries in the return table (i.e., in
match/tfind/exec)
* The 'flags()' function still works, returning all flags, but two new functions
'compile_flags()' and 'match_flags()' return just their respective flags,
* The _flags()_ function still works, returning all flags, but two new functions
_compile_flags()_ and _match_flags()_ return just their respective flags,
since GLib has a different and smaller set of such flags, for regex compile
vs. match functions
* Using some assertions and POSIX character classes against strings with
non-ASCII characters might match high-order characters, because glib always
sets PCRE_UCP even if G_REGEX_RAW is set. For example, '[:alpha;]' matches
certain non-ASCII bytes. The following assertions have this issue: '\b', '\B',
'\s', '\S', '\w', '\W'. The following character classes have this issue:
sets PCRE_UCP even if G_REGEX_RAW is set. For example, _[:alpha;]_ matches
certain non-ASCII bytes. The following assertions have this issue: _\b_, _\B_,
_\s_, _\S_, _\w_, _\W_. The following character classes have this issue:
[:alpha:], [:alnum:], [:lower:], [:upper:], [:space:], [:word:], and
[:graph:].
@ -272,15 +272,15 @@ All functions that take a string-type regex argument accept a compiled regex
too. In this case, the compile flags argument is ignored (should be either
supplied as nils or omitted).
The capture flag argument 'cf' may also be supplied as a string, whose
The capture flag argument _cf_ may also be supplied as a string, whose
characters stand for compilation flags. Combinations of the following characters
(case sensitive) are supported:
* '__i__' = G_REGEX_CASELESS - Letters in the pattern match both upper- and
* _i_ = G_REGEX_CASELESS - Letters in the pattern match both upper- and
lowercase letters. This option can be changed within a pattern by a ``(?i)''
option setting.
* '__m__' = G_REGEX_MULTILINE - By default, GRegex treats the strings as
* _m_ = G_REGEX_MULTILINE - By default, GRegex treats the strings as
consisting of a single line of characters (even if it actually contains
newlines). The ``start of line'' metacharacter (``^'') matches only at the start
of the string, while the ``end of line'' metacharacter (``$'') matches only at
@ -291,18 +291,18 @@ characters stand for compilation flags. Combinations of the following characters
very start and end. This can be changed within a pattern by a ``(?m)'' option
setting.
* '__s__' = G_REGEX_DOTALL - A dot metacharater (``.'') in the pattern matches
* _s_ = G_REGEX_DOTALL - A dot metacharater (``.'') in the pattern matches
all characters, including newlines. Without it, newlines are excluded. This
option can be changed within a pattern by a ("?s") option setting.
* '__x__' = G_REGEX_EXTENDED - Whitespace data characters in the pattern are
* _x_ = G_REGEX_EXTENDED - Whitespace data characters in the pattern are
totally ignored except when escaped or inside a character class. Whitespace
does not include the VT character (code 11). In addition, characters between
an unescaped ``$$#$$'' outside a character class and the next newline character,
inclusive, are also ignored. This can be changed within a pattern by a
``(?x)'' option setting.
* '__U__' = G_REGEX_UNGREEDY - Inverts the ``greediness'' of the quantifiers so
* _U_ = G_REGEX_UNGREEDY - Inverts the ``greediness'' of the quantifiers so
that they are not greedy by default, but become greedy if followed by ``?''.
It can also be set by a ``(?U)'' option setting within the pattern.
@ -405,7 +405,7 @@ A table filled with the results.
Searches for the first match of the regexp pattern in the string subject,
starting from offset init, subject to flags cf and ef. The pattern is compiled
each time this is called, unlike the class method 'match' function.
each time this is called, unlike the class method _match_ function.
Since: 1.11.3
@ -436,7 +436,7 @@ is returned. On failure, returns nil.
Searches for the first match of the regexp pattern in the string subject,
starting from offset init, subject to flags ef. The pattern is compiled each
time this is called, unlike the class method 'find' function.
time this is called, unlike the class method _find_ function.
Since: 1.11.3

92
docbook/wsug_src/WSUG_app_files.asciidoc
View File

@ -98,28 +98,28 @@ menu.
==== Folders on Windows
_APPDATA_ is the personal application data folder, e.g.:
++C:\Users\++__username__++\AppData\Roaming\Wireshark++ (details can be
_%APPDATA%_ is the personal application data folder, e.g.:
_C:\Users{backslash}**username**\AppData\Roaming\Wireshark_ (details can be
found at: <<ChWindowsProfiles>>).
_WIRESHARK_ is the Wireshark program folder, e.g.: `C:\Program
Files\Wireshark`.
_WIRESHARK_ is the Wireshark program folder, e.g.: _C:\Program
Files\Wireshark_.
==== Folders on Unix-like systems
_XDG_CONFIG_HOME_ is the folder for user-specific configuration files.
It's usually $HOME++/.config++, where $HOME is the user's home folder, which
is usually something such as ++/home/++__username__, or
++/Users/++__username__ on macOS.
_$XDG_CONFIG_HOME_ is the folder for user-specific configuration files.
It's usually _$HOME/.config_, where _$HOME_ is the user's home folder, which
is usually something such as _$HOME/**username**_, or
_/Users/**username**_ on macOS.
If you are using macOS and you are running a copy of Wireshark
installed as an application bundle, _APPDIR_ is the top-level directory
of the Wireshark application bundle, which will typically be
`/Applications/Wireshark.app`. Otherwise, _INSTALLDIR_ is the top-level
_/Applications/Wireshark.app_. Otherwise, _INSTALLDIR_ is the top-level
directory under which reside the subdirectories in which components of
Wireshark are installed. This will typically be `/usr` if Wireshark is
bundled with the system (for example, provided as a package with a Linux
distribution) and `/usr/local` if, for example, you've build Wireshark
distribution) and _/usr/local_ if, for example, you've build Wireshark
from source and installed it.
[[ChAppFilesConfigurationSection]]
@ -135,7 +135,7 @@ The content format of the configuration files is the same on all platforms.
On Windows:
* The personal configuration folder for Wireshark is the
`Wireshark` sub-folder of that folder, i.e. _APPDATA_`\Wireshark`.
_Wireshark_ sub-folder of that folder, i.e. _%APPDATA%\Wireshark_.
* The global configuration folder for Wireshark is the Wireshark program
folder and is also used as the system configuration folder.
@ -143,20 +143,18 @@ folder and is also used as the system configuration folder.
On Unix-like systems:
* The personal configuration folder is
__XDG_CONFIG_HOME__++/wireshark++. For backwards compatibility with
Wireshark before 2.2, if __XDG_CONFIG_HOME__++/wireshark++ does not
exist and $HOME++/.wireshark++ is present, then the latter will be used.
_$XDG_CONFIG_HOME/wireshark_. For backwards compatibility with
Wireshark before 2.2, if _$XDG_CONFIG_HOME/wireshark_ does not
exist and _$HOME/.wireshark_ is present, then the latter will be used.
* If you are using macOS and you are running a copy of Wireshark
installed as an application bundle, the global configuration folder is
__APPDIR__++/Contents/Resources/share/wireshark++. Otherwise, the
global configuration folder is __INSTALLDIR__++/share/wireshark++.
_APPDIR/Contents/Resources/share/wireshark_. Otherwise, the
global configuration folder is _INSTALLDIR/share/wireshark_.
* The `/etc` folder is the system configuration folder. The folder
* The _/etc_ folder is the system configuration folder. The folder
actually used on your system may vary, maybe something like:
`/usr/local/etc`.
[float]
_/usr/local/etc_.
[[AppFilesTabFolders]]
.Configuration files overview
@ -168,7 +166,7 @@ actually used on your system may vary, maybe something like:
|_cfilters_|Capture filters.
|_dfilters_|Display filters.
|_colorfilters_|Coloring rules.
|_$$disabled_protos$$_|Disabled protocols.
|_+++disabled_protos+++_|Disabled protocols.
|_ethers_|Ethernet name resolution.
|_manuf_|Ethernet name resolution.
|_hosts_|IPv4 and IPv6 name resolution.
@ -271,7 +269,7 @@ all the current color filters are written to the personal color filters
file.
--
_$$disabled_protos$$_::
_+++disabled_protos+++_::
Each line in this file specifies a disabled protocol name. The following are
some examples:
+
@ -281,9 +279,9 @@ tcp
udp
----
At program start, if there is a _$$disabled_protos$$_ file in the global
At program start, if there is a _+++disabled_protos+++_ file in the global
configuration folder, it is read first. Then, if there is a
_$$disabled_protos$$_ file in the personal configuration folder, that is
_+++disabled_protos+++_ file in the personal configuration folder, that is
read; if there is an entry for a protocol set in both files, the setting
in the personal disabled protocols file overrides the setting in the
global disabled protocols file.
@ -344,7 +342,7 @@ given IP address in both files, the setting in the personal hosts file
overrides the entry in the global hosts file.
+
--
This file has the same format as the usual `/etc/hosts` file on Unix systems.
This file has the same format as the usual _/etc/hosts_ file on Unix systems.
An example is:
@ -392,7 +390,7 @@ overrides the setting in the personal preference file.
+
--
Each line in one of these files consists of an IPv4 address, a subnet
mask length separated only by a '/' and a name separated by whitespace.
mask length separated only by a ``/'' and a name separated by whitespace.
While the address must be a full IPv4 address, any values beyond the
mask length are subsequently ignored.
@ -455,7 +453,7 @@ Wireshark.
=== Plugin folders
Wireshark supports plugins for various purposes. Plugins can either be
scripts written in Lua or code written in C or C++ and compiled to
scripts written in Lua or code written in C or {cpp} and compiled to
machine code.
Wireshark looks for plugins in both a personal plugin folder and a
@ -464,33 +462,33 @@ compiled plugins are stored in subfolders of the plugin folders, with
the subfolder name being the Wireshark minor version number (X.Y). There is
another hierarchical level for each Wireshark library (libwireshark, libwscodecs
and libwiretap). So for example the location for a libwireshark plugin
++foo.so++ (++foo.dll++ on Windows) would be __PLUGINDIR__++/X.Y/epan++
(libwireshark used to be called libepan; the other folder names are ++codecs++
and ++wiretap++).
_foo.so_ (_foo.dll_ on Windows) would be _PLUGINDIR/X.Y/epan_
(libwireshark used to be called libepan; the other folder names are _codecs_
and _wiretap_).
On Windows:
* The personal plugin folder is _APPDATA_`\Wireshark\plugins`.
* The personal plugin folder is _%APPDATA%\Wireshark\plugins_.
* The global plugin folder is _WIRESHARK_`\plugins`.
* The global plugin folder is _WIRESHARK\plugins_.
On Unix-like systems:
* The personal plugin folder is ++~/.local/lib/wireshark/plugins++.
* The personal plugin folder is _~/.local/lib/wireshark/plugins_.
[NOTE]
====
To provide better support for binary plugins this folder changed in Wireshark 2.5.
It is recommended to use the new folder but *for lua scripts only* you may
continue to use __XDG_CONFIG_HOME__++/wireshark/plugins++ for backward-compatibility.
continue to use _$XDG_CONFIG_HOME/wireshark/plugins_ for backward-compatibility.
This is useful to have older versions of Wireshark installed side-by-side. In case
of duplicate file names between old and new the new folder wins.
====
* If you are running on macOS and Wireshark is installed as an
application bundle, the global plugin folder is
_APPDIR_`/Contents/PlugIns/wireshark`, otherwise it's
_INSTALLDIR_`/lib/wireshark/plugins`.
_%APPDIR%/Contents/PlugIns/wireshark_, otherwise it's
_INSTALLDIR/lib/wireshark/plugins_.
[[ChWindowsFolder]]
@ -499,8 +497,8 @@ _INSTALLDIR_`/lib/wireshark/plugins`.
Here you will find some details about the folders used in Wireshark on different
Windows versions.
As already mentioned, you can find the currently used folders in the _About
Wireshark_ dialog.
As already mentioned, you can find the currently used folders in the ``About
Wireshark'' dialog.
[[ChWindowsProfiles]]
@ -521,23 +519,23 @@ The following guides you to the right place where to look for Wireshark's
profile data.
Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Vista, and associated server editions::
++C:\Users\++__username__++\AppData\Roaming\Wireshark++.
_C:\Users{backslash}**username**\AppData\Roaming\Wireshark_.
Windows XP, Windows Server 2003, and Windows 2000 footnoteref:[historical,No longer supported by Wireshark. For historical reference only.]::
++C:\Documents and Settings\++__username__++\Application Data++. ``Documents and
_C:\Documents and Settings{backslash}**username**\Application Data_. ``Documents and
Settings'' and ``Application Data'' might be internationalized.
Windows NT 4 footnoteref:[historical]::
++C:\WINNT\Profiles\++__username__++\Application Data\Wireshark++
_C:\WINNT\Profiles{backslash}**username**\Application Data\Wireshark_
Windows ME, Windows 98 with user profiles footnoteref:[historical]::
In Windows ME and 98 you could enable separate user profiles. In that case,
something like ++C:\windows\Profiles\++__username__++\Application Data\Wireshark++
something like _C:\windows\Profiles{backslash}**username**\Application Data\Wireshark_
is used.
Windows ME, Windows 98 without user profiles footnoteref:[historical]::
Without user profiles enabled the default location for all users was
++C:\windows\Application Data\Wireshark++.
_C:\windows\Application Data\Wireshark_.
[[ChWindowsRoamingProfiles]]
@ -549,7 +547,7 @@ They will be stored on the domain server instead.
Your settings will travel with you from computer to computer with one exception.
The ``Local Settings'' folder in your profile data (typically something like:
++C:\Documents and Settings\++__username__++\Local Settings++) will not be
_C:\Documents and Settings{backslash}**username**\Local Settings_) will not be
transferred to the domain server. This is the default for temporary capture
files.
@ -561,13 +559,13 @@ Wireshark uses the folder which is set by the TMPDIR or TEMP environment
variable. This variable will be set by the Windows installer.
Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Vista, and associated server editions::
++C:\Users\++__username__++\AppData\Local\Temp++
_C:\Users{backslash}**username**\AppData\Local\Temp_
Windows XP, Windows Server 2003, Windows 2000 footnoteref:[historical]::
++C:\Documents and Settings\++__username__++\Local Settings\Temp++
_C:\Documents and Settings{backslash}**username**\Local Settings\Temp_
Windows NT footnoteref:[historical]::
++C:\TEMP++
_C:\TEMP_
++++++++++++++++++++++++++++++++++++++
<!-- End of WSUG Appendix Files -->

4
docbook/wsug_src/WSUG_app_howitworks.asciidoc
View File

@ -65,7 +65,7 @@ There are two ways for a dissector to register itself for packet data:
Let's look at an example. We'll assume, Wireshark loads a TCP/IP/Ethernet
packet. Wireshark will call the Ethernet dissector, which will dissect the
Ethernet related data (usually the first 6+6+2 bytes). Then this dissector calls
Ethernet related data (usually the first 6 + 6 + 2 bytes). Then this dissector calls
back into Wireshark and will pass the rest of the data back to Wireshark.
Wireshark in turn will call the next related dissector, in our case the IP
dissector (because of the value 0x800 in the Ethernet type field). This game
@ -77,4 +77,4 @@ You can control the way Wireshark calls its dissectors, see
++++++++++++++++++++++++++++++++++++++
<!-- End of WSUG Appendix How it Works -->
++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++

24
docbook/wsug_src/WSUG_app_tools.asciidoc
View File

@ -35,7 +35,7 @@ include::tshark-h.txt[]
[[AppToolstcpdump]]
=== __tcpdump__: Capturing with `tcpdump` for viewing with Wireshark
=== __tcpdump__: Capturing with ``tcpdump'' for viewing with Wireshark
It's often more useful to capture packets using `tcpdump` rather than
`wireshark`. For example, you might want to do a remote capture and either don't
@ -52,14 +52,14 @@ You will have to specify the correct _interface_ and the name of a _file_ to
save into. In addition, you will have to terminate the capture with ^C when you
believe you have captured enough packets.
+tcpdump+ is not part of the Wireshark distribution. You can get it from
`tcpdump` is not part of the Wireshark distribution. You can get it from
{tcpdump-main-url} or as a standard package in most Linux distributions.
For more information on +tcpdump+ consult your local manual page (`man
For more information on `tcpdump` consult your local manual page (`man
tcpdump`) or link:{tcpdump-man-page-url}[the online version].
[[AppToolsdumpcap]]
=== __dumpcap__: Capturing with `dumpcap` for viewing with Wireshark
=== __dumpcap__: Capturing with ``dumpcap'' for viewing with Wireshark
Dumpcap is a network traffic dump tool. It captures packet data from a live
network and writes the packets to a file. Dumpcap's native capture file format
@ -82,7 +82,7 @@ include::dumpcap-h.txt[]
=== __capinfos__: Print information about capture files
+capinfos+ can print information about capture files including the file
`capinfos` can print information about capture files including the file
type, number of packets, date and time information, and file hashes.
Information can be printed in human and machine readable formats. For
more information on `capinfos` consult your local manual page (`man
@ -115,7 +115,7 @@ include::rawshark-h.txt[]
=== __editcap__: Edit capture files
+editcap+ is a general-purpose utility for modifying capture files. Its
`editcap` is a general-purpose utility for modifying capture files. Its
main function is to remove packets from capture files, but it can also
be used to convert capture files from one format to another, as well as
to print information about capture files. For more information on
@ -155,7 +155,7 @@ HP-UX's nettl, and the dump output from Toshiba's ISDN routers. There is no need
to tell Mergecap what type of file you are reading; it will determine the file
type by itself. Mergecap is also capable of reading any of these file formats if
they are compressed using `gzip`. Mergecap recognizes this directly from the
file; the ``$$.gz$$'' extension is not required for this purpose.
file; the ``.gz'' extension is not required for this purpose.
By default, it writes the capture file in pcapng format, and writes all of the
packets in the input capture files to the output file. The `-F` flag can be used
@ -216,14 +216,14 @@ $ mergecap -w outfile.pcapng dhcp-capture.pcapng imap-1.pcapng
There may be some occasions when you wish to convert a hex dump of some network
traffic into a libpcap file.
+text2pcap+ is a program that reads in an ASCII hex dump and writes the data
`text2pcap` is a program that reads in an ASCII hex dump and writes the data
described into a libpcap-style capture file. text2pcap can read hexdumps with
multiple packets in them, and build a capture file of multiple packets.
`text2pcap` is also capable of generating dummy Ethernet, IP and UDP headers, in
order to build fully processable packet dumps from hexdumps of application-level
data only.
+text2pcap+ understands a hexdump of the form generated by `od -A x -t x1`. In
`text2pcap` understands a hexdump of the form generated by `od -A x -t x1`. In
other words, each byte is individually displayed and surrounded with a space.
Each line begins with an offset describing the position in the file. The offset
is a hex number (can also be octal - see `-o`), of more than two hex digits. Here
@ -256,13 +256,13 @@ of mangled outputs (including being forwarded through email multiple times, with
limited line wrap etc.)
There are a couple of other special features to note. Any line where the first
non-whitespace character is '#' will be ignored as a comment. Any line beginning
non-whitespace character is `#' will be ignored as a comment. Any line beginning
with #TEXT2PCAP is a directive and options can be inserted after this command to
be processed by `text2pcap`. Currently there are no directives implemented; in the
future, these may be used to give more fine grained control on the dump and the
way it should be processed e.g. timestamps, encapsulation type etc.
+text2pcap+ also allows the user to read in dumps of application-level data, by
`text2pcap` also allows the user to read in dumps of application-level data, by
inserting dummy L2, L3 and L4 headers before each packet. Possibilities include
inserting headers such as Ethernet, Ethernet + IP, Ethernet + IP + UDP, or
Ethernet + Ip + TCP before each packet. This allows Wireshark or any other
@ -283,7 +283,7 @@ include::text2pcap-h.txt[]
=== __reordercap__: Reorder a capture file
+reordercap+ lets you reorder a capture file according to the packets
`reordercap` lets you reorder a capture file according to the packets
timestamp. For more information on `reordercap` consult your local
manual page (`man reordercap`) or
link:{wireshark-man-page-url}reordercap.html[the online version].

6
docbook/wsug_src/WSUG_chapter_build_install.asciidoc
View File

@ -321,7 +321,7 @@ the installation methods used with your version of UNIX. For example, under AIX,
you would use _smit_ to install the Wireshark binary package, while under Tru64
UNIX (formerly Digital UNIX) you would use _setld_.
==== Installing from RPM's under Red Hat and alike
==== Installing from RPMs under Red Hat and alike
Building RPMs from Wireshark's source code results in several packages (most
distributions follow the same system):
@ -353,7 +353,7 @@ rpm -ivh wireshark-2.0.0-1.x86_64.rpm wireshark-qt-2.0.0-1.x86_64.rpm
If the above command fails because of missing dependencies, install the
dependencies first, and then retry the step above.
==== Installing from deb's under Debian, Ubuntu and other Debian derivatives
==== Installing from debs under Debian, Ubuntu and other Debian derivatives
If you can just install from the repository then use
@ -363,7 +363,7 @@ $ aptitude install wireshark
Aptitude should take care of all of the dependency issues for you.
Use the following command to install downloaded Wireshark deb's under Debian:
Use the following command to install downloaded Wireshark debs under Debian:
----
$ dpkg -i wireshark-common_2.0.5.0-1_i386.deb wireshark_wireshark-2.0.5.0-1_i386.deb

30
docbook/wsug_src/WSUG_chapter_customize.asciidoc
View File

@ -413,7 +413,7 @@ are seconds since epoch (Jan 1, 1970 00:00:00)
-u <s | hms>::
Show timesamps as seconds ('s', the default) or hours, minutes, and seconts ('hms')
Show timesamps as seconds (`s', the default) or hours, minutes, and seconds (`hms')
-v::
@ -449,12 +449,12 @@ Tells Wireshark to load the given script in addition to the default Lua scripts.
lua_script[num]:argument::
Tells Wireshark to pass the given argument to the lua script identified by
'num', which is the number indexed order of the 'lua_script' command. For
_num_, which is the number indexed order of the _lua_script_ command. For
example, if only one script was loaded with `-X lua_script:my.lua`, then `-X
lua_script1:foo` will pass the string 'foo' to the 'my.lua' script. If two
lua_script1:foo` will pass the string _foo_ to the _my.lua_ script. If two
scripts were loaded, such as `-X lua_script:my.lua` and `-X
lua_script:other.lua` in that order, then a `-X lua_script2:bar` would pass the
string 'bar' to the second lua script, namely 'other.lua'.
string _bar_ to the second lua script, namely _other.lua_.
--
-z <statistics-string>::
@ -921,13 +921,13 @@ Responder's SPI::
Responder's SPI of the IKE_SA. This field takes hexadecimal string without
``0x'' prefix and the length must be 16 hex chars (represents 8 octets).
$$SK_ei$$::
SK_ei::
Key used to encrypt/decrypt IKEv2 packets from initiator to responder. This
field takes hexadecimal string without ``0x'' prefix and its length must meet
the requirement of the encryption algorithm selected.
$$SK_er$$::
SK_er::
Key used to encrypt/decrypt IKEv2 packets from responder to initiator. This
field takes hexadecimal string without ``0x'' prefix and its length must meet
the requirement of the encryption algorithm selected.
@ -973,7 +973,7 @@ The string representation of the Object Identifier e.g. ``2.5.4.6''.
Name::
The name that should be displayed by Wireshark when the Object Identifier is
dissected e.g. ('c');
dissected e.g. (``c'');
Syntax::
The syntax of the value associated with the Object Identifier. This must be one
@ -1084,21 +1084,21 @@ Authentication model::
Which auth model to use (either ``MD5'' or ``SHA1'').
Password::
The authentication password. Use '\xDD' for unprintable characters. An
hexadecimal password must be entered as a sequence of '\xDD' characters. For
The authentication password. Use _\xDD_ for unprintable characters. An
hexadecimal password must be entered as a sequence of _\xDD_ characters. For
example the hex password 010203040506 must be entered as
'\x01\x02\x03\x04\x05\x06'. The '\' character must be treated as an unprintable
character, i.e. it must be entered as '\x5C' or '\x5c'.
_\x01\x02\x03\x04\x05\x06_. The _\_ character must be treated as an unprintable
character, i.e. it must be entered as _\x5C_ or _\x5c_.
Privacy protocol::
Which encryption algorithm to use (either ``DES'' or ``AES").
Privacy password::
The privacy password. Use '\xDD' for unprintable characters. An hexadecimal
password must be entered as a sequence of '\xDD' characters. For example the hex
password 010203040506 must be entered as '\x01\x02\x03\x04\x05\x06'. The '\'
The privacy password. Use _\xDD_ for unprintable characters. An hexadecimal
password must be entered as a sequence of _\xDD_ characters. For example the hex
password 010203040506 must be entered as _\x01\x02\x03\x04\x05\x06_. The _\_
character must be treated as an unprintable character, i.e. it must be entered
as '\x5C' or '\x5c'.
as _\x5C_ or _\x5c_.
[[ChK12ProtocolsSection]]

6
docbook/wsug_src/WSUG_chapter_introduction.asciidoc
View File

@ -431,7 +431,7 @@ When reporting problems with Wireshark please supply the following information:
. The version number of Wireshark and the dependent libraries linked with it,
such as Qt or GLib. You can obtain this from Wireshark's about box or the
command `wireshark -v`.
command _wireshark -v_.
. Information about the platform you run Wireshark on.
@ -473,9 +473,9 @@ backtrace
^D
----
If you do not have `gdb` available, you will have to check out your operating system's debugger.
If you do not have _gdb_ available, you will have to check out your operating system's debugger.
Mail `backtrace.txt` to mailto:{wireshark-dev-list-email}[].
Mail _backtrace.txt_ to mailto:{wireshark-dev-list-email}[].
==== Reporting Crashes on Windows platforms

6
docbook/wsug_src/WSUG_chapter_io.asciidoc
View File

@ -440,7 +440,7 @@ Here is a sample dump that can be imported:
There is no limit on the width or number of bytes per line. Also the text dump
at the end of the line is ignored. Byte and hex numbers can be uppercase or
lowercase. Any text before the offset is ignored, including email forwarding
characters '&gt;'. Any lines of text between the bytestring lines are ignored.
characters _&gt;_. Any lines of text between the bytestring lines are ignored.
The offsets are used to track the bytes, so offsets must be correct. Any line
which has only bytes without a leading offset is ignored. An offset is
recognized as being a hex number longer than two characters. Any text after the
@ -707,7 +707,7 @@ Export packet bytes into C arrays so you can import the stream data into your ow
Export packet data into PSML. This is an XML based format including only the
packet summary. The PSML file specification is available at:
link:$$http://www.nbee.org/doku.php?id=netpdl:psml_specification$$[].
link:http://www.nbee.org/doku.php?id=netpdl:psml_specification[].
.The "Export as PSML File" dialog box
image::wsug_graphics/ws-export-psml.png[{screenshot-attrs}]
@ -725,7 +725,7 @@ format is defined by the PSML specification.
Export packet data into PDML. This is an XML based format including the packet
details. The PDML file specification is available at:
link:$$http://www.nbee.org/doku.php?id=netpdl:pdml_specification$$[].
link:http://www.nbee.org/doku.php?id=netpdl:pdml_specification[].
[NOTE]
====

4
docbook/wsug_src/WSUG_chapter_use.asciidoc
View File

@ -670,11 +670,11 @@ image::wsug_graphics/ws-help-menu.png[{screenshot-attrs}]
|menu:Contents[]|F1| This menu item brings up a basic help system.
|menu:Manual Pages[...]|| This menu item starts a Web browser showing one of the locally installed html manual pages.
|menu:Website[]|| This menu item starts a Web browser showing the webpage from: link:{wireshark-main-url}[].
|menu:FAQ's[]|| This menu item starts a Web browser showing various FAQ's.
|menu:FAQs[]|| This menu item starts a Web browser showing various FAQs.
|menu:Downloads[]|| This menu item starts a Web browser showing the downloads from: link:{wireshark-download-url}[].
|menu:Wiki[]|| This menu item starts a Web browser showing the front page from: link:{wireshark-wiki-url}[].
|menu:Sample Captures[]|| This menu item starts a Web browser showing the sample captures from: link:{wireshark-wiki-url}SampleCaptures[].
|menu:About Wireshark[]|| This menu item brings up an information window that provides various detailed information items on Wireshark, such as how it's build, the plugins loaded, the used folders, ...
|menu:About Wireshark[]|| This menu item brings up an information window that provides various detailed information items on Wireshark, such as how it's built, the plugins loaded, the used folders, ...
|===============

16
docbook/wsug_src/WSUG_chapter_work.asciidoc
View File

@ -319,13 +319,13 @@ Signed integer::
Boolean::
A boolean field is present in the protocol decode only if its value is true. For
example, +tcp.flags.syn+ is present, and thus true, only if the SYN flag is
example, `tcp.flags.syn` is present, and thus true, only if the SYN flag is
present in a TCP segment header.
The filter expression +tcp.flags.syn+ will select only those packets for which
The filter expression `tcp.flags.syn` will select only those packets for which
this flag exists, that is, TCP segments where the segment header contains the
SYN flag. Similarly, to find source-routed token ring packets, use a filter
expression of +tr.sr+.
expression of `tr.sr`.
Ethernet address::
6 bytes separated by a colon (:), dot (.) or dash (-) with one or two bytes between separators:
@ -346,12 +346,12 @@ IPv4 address::
ip.addr == 129.111.0.0/16
IPv6 address::
+ipv6.addr == ::1+
`ipv6.addr == ::1`
As with IPv4 addresses, IPv6 addresses can match a subnet.
Text string::
+http.request.uri == "https://www.wireshark.org/"+
`http.request.uri == "https://www.wireshark.org/"`
----
udp contains 81:60:03
@ -368,7 +368,7 @@ http.host matches "acme\.(org|com|net)"
----
The example above match HTTP packets where the HOST header contains acme.org or acme.com
or acme.net. Comparisons are case-insensitive. Note: Wireshark needs to be built with
libpcre in order to be able to use the +matches+ resp. +~+ operator.
libpcre in order to be able to use the `matches` resp. `~`` operator.
----
tcp.flags & 0x02
----
@ -817,7 +817,7 @@ The available precisions (aka. the number of displayed decimal places) are:
precision is larger, the remaining decimal places will be cut off.
Precision example: If you have a timestamp and it's displayed using, ``Seconds
Since Previous Packet'', : the value might be 1.123456. This will be displayed
Since Previous Packet'' the value might be 1.123456. This will be displayed
using the ``Automatic'' setting for libpcap files (which is microseconds). If
you use Seconds it would show simply 1 and if you use Nanoseconds it shows
1.123456000.
@ -839,7 +839,7 @@ Time referencing will only be useful if the time display format is set to
are used, time referencing will have no effect (and will make no sense either).
To work with time references, choose one of the menu:Time Reference[] items in
the menu:Edit[] menu or from the pop-up menu of the ``Packet List'' pane. See
the menu:[Edit] menu or from the pop-up menu of the ``Packet List'' pane. See
<<ChUseEditMenuSection>>.
* _Set Time Reference (toggle)_ Toggles the time reference state of the