WSUG: Fix numerous grammar issues
This commit is contained in:
Moshe Kaplan
Martin Mathieson
parent
7747189861
commit
9b49cbff29
|
|
@ -117,7 +117,7 @@ _/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 built Wireshark
|
||||
from source and installed it.
|
||||
|
||||
[#ChAppFilesConfigurationSection]
|
||||
|
|
@ -526,7 +526,7 @@ vlans::
|
|||
--
|
||||
Wireshark uses the _vlans_ file to translate VLAN tag IDs into names.
|
||||
|
||||
If there is a _vlans_ file in the currently active profile folder, it is used. Otherwise the _vlans_ file in the personal configuration folder is used.
|
||||
If there is a _vlans_ file in the currently active profile folder, it is used. Otherwise, the _vlans_ file in the personal configuration folder is used.
|
||||
|
||||
Each line in this file consists of one VLAN tag ID and a describing name separated by whitespace or tab.
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ include::wireshark-h.txt[]
|
|||
We will examine each of the command line options in turn.
|
||||
|
||||
The first thing to notice is that issuing the command `wireshark` by itself will
|
||||
bring up Wireshark. However, you can include as many of the command line
|
||||
launch Wireshark. However, you can include as many of the command line
|
||||
parameters as you like. Their meanings are as follows ( in alphabetical order ):
|
||||
|
||||
// XXX - is the alphabetical order a good choice? Maybe better task based?
|
||||
|
|
@ -522,7 +522,7 @@ Each protocol has its own dissector, so dissecting a complete packet will
|
|||
typically involve several dissectors. As Wireshark tries to find the right
|
||||
dissector for each packet (using static “routes” and heuristics “guessing”),
|
||||
it might choose the wrong dissector in your specific case. For example,
|
||||
Wireshark won’t know if you use a common protocol on an uncommon TCP port, e.g.
|
||||
Wireshark won’t know if you use a common protocol on an uncommon TCP port, e.g.,
|
||||
using HTTP on TCP port 800 instead of the standard port 80.
|
||||
|
||||
There are two ways to control the relations between protocol dissectors: disable
|
||||
|
|
@ -814,7 +814,7 @@ The replacement text for the macro it uses $1, $2, $3, ... as the input argument
|
|||
|
||||
=== ESS Category Attributes
|
||||
|
||||
Wireshark uses this table to map ESS Security Category attributes to textual representations. The values to put in this table are usually found in a http://www.xmlspif.org/[XML SPIF], which is used for defining security labels.
|
||||
Wireshark uses this table to map ESS Security Category attributes to textual representations. The values to put in this table are usually found in an http://www.xmlspif.org/[XML SPIF], which is used for defining security labels.
|
||||
|
||||
This table is a user table, as described in <<ChUserTable>>, with the
|
||||
following fields:
|
||||
|
|
@ -969,10 +969,10 @@ An Integer representing the network indicator for which this association is
|
|||
valid.
|
||||
|
||||
Called DPCs::
|
||||
An range of integers representing the dpcs for which this association is valid.
|
||||
A range of integers representing the dpcs for which this association is valid.
|
||||
|
||||
Called SSNs::
|
||||
An range of integers representing the ssns for which this association is valid.
|
||||
A range of integers representing the ssns for which this association is valid.
|
||||
|
||||
User protocol::
|
||||
The protocol that is carried over this association
|
||||
|
|
@ -1044,9 +1044,9 @@ Authentication model::
|
|||
Which auth model to use (either “MD5” or “SHA1”).
|
||||
|
||||
Password::
|
||||
The authentication password. Use _\xDD_ for unprintable characters. An
|
||||
The authentication password. Use _\xDD_ for unprintable characters. A
|
||||
hexadecimal password must be entered as a sequence of _\xDD_ characters. For
|
||||
example the hex password 010203040506 must be entered as
|
||||
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_.
|
||||
|
||||
|
|
@ -1080,7 +1080,7 @@ Protocol::
|
|||
This is the name of the encapsulating protocol (the lowest layer in the packet
|
||||
data) it can be either just the name of the protocol (e.g., mtp2, eth_withoutfcs,
|
||||
sscf-nni ) or the name of the encapsulation protocol and the “application”
|
||||
protocol over it separated by a colon (e.g sscop:sscf-nni, sscop:alcap,
|
||||
protocol over it separated by a colon (e.g., sscop:sscf-nni, sscop:alcap,
|
||||
sscop:nbap, ...)
|
||||
|
||||
[#ChUserDLTsSection]
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ configurable extension(s) of the display filter engine.
|
|||
MATE's goal is to enable users to filter frames based on information extracted
|
||||
from related frames or information on how frames relate to each other. MATE
|
||||
was written to help troubleshooting gateways and other systems where a "use"
|
||||
involves more protocols. However MATE can be used as well to analyze other
|
||||
involves more protocols. However, MATE can be used as well to analyze other
|
||||
issues regarding an interaction between packets like response times,
|
||||
incompleteness of transactions, presence/absence of certain attributes in a
|
||||
group of PDUs and more.
|
||||
|
|
@ -22,7 +22,7 @@ group of PDUs and more.
|
|||
MATE is a Wireshark plugin that allows the user to specify how different
|
||||
frames are related to each other. To do so, MATE extracts data from the frames'
|
||||
tree and then, using that information, tries to group the frames based on how
|
||||
MATE is configured. Once the PDUs are related MATE will create a "protocol"
|
||||
MATE is configured. Once the PDUs are related, MATE will create a "protocol"
|
||||
tree with fields the user can filter with. The fields will be almost the same
|
||||
for all the related frames, so one can filter a complete session spanning
|
||||
several frames containing more protocols based on an attribute appearing in
|
||||
|
|
@ -53,7 +53,7 @@ appear in Help->About->Plugins)
|
|||
for more) and place it somewhere on your harddisk.
|
||||
* Go to Preferences->Protocols->MATE and set the config filename to the file
|
||||
you want to use (you don't have to restart Wireshark)
|
||||
* Load a corresponding capture file (e.g.
|
||||
* Load a corresponding capture file (e.g.,
|
||||
{wireshark-wiki-url}uploads/27707187aeb30df68e70c8fb9d614981/http.cap[http.cap]) and see if MATE
|
||||
has added some new display filter fields, something like: `mate tcp_pdu:1->tcp_ses:1`
|
||||
or, at prompt: `path_to/wireshark -o "mate.config: tcp.mate" -r http.cap`.
|
||||
|
|
@ -70,7 +70,7 @@ image::wsug_graphics/ws-mate-tcp-output.png[]
|
|||
|
||||
MATE creates a filterable tree based on information contained in frames that
|
||||
share some relationship with information obtained from other frames. The way
|
||||
this relationships are made is described in a configuration file. The
|
||||
these relationships are made is described in a configuration file. The
|
||||
configuration file tells MATE what makes a PDU and how to relate it to other
|
||||
PDUs.
|
||||
|
||||
|
|
@ -225,7 +225,7 @@ an AVPL containing the AVPs from the operand that matched.
|
|||
* There's also a <<Merge,Merge>> operation that is to be performed between AVPLs
|
||||
where all the AVPs that don't exist in the operand AVPL but exist in the operand
|
||||
will be added to the operand AVPL.
|
||||
* Other than that there are <<Transform,Transformations>> - a combination
|
||||
* Other than that, there are <<Transform,Transformations>> - a combination
|
||||
of a match AVPL and an AVPL to merge.
|
||||
|
||||
==== MATE Analysis
|
||||
|
|
@ -387,7 +387,7 @@ extracted one.
|
|||
|
||||
Once the fields have been extracted into the Pdu's AVPL, MATE will apply any
|
||||
declared transformation to it. The way transforms are applied and how they work
|
||||
is described later on. However it's useful to know that once the AVPL for the
|
||||
is described later on. However, it's useful to know that once the AVPL for the
|
||||
Pdu is created, it may be transformed before being analyzed. That way we can
|
||||
massage the data to simplify the analysis.
|
||||
|
||||
|
|
@ -869,7 +869,7 @@ Gop my_gop On my_pdu Match (addr,addr,port,port) {
|
|||
|
||||
====== NAT
|
||||
|
||||
NAT can create problems when tracing, but we can easily worked around it by
|
||||
NAT can create problems when tracing, but we can easily work around it by
|
||||
Transforming the NATed IP address and the Ethernet address of the router into
|
||||
the non-NAT address:
|
||||
|
||||
|
|
@ -901,7 +901,7 @@ he was directly involved with.
|
|||
=== MATE's configuration tutorial
|
||||
|
||||
We'll show a MATE configuration that first creates Gops for every DNS and HTTP
|
||||
request, then it ties the Gops together in a Gop based on the host. Finally
|
||||
request, then it ties the Gops together in a Gop based on the host. Finally,
|
||||
we'll separate into different Gogs request coming from different users.
|
||||
|
||||
With this MATE configuration loaded we can:
|
||||
|
|
@ -917,7 +917,7 @@ that take more than 1.5 seconds to complete.
|
|||
The complete config file is available on the Wireshark Wiki:
|
||||
https://gitlab.com/wireshark/wireshark/-/wikis/Mate/Tutorial
|
||||
|
||||
Note: for this example I used _dns.qry.name_ which is defined since Wireshark
|
||||
Note: This example uses _dns.qry.name_ which is defined since Wireshark
|
||||
version 0.10.9. Supposing you have a mate plugin already installed you can test
|
||||
it with the current Wireshark version.
|
||||
|
||||
|
|
@ -1030,7 +1030,7 @@ Here we've told MATE to import _http.host_ into _http_pdu_ and _dns.qry.name_
|
|||
into _dns_pdu_ as _host_. We also have to tell MATE to copy the _host_
|
||||
attribute from the Pdus to the Gops, we do this using _Extra_.
|
||||
|
||||
Once we've got all the data we need in Pdus and Gops, we tell MATE what makes
|
||||
Once we have all the data we need in Pdus and Gops, we tell MATE what makes
|
||||
different Gops belong to a certain Gog.
|
||||
|
||||
----
|
||||
|
|
@ -1041,12 +1041,12 @@ Gog http_use {
|
|||
};
|
||||
----
|
||||
|
||||
Using the _Gog_ declaration we tell MATE to define a Gog type _Named_
|
||||
Using the _Gog_ declaration, we tell MATE to define a Gog type _Named_
|
||||
_http_use_ whose expiration is 0.75 seconds after all the Gops that belong to it
|
||||
had been stopped. After that time, an eventual new Gop with the same key match
|
||||
will create a new Gog instead of been added to the previous Gog.
|
||||
|
||||
Using the _Member_ statements we tell MATE that *http_req*s with the same
|
||||
Using the _Member_ statements, we tell MATE that *http_req*s with the same
|
||||
*host* belong to the same Gog, same thing for *dns_req*s.
|
||||
|
||||
So far we have instructed mate to group every packet related to sessions towards
|
||||
|
|
@ -1588,8 +1588,8 @@ The defined match operators are:
|
|||
or the match will fail.
|
||||
* <<NotEqual,Not Equal>> _!_ will match only if the value strings aren't equal.
|
||||
* <<OneOf,One Of>> _{}_ will match if one of the value strings listed is equal to the
|
||||
data AVP's string. Individual tems of the list inside the curly braces are
|
||||
separated using | character.
|
||||
data AVP's string. Items inside the list's curly braces are
|
||||
separated with the | character.
|
||||
* <<StartsWith,Starts With>> _^_ will match if the configuration value string matches the
|
||||
first characters of the data AVP's value string.
|
||||
* <<EndsWith,Ends With>> _$_ will match if the configuration value string matches the
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ These statistics range from general information about the loaded capture file
|
|||
|
||||
- *Conversations* e.g., traffic between specific IP addresses.
|
||||
|
||||
- *Endpoints* e.g., traffic to and from an IP addresses.
|
||||
- *Endpoints* e.g., traffic to and from IP addresses.
|
||||
|
||||
- *I/O Graphs* visualizing the number of packets (or similar) in time.
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ The Resolved Addresses window shows the list of resolved addresses and their hos
|
|||
|
||||
. Select `Use an external network name resolver` in the menu:Preferences[Name Resolution] menu. This option is enabled by default.
|
||||
|
||||
NOTE: The resolved addresses are not updated automatically after users change the settings. To display newly available names user have to reopen the dialog.
|
||||
NOTE: The resolved addresses are not updated automatically after a user changes the settings. To display newly available names, the user has to reopen the dialog.
|
||||
|
||||
The `Ports` tab shows the list of service names, ports and types.
|
||||
|
||||
|
|
@ -164,7 +164,7 @@ The absolute number of bytes of this protocol where it was the highest protocol
|
|||
End Bits/s::
|
||||
The bandwidth of this protocol relative to the capture time where was the highest protocol in the stack (last dissected).
|
||||
|
||||
Packets usually contain multiple protocols. As a result more than one protocol will
|
||||
Packets usually contain multiple protocols. As a result, more than one protocol will
|
||||
be counted for each packet. Example: In the screenshot IP has 99.9% and TCP
|
||||
98.5% (which is together much more than 100%).
|
||||
|
||||
|
|
@ -261,10 +261,10 @@ IPv4:: Identical to the 32-bit IPv4 address.
|
|||
|
||||
IPv6:: Identical to the 128-bit IPv6 address.
|
||||
|
||||
IPX:: A concatenation of a 32 bit network number and 48 bit node address, by
|
||||
IPX:: A concatenation of a 32-bit network number and 48-bit node address, by
|
||||
default the Ethernet interface’s MAC-48 address.
|
||||
|
||||
JXTA:: A 160 bit SHA-1 URN.
|
||||
JXTA:: A 160-bit SHA-1 URN.
|
||||
|
||||
NCP:: Similar to IPX.
|
||||
|
||||
|
|
@ -355,7 +355,7 @@ Count::
|
|||
The number of packets that fall into this range.
|
||||
|
||||
Average::
|
||||
The arithmetic mean length of the packets in this range.
|
||||
The arithmetic mean of the packet lengths in this range.
|
||||
|
||||
Min Val, Max Val::
|
||||
The minimum and maximum lengths in this range.
|
||||
|
|
@ -570,7 +570,7 @@ The Dynamic Host Configuration Protocol (DHCP) is an option of the Bootstrap Pro
|
|||
|
||||
The NetPerfMeter Protocol{nbsp}(NPMP) is the control and data transfer protocol of NetPerfMeter, the transport protocol performance testing tool. It transmits data streams over TCP, SCTP, UDP and DCCP with given parameters, such as frame rate, frame size, saturated flows, etc.
|
||||
|
||||
With this statistics you can:
|
||||
With these statistics you can:
|
||||
|
||||
* Observed number of messages and bytes per message type.
|
||||
* The share of messages and bytes for each message type.
|
||||
|
|
@ -797,7 +797,7 @@ Window Scaling:: Window size and outstanding bytes.
|
|||
|
||||
The UDP Multicast Streams window shows statistics for all UDP multicast streams. It includes source addresses and ports, destination addresses and ports, packets counter and other data. You can specify the burst interval, the alarm limits and output speeds. To apply new settings, press btn:[Enter].
|
||||
|
||||
With this statistics you can:
|
||||
With these statistics you can:
|
||||
|
||||
* Measure the burst size for a video stream. This uses the sliding window algorithm.
|
||||
* Measure of the output buffer size limit, that no packet drop will occur. This uses the Leaky bucket algorithm.
|
||||
|
|
|
|||
|
|
@ -25,15 +25,15 @@ Some of these statistics are described at the
|
|||
|
||||
=== Playing VoIP Calls
|
||||
|
||||
The tool for playing VoIP calls is called <<ChTelRtpPlayer,RTP Player>>. It shows RTP streams and its waveforms, allows play stream and export it as audio or payload to file. Its capabilities depends on supported codecs.
|
||||
The tool for playing VoIP calls is called <<ChTelRtpPlayer,RTP Player>>. It shows RTP streams and its waveforms, allows play stream and export it as audio or payload to file. Its capabilities depend on supported codecs.
|
||||
|
||||
==== Supported codecs
|
||||
|
||||
RTP Player is able to play any codec supported by an installed plugins. The codecs supported by RTP Player depend on the version of Wireshark you're using. The official builds contain all of the plugins maintained by the Wireshark developers, but custom/distribution builds might not include some of those codecs. To check your Wireshark follow this procedure:
|
||||
RTP Player is able to play any codec supported by an installed plugin. The codecs supported by RTP Player depend on the version of Wireshark you're using. The official builds contain all of the plugins maintained by the Wireshark developers, but custom/distribution builds might not include some of those codecs. To check your Wireshark installation's installed codec plugins, do the following:
|
||||
|
||||
* open menu:Help[About Wireshark] window
|
||||
* switch to menu:Plugins[] tab
|
||||
* select codec as menu:Filter by type[]
|
||||
* Open menu:Help[About Wireshark] window
|
||||
* Select the menu:Plugins[] tab
|
||||
* In the menu:Filter by type[] menu on the top-right, select codec
|
||||
|
||||
.List of supported codecs
|
||||
image::wsug_graphics/ws-about-codecs.png[{screenshot-attrs}]
|
||||
|
|
@ -53,11 +53,11 @@ When RTP Player window is opened, playlist can be modified from other tools (Wir
|
|||
.btn:[Play Streams] button with opened action menu
|
||||
image::wsug_graphics/ws-tel-rtp-player_button.png[]
|
||||
|
||||
btn:[Play Streams] button can be clicked directly and opens RTP Player window directly with btn:[Set playlist] action. All actions are selectable by small down arrow next to button.
|
||||
btn:[Play Streams] button can be clicked directly and opens RTP Player window directly with btn:[Set playlist] action. All actions can be selected with the small down arrow next to the button.
|
||||
|
||||
When playlist is empty, there is no difference between btn:[Set playlist] and btn:[Add to playlist]. When RTP Player window is not opened, all three actions above open it.
|
||||
When the playlist is empty, there is no difference between btn:[Set playlist] and btn:[Add to playlist]. When the RTP Player window is not opened, all three actions above open it.
|
||||
|
||||
btn:[Remove from playlist] is useful e. g. in case user selected all RTP streams and wants to remove RTP streams from specific calls found with menu:VoIPCalls[].
|
||||
btn:[Remove from playlist] is useful e.g. in case user selected all RTP streams and wants to remove RTP streams from specific calls found with menu:VoIPCalls[].
|
||||
|
||||
Tools below can be used to maintain content of playlist, they contain btn:[Play Streams] button. You can use one of procedures (Note: btn:[Add to playlist] action is demonstrated):
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ When live capture is running, streams are read only till "now" and are shown. Wh
|
|||
|
||||
[NOTE]
|
||||
====
|
||||
RTP Player dialog stays open even live capture is stopped and then started again. Play list stays unchanged. Therefore btn:[Refresh stream] tries to read same streams as before and shows them if they are still running. Past part of them (from previous live capture) is lost.
|
||||
RTP Player dialog stays open even live capture is stopped and then started again. Play list stays unchanged. Therefore, btn:[Refresh stream] tries to read same streams as before and shows them if they are still running. Past part of them (from previous live capture) is lost.
|
||||
====
|
||||
|
||||
==== RTP Decoding Settings
|
||||
|
|
@ -121,7 +121,7 @@ RTP Player must store decoded data somewhere to be able to play it. When data ar
|
|||
* ui.rtp_player_use_disk1 - When set to FALSE (default), audio samples are kept in memory. When set to TRUE, audio samples are stored on temporary file.
|
||||
* ui.rtp_player_use_disk2 - When set to FALSE (default), dictionary is kept in memory. When set to TRUE, dictionary is stored on temporary file.
|
||||
|
||||
When any data are configured to be stored on disk, one file is created for each stream. Therefore there might be up to two files for one RTP stream (audio samples and dictionary). If your OS or user has OS enforced limit for count of opened files (most of Unix/Linux systems), you can see fewer streams that was added to playlist. Warnings are printed on console in this case and you will see fewer streams in the playlist than you send to it from other tools.
|
||||
When any data are configured to be stored on disk, one file is created for each stream. Therefore, there might be up to two files for one RTP stream (audio samples and dictionary). If your OS or user has OS enforced limit for count of opened files (most of Unix/Linux systems), you can see fewer streams that was added to playlist. Warnings are printed on console in this case and you will see fewer streams in the playlist than you send to it from other tools.
|
||||
|
||||
For common use you can use default settings - store everything in memory. When you will be out of memory, switch ui.rtp_player_use_disk1 to TRUE first - it saves much more memory than ui.rtp_player_use_disk2.
|
||||
|
||||
|
|
@ -280,7 +280,7 @@ This menu shows MTP3 Statistics and MTP3 Summary windows.
|
|||
|
||||
=== Osmux Windows
|
||||
|
||||
OSmux is a multiplex protocol which benefits satellite based GSM back-haul systems by reducing the bandwidth consumption of the voice proxying (RTP-AMR) and signaling traffic. The OSmux menu opens the packet counter window with the related statistic data. The user can filter, copy or save the data into a file.
|
||||
OSmux is a multiplex protocol designed to reduce bandwidth usage of satellite-based GSM systems's voice (RTP-AMR) and signaling traffic. The OSmux menu opens the packet counter window with the related statistic data. The user can filter, copy or save the data into a file.
|
||||
|
||||
=== RTP
|
||||
|
||||
|
|
@ -432,7 +432,7 @@ Playlist shows information about every stream:
|
|||
* Time Span - Start - Stop (Duration) of the stream
|
||||
* SR - Sample rate of used codec
|
||||
* PR - Decoded play rate used for stream playing
|
||||
* Payloads - One or more playload types used by the stream
|
||||
* Payloads - One or more payload types used by the stream
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
|
@ -531,7 +531,7 @@ Export of payload function is useful for codecs not supported by Wireshark.
|
|||
|
||||
[NOTE]
|
||||
====
|
||||
Default value of btn:[Output Audio Rate] is btn:[Automatic]. When multiple codecs with different codec rates are captured, Wireshark decodes each stream with its own play audio rate. Therefore each stream can has different play audio rate. When export of audio is used in this case, it will fail because .au or .wav requires one common play audio rate.
|
||||
Default value of btn:[Output Audio Rate] is btn:[Automatic]. When multiple codecs with different codec rates are captured, Wireshark decodes each stream with its own play audio rate. Therefore, each stream can have a different audio rate. If you attempt to export audio when there are multiple audio rates, it will fail because .au or .wav require a fixed audio rate.
|
||||
|
||||
In this case user must manually select one of rates in btn:[Output Audio Rate], streams will be resampled and audio export succeeds.
|
||||
====
|
||||
|
|
@ -548,7 +548,7 @@ In the Real Time Streaming Protocol (RTSP) menu the user can check the Packet Co
|
|||
|
||||
Stream Control Transmission Protocol (SCTP) is a computer network protocol which provides a message transfer in telecommunication in the transport layer. It overcomes some lacks of User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). The SCTP packets consist of the _common header_ and the _data chunks_.
|
||||
|
||||
The SCTP Analyze Association window shows the statistics of the captured packets between two Endpoints. You can check the different chunk types by pressing btn:[Chunk Statistics] button in the `Statistics` tab. In the `Endpoint` tabs you can see various statistics, such as IP addresses, ports and others. Also you can check different graphs here.
|
||||
The SCTP Analyze Association window shows the statistics of the captured packets between two Endpoints. You can check the different chunk types by pressing btn:[Chunk Statistics] button in the `Statistics` tab. In the `Endpoint` tabs you can see various statistics, such as IP addresses, ports and others. You can also check different graphs here.
|
||||
|
||||
.SCTP Analyze Association window
|
||||
image::wsug_graphics/ws-sctp-1-association.png[{screenshot-attrs}]
|
||||
|
|
|
|||
Loading…
Reference in New Issue