diff options
| -rw-r--r-- | docbook/wsug_src/WSUG_app_files.adoc | 8 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_app_howitworks.adoc | 10 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_app_messages.adoc | 4 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_app_protocols.adoc | 2 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_app_tools.adoc | 6 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_advanced.adoc | 96 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_build_install.adoc | 2 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_capture.adoc | 32 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_customize.adoc | 32 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_io.adoc | 54 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_mate.adoc | 22 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_statistics.adoc | 14 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_telephony.adoc | 10 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_use.adoc | 26 | ||||
| -rw-r--r-- | docbook/wsug_src/WSUG_chapter_work.adoc | 20 | ||||
| -rw-r--r-- | docbook/wsug_src/editcap-h.txt | 8 | ||||
| -rw-r--r-- | docbook/wsug_src/text2pcap-h.txt | 2 | ||||
| -rw-r--r-- | docbook/wsug_src/tshark-h.txt | 8 |
18 files changed, 178 insertions, 178 deletions
diff --git a/docbook/wsug_src/WSUG_app_files.adoc b/docbook/wsug_src/WSUG_app_files.adoc index 99c6fbaba0..664c7c1dd4 100644 --- a/docbook/wsug_src/WSUG_app_files.adoc +++ b/docbook/wsug_src/WSUG_app_files.adoc @@ -22,7 +22,7 @@ Wireshark also supports the link:https://gitlab.com/wireshark/wireshark/-/wikis/Development/LibpcapFileFormat[libpcap] file format. This is a much simpler format and is well established. However, it has some drawbacks: it’s not extensible and lacks some information that would be -really helpful (e.g. being able to add a comment to a packet such as “the +really helpful (e.g., being able to add a comment to a packet such as “the problems start here” would be really nice). In addition to the libpcap format, Wireshark supports several different capture @@ -36,7 +36,7 @@ formats. At the start of each libpcap capture file some basic information is stored like a magic number to identify the libpcap file format. The most interesting information of this file start is the link layer type (Ethernet, 802.11, -MPLS, etc). +MPLS, etc.). The following data is saved for each packet: @@ -133,7 +133,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. @@ -312,7 +312,7 @@ disabled protocols file. ethers:: + -- -When Wireshark is trying to translate an hardware MAC address to +When Wireshark is trying to translate a hardware MAC address to a name, it consults the _ethers_ file in the personal configuration folder first. If the address is not found in that file, Wireshark consults the _ethers_ file in the system configuration folder. diff --git a/docbook/wsug_src/WSUG_app_howitworks.adoc b/docbook/wsug_src/WSUG_app_howitworks.adoc index 00dc10d49a..13cb81766a 100644 --- a/docbook/wsug_src/WSUG_app_howitworks.adoc +++ b/docbook/wsug_src/WSUG_app_howitworks.adoc @@ -48,12 +48,12 @@ But how does Wireshark know which dissector to use? When Wireshark starts each dissector registers itself in one of two ways: * _Static_. If the dissector knows a specific value of a lower layer, it can - directly register itself there (e.g. the HTTP dissector “knows”, that - typically the well known TCP port 80 is used to transport HTTP data). + directly register itself there (e.g., the HTTP dissector “knows”, that + typically the well-known TCP port 80 is used to transport HTTP data). -* _Heuristic_. If no such well known way exists, the dissector - can register itself for the heuristic mechanism. If a lower layer dissector - has to handle some packet data where no well known way exists, it can +* _Heuristic_. If no such well-known way exists, the dissector + can register itself for the heuristic mechanism. If a lower-layer dissector + has to handle some packet data where no well-known way exists, it can handover the packet to Wireshark’s heuristic mechanism. This will ask all registered upper layer dissectors, if they “like” that data. These dissectors typically look at the first few bytes of the packet, to see if they diff --git a/docbook/wsug_src/WSUG_app_messages.adoc b/docbook/wsug_src/WSUG_app_messages.adoc index 0d8acdceb4..bd3291ede3 100644 --- a/docbook/wsug_src/WSUG_app_messages.adoc +++ b/docbook/wsug_src/WSUG_app_messages.adoc @@ -21,7 +21,7 @@ Malformed packet means that the protocol dissector can’t dissect the contents the packet any further. There can be various reasons: * __Wrong dissector__: Wireshark erroneously has chosen the wrong protocol - dissector for this packet. This will happen e.g. if you are using a protocol + dissector for this packet. This will happen e.g., if you are using a protocol not on its well known TCP or UDP port. You may try Analyze|Decode As to circumvent this problem. @@ -74,7 +74,7 @@ The time between the request and the response packets. ==== [Stream setup by PROTOCOL (frame 123)] -The session control protocol (SDP, H225, etc) message which signaled the +The session control protocol (SDP, H225, etc.) message which signaled the creation of this session. You can directly jump to the corresponding packet by double clicking on this message. diff --git a/docbook/wsug_src/WSUG_app_protocols.adoc b/docbook/wsug_src/WSUG_app_protocols.adoc index 5849ea5e8c..8f2b8b92ee 100644 --- a/docbook/wsug_src/WSUG_app_protocols.adoc +++ b/docbook/wsug_src/WSUG_app_protocols.adoc @@ -5,7 +5,7 @@ [appendix] == Protocols and Protocol Fields -Wireshark distinguishes between protocols (e.g. tcp) and protocol fields (e.g. +Wireshark distinguishes between protocols (e.g., tcp) and protocol fields (e.g., tcp.port). A comprehensive list of all protocols and protocol fields can be found diff --git a/docbook/wsug_src/WSUG_app_tools.adoc b/docbook/wsug_src/WSUG_app_tools.adoc index d9ca1581ed..a2e1cd69d5 100644 --- a/docbook/wsug_src/WSUG_app_tools.adoc +++ b/docbook/wsug_src/WSUG_app_tools.adoc @@ -246,7 +246,7 @@ characters “>”. Any lines of text between the bytestring lines is 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 -bytes is ignored (e.g. the character dump). Any hex numbers in this text are +bytes is ignored (e.g., the character dump). Any hex numbers in this text are also ignored. An offset of zero is indicative of starting a new packet, so a single text file with a series of hexdumps can be converted into a packet capture with multiple packets. Packets may be preceded by a timestamp. These @@ -262,8 +262,8 @@ 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 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. +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 inserting dummy L2, L3 and L4 headers before each packet. Possibilities include diff --git a/docbook/wsug_src/WSUG_chapter_advanced.adoc b/docbook/wsug_src/WSUG_chapter_advanced.adoc index 07e8e0e223..5f884eb038 100644 --- a/docbook/wsug_src/WSUG_chapter_advanced.adoc +++ b/docbook/wsug_src/WSUG_chapter_advanced.adoc @@ -81,7 +81,7 @@ server to client data. You can choose to view the data in one of the following formats: menu:ASCII[]:: In this view you see the data from each direction in ASCII. - Obviously best for ASCII based protocols, e.g. HTTP. + Obviously best for ASCII based protocols, e.g., HTTP. menu:C Arrays[]:: This allows you to import the stream data into your own C program. @@ -200,7 +200,7 @@ field. Count of streams is fixed to 0 and the field is disabled. === Show Packet Bytes -If a selected packet field does not show all the bytes (i.e. they are truncated +If a selected packet field does not show all the bytes (i.e., they are truncated when displayed) or if they are shown as bytes rather than string or if they require more formatting because they contain an image or HTML then this dialog can be used. @@ -275,7 +275,7 @@ pressing btn:[Find Next]. === Expert Information Wireshark keeps track of any anomalies and other items of interest it finds in a capture file and shows them in the Expert Information dialog. -The goal is to give you a better idea of uncommon or notable network behaviour and to let novice and expert users find network problems faster than manually scanning through the packet list. +The goal is to give you a better idea of uncommon or notable network behavior and to let novice and expert users find network problems faster than manually scanning through the packet list. [WARNING] .Expert information is only a hint @@ -316,13 +316,13 @@ The following levels are used, from lowest to highest. Wireshark marks them using different colors, which are shown in parentheses: Chat [white blue-background]#(blue)#:: -Information about usual workflow, e.g. a TCP packet with the SYN flag set. +Information about usual workflow, e.g., a TCP packet with the SYN flag set. Note [black aqua-background]#(cyan)#:: -Notable events, e.g. an application returned a common error code such as HTTP 404. +Notable events, e.g., an application returned a common error code such as HTTP 404. Warn [black yellow-background]#(yellow)#:: -Warnings, e.g. application returned an unusual error code like a connection problem. +Warnings, e.g., application returned an unusual error code like a connection problem. Error [white red-background]#(red)#:: Serious problems, such as malformed packets. @@ -362,23 +362,23 @@ Malformed packet or dissector has a bug. Dissection of this packet aborted. Protocol:: -Violation of a protocol’s specification (e.g. invalid field values or illegal lengths). +Violation of a protocol’s specification (e.g., invalid field values or illegal lengths). Dissection of this packet probably continued. Reassemble:: -Problems while reassembling, e.g. not all fragments were available or an exception happened during reassembly. +Problems while reassembling, e.g., not all fragments were available or an exception happened during reassembly. Request Code:: -An application request (e.g. File Handle == _x_). Usually assigned the Chat severity level. +An application request (e.g., File Handle == _x_). Usually assigned the Chat severity level. Response Code:: -An application response code indicates a potential problem, e.g. HTTP 404 page not found. +An application response code indicates a potential problem, e.g., HTTP 404 page not found. Security:: -A security problem, e.g. an insecure implementation. +A security problem, e.g., an insecure implementation. Sequence:: -A protocol sequence number was suspicious, e.g. it wasn’t continuous or a retransmission was detected. +A protocol sequence number was suspicious, e.g., it wasn’t continuous or a retransmission was detected. Undecoded:: Dissection incomplete or data can’t be decoded for other reasons. @@ -456,7 +456,7 @@ Closes the dialog .The “Colorized” protocol details tree image::wsug_graphics/ws-expert-colored-tree.png[{screenshot-attrs}] -The packet detail tree marks fields with expert information based on their severity level color, e.g. “Warning” severities have a yellow background. +The packet detail tree marks fields with expert information based on their severity level color, e.g., “Warning” severities have a yellow background. This color is propagated to the top-level protocol item in the tree in order to make it easy to find the field that created the expert information. For the example screenshot above, the IP “Time to live” value is very low (only 1), so the corresponding protocol field is marked with a cyan background. @@ -530,7 +530,7 @@ Set when all of the following are true: * The segment size is zero. * The window size is non-zero and hasn’t changed. -* The next expected sequence number and last-seen acknowledgment number are non-zero (i.e. the connection has been established). +* The next expected sequence number and last-seen acknowledgment number are non-zero (i.e., the connection has been established). * SYN, FIN, and RST are not set. // TCP_A_FAST_RETRANSMISSION @@ -702,7 +702,7 @@ protocol level. ==== TCP Conversation Completeness TCP conversations are said to be complete when they have both opening and closing -handshakes, independently of any data transfer. However we might be interested in +handshakes, independently of any data transfer. However, we might be interested in identifying complete conversations with some data sent, and we are using the following bit values to build a filter value on the tcp.completeness field : @@ -756,7 +756,7 @@ capturing hardware, this resolution should be adequate. Every capture file format that Wireshark knows supports time stamps. The time stamp precision supported by a specific capture file format differs widely and varies from one second “0” to one nanosecond “0.123456789”. Most file -formats store the time stamps with a fixed precision (e.g. microseconds), while +formats store the time stamps with a fixed precision (e.g., microseconds), while some file formats are even capable of storing the time stamp precision itself (whatever the benefit may be). @@ -774,7 +774,7 @@ precision from nanosecond to microsecond. People often ask “Which time stamp accuracy is provided by Wireshark?”. Well, Wireshark doesn’t create any time stamps itself but simply gets them from “somewhere else” and displays them. So accuracy will depend on the capture -system (operating system, performance, etc) that you use. Because of this, the +system (operating system, performance, etc.) that you use. Because of this, the above question is difficult to answer in a general way. [NOTE] @@ -828,12 +828,12 @@ used as it is slightly incorrect (up to 0.9 seconds difference to UTC). The UTC base time equals to 0 (based at Greenwich, England) and all time zones have an offset to UTC between -12 to +14 hours! -For example: If you live in Berlin you are in a time zone one hour earlier than +For example: If you live in Berlin, you are in a time zone one hour earlier than UTC, so you are in time zone “+1” (time difference in hours compared to UTC). If it’s 3 o’clock in Berlin it’s 2 o’clock in UTC “at the same moment”. Be aware that at a few places on earth don’t use time zones with even hour -offsets (e.g. New Delhi uses UTC+05:30)! +offsets (e.g., New Delhi uses UTC+05:30)! Further information can be found at: {wikipedia-main-url}Time_zone and {wikipedia-main-url}Coordinated_Universal_Time. @@ -849,7 +849,7 @@ zone calculations”. Unfortunately, the date at which DST actually takes effect is different throughout the world. You may also note, that the northern and southern -hemispheres have opposite DST’s (e.g. while it’s summer in Europe it’s winter in +hemispheres have opposite DST’s (e.g., while it’s summer in Europe it’s winter in Australia). Keep in mind: UTC remains the same all year around, regardless of DST! @@ -879,7 +879,7 @@ networking gear to UTC in order to make coordination and troubleshooting easier. [TIP] ==== -If you travel around the world, it’s an often made mistake to adjust the hours +If you travel around the world, it’s an often-made mistake to adjust the hours of your computer clock to the local time. Don’t adjust the hours but your time zone setting instead! For your computer, the time is essentially the same as before, you are simply in a different time zone with a different local time. @@ -940,7 +940,7 @@ in which the packet was captured. |_Displayed Time (Local Time)_|02:00|05:00|09:00|10:00|11:00|19:00 |=== -For example let’s assume that someone in Los Angeles captured a packet with +For example, let’s assume that someone in Los Angeles captured a packet with Wireshark at exactly 2 o’clock local time and sends you this capture file. The capture file’s time stamp will be represented in UTC as 10 o’clock. You are located in Berlin and will see 11 o’clock on your Wireshark display. @@ -966,8 +966,8 @@ every computer in question has the correct time and time zone setting. ==== What Is It? Network protocols often need to transport large chunks of data which are -complete in themselves, e.g. when transferring a file. The underlying protocol -might not be able to handle that chunk size (e.g. limitation of the network +complete in themselves, e.g., when transferring a file. The underlying protocol +might not be able to handle that chunk size (e.g., limitation of the network packet size), or is stream-based like TCP, which doesn’t know data chunks at all. @@ -976,8 +976,8 @@ In that case the network protocol has to handle the chunk boundaries itself and mechanism to determine the chunk boundaries on the receiving side. Wireshark calls this mechanism reassembly, although a specific protocol -specification might use a different term for this (e.g. desegmentation, -defragmentation, etc). +specification might use a different term for this (e.g., desegmentation, +defragmentation, etc.). ==== How Wireshark Handles It @@ -1000,7 +1000,7 @@ multiple tabs in the “Packet Bytes” pane appear. You will find the reassembled data in the last packet of the chunk. ==== -For example, in a _HTTP_ GET response, the requested data (e.g. an HTML page) is +For example, in a _HTTP_ GET response, the requested data (e.g., an HTML page) is returned. Wireshark will show the hex dump of the data in a new tab “Uncompressed entity body” in the “Packet Bytes” pane. @@ -1008,15 +1008,15 @@ Reassembly is enabled in the preferences by default but can be disabled in the preferences for the protocol in question. Enabling or disabling reassembly settings for a protocol typically requires two things: -. The lower level protocol (e.g., TCP) must support reassembly. Often this +. The lower-level protocol (e.g., TCP) must support reassembly. Often this reassembly can be enabled or disabled via the protocol preferences. -. The higher level protocol (e.g., HTTP) must use the reassembly mechanism to +. The higher-level protocol (e.g., HTTP) must use the reassembly mechanism to reassemble fragmented protocol data. This too can often be enabled or disabled via the protocol preferences. -The tooltip of the higher level protocol setting will notify you if and which -lower level protocol setting also has to be considered. +The tooltip of the higher-level protocol setting will notify you if and which +lower-level protocol setting also has to be considered. [#ChAdvReassemblyTcp] @@ -1025,13 +1025,13 @@ lower level protocol setting also has to be considered. Protocols such as HTTP or TLS are likely to span multiple TCP segments. The TCP protocol preference “Allow subdissector to reassemble TCP streams” (enabled by default) makes it possible for Wireshark to collect a contiguous sequence of -TCP segments and hand them over to the higher level protocol (for example, to +TCP segments and hand them over to the higher-level protocol (for example, to reconstruct a full HTTP message). All but the final segment will be marked with “[TCP segment of a reassembled PDU]” in the packet list. Disable this preference to reduce memory and processing overhead if you are only interested in TCP sequence number analysis (<<ChAdvTCPAnalysis>>). Keep in mind, -though, that higher level protocols might be wrongly dissected. For example, +though, that higher-level protocols might be wrongly dissected. For example, HTTP messages could be shown as “Continuation” and TLS records could be shown as “Ignored Unknown Record”. Such results can also be observed if you start capturing while a TCP connection was already started or when TCP segments @@ -1042,7 +1042,7 @@ To reassemble of out-of-order TCP segments, the TCP protocol preference enabled in addition to the previous preference. If all packets are received in-order, this preference will not have any effect. Otherwise (if missing segments are encountered while sequentially processing a -packet capture), it is assumes that the new and missing segments belong to the +packet capture), it is assuming that the new and missing segments belong to the same PDU. Caveats: * Lost packets are assumed to be received out-of-order or retransmitted later. @@ -1102,13 +1102,13 @@ you hours of work. Unfortunately, it also has its drawbacks. the name is also not found in Wireshark’s configuration files. * _Resolved names might not be available._ -Wireshark obtains name resolution information from a variety of sources, including DNS servers, the capture file itself (e.g. for a pcapng file), and the _hosts_ files on your system and in your <<ChAppFilesConfigurationSection,profile directory>>. +Wireshark obtains name resolution information from a variety of sources, including DNS servers, the capture file itself (e.g., for a pcapng file), and the _hosts_ files on your system and in your <<ChAppFilesConfigurationSection,profile directory>>. The resolved names might not be available if you open the capture file later or on a different machine. As a result, each time you or someone else opens a particular capture file it may look slightly different due to changing environments. * _DNS may add additional packets to your capture file._ You might run into the link:{wikipedia-main-url}Observer_effect_(information_technology)[observer effect] if the extra traffic from Wireshark’s DNS queries and responses affects the problem you're trying to troubleshoot or any subsequent analysis. + -The same sort of thing can happen when capturing over a remote connection, e.g. SSH or RDP. +The same sort of thing can happen when capturing over a remote connection, e.g., SSH or RDP. // XXX Are there any other such packets than DNS ones? @@ -1116,7 +1116,7 @@ The same sort of thing can happen when capturing over a remote connection, e.g. performance. However, if the name resolution information should change while Wireshark is running, Wireshark won’t notice a change in the name resolution information once it gets cached. If this information changes while Wireshark - is running, e.g. a new DHCP lease takes effect, Wireshark won’t notice it. + is running, e.g., a new DHCP lease takes effect, Wireshark won’t notice it. // XXX Is this true for all or only for DNS info? @@ -1130,7 +1130,7 @@ However, this isn’t possible while a capture is in progress. ==== Ethernet Name Resolution (MAC Layer) -Try to resolve an Ethernet MAC address (e.g. 00:09:5b:01:02:03) to a human readable name. +Try to resolve an Ethernet MAC address (e.g., 00:09:5b:01:02:03) to a human readable name. __ARP name resolution (system service)__: Wireshark will ask the operating system to convert an Ethernet address to the corresponding IP address (e.g. @@ -1138,7 +1138,7 @@ system to convert an Ethernet address to the corresponding IP address (e.g. __Ethernet codes (ethers file)__: If the ARP name resolution failed, Wireshark tries to convert the Ethernet address to a known device name, which has been -assigned by the user using an _ethers_ file (e.g. 00:09:5b:01:02:03 → +assigned by the user using an _ethers_ file (e.g., 00:09:5b:01:02:03 → homerouter). __Ethernet manufacturer codes (manuf file)__: If neither ARP or ethers returns a @@ -1148,11 +1148,11 @@ an abbreviated manufacturer name, which has been assigned by the IEEE (e.g. ==== IP Name Resolution (Network Layer) -Try to resolve an IP address (e.g. 216.239.37.99) to a human readable name. +Try to resolve an IP address (e.g., 216.239.37.99) to a human readable name. __DNS name resolution (system/library service)__: Wireshark will use a name resolver to convert an IP address to the hostname associated with it -(e.g. 216.239.37.99 -> www.1.google.com). +(e.g., 216.239.37.99 -> www.1.google.com). Most applications use synchronously DNS name resolution. For example, your web browser must resolve the host name portion of a URL before it can connect to the server. @@ -1168,10 +1168,10 @@ You can also edit your system __hosts__ file, but that isn’t generally recomme ==== TCP/UDP Port Name Resolution (Transport Layer) -Try to resolve a TCP/UDP port (e.g. 80) to a human readable name. +Try to resolve a TCP/UDP port (e.g., 80) to a human readable name. __TCP/UDP port conversion (system service)__: Wireshark will ask the operating -system to convert a TCP or UDP port to its well known name (e.g. 80 -> http). +system to convert a TCP or UDP port to its well-known name (e.g., 80 -> http). ==== VLAN ID Resolution @@ -1232,14 +1232,14 @@ Further information about checksums can be found at: ==== Wireshark Checksum Validation -Wireshark will validate the checksums of many protocols, e.g. IP, TCP, UDP, etc. +Wireshark will validate the checksums of many protocols, e.g., IP, TCP, UDP, etc. It will do the same calculation as a “normal receiver” would do, and shows the -checksum fields in the packet details with a comment, e.g. [correct] or +checksum fields in the packet details with a comment, e.g., [correct] or [invalid, must be 0x12345678]. Checksum validation can be switched off for various protocols in the Wireshark -protocol preferences, e.g. to (very slightly) increase performance. +protocol preferences, e.g., to (very slightly) increase performance. If the checksum validation is enabled and it detected an invalid checksum, features like packet reassembly won’t be processed. This is avoided as @@ -1255,7 +1255,7 @@ checksum and the receiving hardware validates this checksum. If the received checksum is wrong Wireshark won’t even see the packet, as the Ethernet hardware internally throws away the packet. -Higher level checksums are “traditionally” calculated by the protocol +Higher-level checksums are “traditionally” calculated by the protocol implementation and the completed packet is then handed over to the hardware. Recent network hardware can perform advanced features such as IP checksum @@ -1284,6 +1284,6 @@ You can do two things to avoid this checksum offloading problem: * Turn off checksum validation of the specific protocol in the Wireshark preferences. Recent releases of Wireshark disable checksum validation by default due to the - prevalance of offloading in modern hardware and operating systems. + prevalence of offloading in modern hardware and operating systems. // End of WSUG Chapter Advanced diff --git a/docbook/wsug_src/WSUG_chapter_build_install.adoc b/docbook/wsug_src/WSUG_chapter_build_install.adoc index df766ca530..b81a4c14c0 100644 --- a/docbook/wsug_src/WSUG_chapter_build_install.adoc +++ b/docbook/wsug_src/WSUG_chapter_build_install.adoc @@ -24,7 +24,7 @@ build Wireshark from source should you choose to do so. The general steps are the following: -. Download the relevant package for your needs, e.g. source or binary +. Download the relevant package for your needs, e.g., source or binary distribution. . For source distributions, compile the source into a binary. diff --git a/docbook/wsug_src/WSUG_chapter_capture.adoc b/docbook/wsug_src/WSUG_chapter_capture.adoc index c28c60a8f2..04eb053553 100644 --- a/docbook/wsug_src/WSUG_chapter_capture.adoc +++ b/docbook/wsug_src/WSUG_chapter_capture.adoc @@ -24,7 +24,7 @@ The Wireshark capture engine provides the following features: * Filter packets, reducing the amount of data to be captured. See <<ChCapCaptureFilterSection>>. -* Save packets in multiple files while doing a long term capture, optionally +* Save packets in multiple files while doing a long-term capture, optionally rotating through a fixed number of files (a “ringbuffer”). See <<ChCapCaptureFiles>>. @@ -139,7 +139,7 @@ Note that another application might override this setting. Snaplen:: The snapshot length, or the number of bytes to capture for each packet. -You can set an explicit length if needed, e.g. for performance or privacy reasons. +You can set an explicit length if needed, e.g., for performance or privacy reasons. Buffer:: The size of the kernel buffer that is reserved for capturing packets. @@ -197,7 +197,7 @@ You can also click on the button to the right of this field to browse through th Output format::: Allows you to set the format of the capture file. pcapng is the default and is more flexible than pcap. -pcapng might be required, e.g. if more than one interface is chosen for capturing. +pcapng might be required, e.g., if more than one interface is chosen for capturing. See {wireshark-wiki-url}Development/PcapNg for more details on pcapng. Create a new file automatically...:: @@ -336,8 +336,8 @@ To add a new remote capture interface, click btn:[{plus}] and specify the follow Host:: The IP address or host name of the target platform where the Remote Packet Capture Protocol service is listening. -The drop down list contains the hosts that have previously been successfully contacted. -The list can be emptied by choosing “Clear list” from the drop down list. +The drop-down list contains the hosts that have previously been successfully contacted. +The list can be emptied by choosing “Clear list” from the drop-down list. Port:: Set the port number where the Remote Packet Capture Protocol service is listening on. @@ -346,13 +346,13 @@ Leave blank to use the default port (2002). Null authentication:: Select this if you don’t need authentication to take place for a remote capture to be started. This depends on the target platform. -This is exactly as secure as it appears, i.e. it is not secure at all. +This is exactly as secure as it appears, i.e., it is not secure at all. Password authentication:: Lets you specify the username and password required to connect to the Remote Packet Capture Protocol service. Each interface can optionally be hidden. -In contrast to the local interfaces they are not saved in the `preferences` file. +In contrast to the local interfaces, they are not saved in the `preferences` file. [NOTE] ==== @@ -447,15 +447,15 @@ The results of compiling a filter for the selected interface are shown on the ri === Capture files and file modes -While capturing the underlying libpcap capturing engine will grab the packets +While capturing, the underlying libpcap capturing engine will grab the packets from the network card and keep the packet data in a (relatively) small kernel buffer. This data is read by Wireshark and saved into a capture file. -By default Wireshark saves packets to a temporary file. You can also tell +By default, Wireshark saves packets to a temporary file. You can also tell Wireshark to save to a specific (“permanent”) file and switch to a different file after a given time has elapsed or a given number of packets -have been captured. These options are controlled in the “Output” tab in -the “Capture Options” dialog. +have been captured. These options are controlled in the +“Capture Options” dialog's “Output” tab. [#ChCapCaptureOptionsOutputDialog] .Capture output options @@ -464,7 +464,7 @@ image::wsug_graphics/ws-capture-options-output.png[{screenshot-attrs}] [TIP] ==== Working with large files (several hundred MB) can be quite slow. If you plan to do -a long term capture or capturing from a high traffic network, think about using +a long-term capture or capturing from a high traffic network, think about using one of the “Multiple files” options. This will spread the captured packets over several smaller files which can be much more pleasant to work with. ==== @@ -472,7 +472,7 @@ several smaller files which can be much more pleasant to work with. Using the “Multiple files” option may cut context related information. Wireshark keeps context information of the loaded packet data, so it can report context related problems (like a stream error) and keeps information about context related -protocols (e.g. where data is exchanged at the establishing phase and only +protocols (e.g., where data is exchanged at the establishing phase and only referred to in later packets). As it keeps this information only for the loaded file, using one of the multiple file modes may cut these contexts. If the establishing phase is saved in one file and the things you would like to see is @@ -498,7 +498,7 @@ After capturing is stopped this file can be saved later under a user specified n Single named file:: A single capture file will be used. -If you want to place the new capture file in a specific folder choose this mode. +Choose this mode if you want to place the new capture file in a specific folder. Multiple files, continuous:: Like the “Single named file” mode, but a new file is created and used after reaching one of the multiple file switch conditions (one of the “Next file every...” values). @@ -650,7 +650,7 @@ Please see the pcap-filter man page at {pcap-filter-man-page-url} for more detai ==== Automatic Remote Traffic Filtering -If Wireshark is running remotely (using e.g. SSH, an exported X11 window, a +If Wireshark is running remotely (using e.g., SSH, an exported X11 window, a terminal server, ...), the remote content has to be transported over the network, adding a lot of (usually unimportant) packets to the actually interesting traffic. @@ -710,7 +710,7 @@ A running capture session will be stopped in one of the following ways: . Pressing kbd:[Ctrl+E]. . The capture will be automatically stopped if one of the _Stop Conditions_ is - met, e.g. the maximum amount of data was captured. + met, e.g., the maximum amount of data was captured. [#ChCapRestartSection] diff --git a/docbook/wsug_src/WSUG_chapter_customize.adoc b/docbook/wsug_src/WSUG_chapter_customize.adoc index 9c8506be47..0750b6ad3f 100644 --- a/docbook/wsug_src/WSUG_chapter_customize.adoc +++ b/docbook/wsug_src/WSUG_chapter_customize.adoc @@ -8,7 +8,7 @@ === Introduction -Wireshark’s default behaviour will usually suit your needs pretty well. However, +Wireshark’s default behavior will usually suit your needs pretty well. However, as you become more familiar with Wireshark, it can be customized in various ways to suit your needs even better. In this chapter we explore: @@ -308,7 +308,7 @@ addresses received by that machine. -P <path setting>:: Special path settings usually detected automatically. This is used for special -cases, e.g. starting Wireshark from a known location on an USB stick. +cases, e.g., starting Wireshark from a known location on an USB stick. + The criterion is of the form key:path, where key is one of: + @@ -785,7 +785,7 @@ dialog works very similarly to that of <<ChCustColorizationSection>>. === Display Filter Macros Display Filter Macros are a mechanism to create shortcuts for complex filters. -For example defining a display filter macro named _$$tcp_conv$$_ whose text is +For example, defining a display filter macro named _$$tcp_conv$$_ whose text is ---- (ip.src == $1 and ip.dst == $2 and tcp.srcport == $3 and tcp.dstport == $4) @@ -918,22 +918,22 @@ associated values, the extensibility means that other values may be encountered. Wireshark uses this table to allow the user to define the name and syntax of Object Identifiers that Wireshark does not know about (for example, a privately defined X.400 extension). It also allows the user to override the name and -syntax of Object Identifiers that Wireshark does know about (e.g. changing the +syntax of Object Identifiers that Wireshark does know about (e.g., changing the name “id-at-countryName” to just “c”). This table is a user table, as described in <<ChUserTable>>, with the following fields: OID:: -The string representation of the Object Identifier e.g. “2.5.4.6”. +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 -of the syntaxes that Wireshark already knows about (e.g. “PrintableString”). +of the syntaxes that Wireshark already knows about (e.g., “PrintableString”). [#ChPresContextList] @@ -985,7 +985,7 @@ If your copy of Wireshark supports libSMI, you can specify a list of MIB and PIB modules here. The COPS and SNMP dissectors can use them to resolve OIDs. Module name:: -The name of the module, e.g. IF-MIB. +The name of the module, e.g., IF-MIB. [#ChSNMPSMIPaths] @@ -995,7 +995,7 @@ If your copy of Wireshark supports libSMI, you can specify one or more paths to MIB and PIB modules here. Directory name:: -A module directory, e.g. `/usr/local/snmp/mibs`. Wireshark automatically uses +A module directory, e.g., `/usr/local/snmp/mibs`. Wireshark automatically uses the standard SMI path for your system, so you usually don’t have to add anything here. @@ -1033,7 +1033,7 @@ following fields: Engine ID:: If given this entry will be used only for packets whose engine id is this. This -field takes an hexadecimal string in the form 0102030405. +field takes a hexadecimal string in the form 0102030405. Username:: This is the userName. When a single user has more than one password for @@ -1048,16 +1048,16 @@ 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_. +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 +The privacy 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 _\x01\x02\x03\x04\x05\x06_. The _\_ -character must be treated as an unprintable character, i.e. it must be entered +character must be treated as an unprintable character, i.e., it must be entered as _\x5C_ or _\x5c_. [#ChK12ProtocolsSection] @@ -1078,7 +1078,7 @@ specific case and a general one the specific one must appear first in the list. 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, +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, sscop:nbap, ...) @@ -1098,7 +1098,7 @@ One of the user dlts. Payload protocol:: This is the name of the payload protocol (the lowest layer in the packet data). -(e.g. “eth” for ethernet, “ip” for IPv4) +(e.g., “eth” for ethernet, “ip” for IPv4) Header size:: If there is a header protocol (before the payload protocol) this tells which diff --git a/docbook/wsug_src/WSUG_chapter_io.adoc b/docbook/wsug_src/WSUG_chapter_io.adoc index e202a2fc54..c8a353ec5d 100644 --- a/docbook/wsug_src/WSUG_chapter_io.adoc +++ b/docbook/wsug_src/WSUG_chapter_io.adoc @@ -52,7 +52,7 @@ sections show some examples of the Wireshark “Open File” dialog box. The appearance of this dialog depends on the system. However, the functionality should be the same across systems. -Common dialog behaviour on all systems: +Common dialog behavior on all systems: * Select files and directories. @@ -73,7 +73,7 @@ Wireshark adds the following controls: Read filters can be used to exclude various types of traffic, which can be useful for large capture files. They use the same syntax as display filters, which are discussed in detail in <<ChWorkDisplayFilterSection>>. -* Optionally force Wireshark to read a file as a particular type using the “Automatically detect file type” dropdown. +* Optionally force Wireshark to read a file as a particular type using the “Automatically detect file type” drop-down. [#ChIOOpenFileDialogWin32] @@ -131,7 +131,7 @@ The following file formats from other capture tools can be opened by Wireshark: * RADCOM’s WAN/LAN Analyzer captures -* Viavi (previously Network Instruments)i Observer captures +* Viavi (previously Network Instruments) Observer captures * Lucent/Ascend router debug output @@ -256,7 +256,7 @@ You can perform the following actions: * Select the directory to save the file into. -* Specify the format of the saved capture file by clicking on the “Save as” drop down box. +* Specify the format of the saved capture file by clicking on the “Save as” drop-down box. You can choose from the types described in <<ChIOOutputFormatsSection>>. Some capture formats may not be available depending on the packet types captured. @@ -268,7 +268,7 @@ You can perform the following actions: * Click on the btn:[Cancel] button to go back to Wireshark without saving any packets. -If you don’t provide a file extension to the filename (e.g. `.pcap`) Wireshark will append the standard file extension for that file format. +If you don’t provide a file extension to the filename (e.g., `.pcap`) Wireshark will append the standard file extension for that file format. [TIP] .Wireshark can convert file formats @@ -352,7 +352,7 @@ Whether or not the above tools will be more helpful than Wireshark is a differen .Third party protocol analyzers may require specific file extensions ==== Wireshark examines a file’s contents to determine its type. Some other protocol -analyzers only look at a filename extensions. For example, you might need to use +analyzers only look at a file's extension. For example, you might need to use the `.cap` extension in order to open a file using the Windows version of _Sniffer_. ==== @@ -363,7 +363,7 @@ of _Sniffer_. Sometimes you need to merge several capture files into one. For example, this can be useful if you have captured simultaneously from multiple interfaces at once -(e.g. using multiple instances of Wireshark). +(e.g., using multiple instances of Wireshark). There are three ways to merge capture files using Wireshark: @@ -373,7 +373,7 @@ There are three ways to merge capture files using Wireshark: * Use _drag and drop_ to drop multiple files on the main window. Wireshark will try to merge the packets in chronological order from the dropped files into a newly created temporary file. - If you drop a single file it will simply replace the existing capture. + If you drop a single file, it will simply replace the existing capture. * Use the `mergecap` tool from the command line to merge capture files. This tool provides the most options to merge capture files. @@ -429,7 +429,7 @@ temporary libpcap capture file. It can read hex dumps with multiple packets in them, and build a capture file of multiple packets. It is also capable of generating dummy Ethernet, IP and UDP, TCP, or SCTP headers, in order to build fully processable packet dumps from hexdumps of application-level data only. -Alternatively a Dummy PDU header can be added to specify a dissector the data +Alternatively, a Dummy PDU header can be added to specify a dissector the data should be passed to initially. Two methods for converting the input are supported: @@ -460,7 +460,7 @@ that of the previous packet. Other text in the input data is ignored. Any text before the offset is ignored, including email forwarding characters '>'. Any text on a line -after the bytes is ignored, e.g. an ASCII character dump (but see *-a* to +after the bytes is ignored, e.g., an ASCII character dump (but see *-a* to ensure that hex digits in the character dump are ignored). Any line where the first non-whitespace character is a '#' will be ignored as a comment. Any lines of text between the bytestring lines are considered preamble; @@ -470,8 +470,8 @@ timestamp as mentioned above and otherwise ignored. Any line beginning with #TEXT2PCAP is a directive and options can be inserted after this command to be processed by Wireshark. 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. +be used to give more fine-grained control on the dump and the way it +should be processed e.g., timestamps, encapsulation type etc. In general, short of these restrictions, Wireshark is pretty liberal about reading in hexdumps and has been tested with a variety of @@ -494,7 +494,7 @@ I 2019-05-14T19:04:57Z ==== Regular Text Dumps -Wireshark is also capable of scanning the input using a custom perl regular +Wireshark is also capable of scanning the input using a custom Perl regular expression as specified by GLib's https://developer-old.gnome.org/glib/stable/glib-regex-syntax.html[GRegex here]. Using a regex capturing a single packet in the given file wireshark will search the given file from start to the second to last character @@ -507,7 +507,7 @@ standard libpcap file retaining packet order. Note that each named capturing subgroup has to match _exactly_ once a packet, but they may be present multiple times in the regex. -For example the following dump: +For example, the following dump: ---- > 0:00:00.265620 a130368b000000080060 > 0:00:00.280836 a1216c8b00000000000089086b0b82020407 @@ -528,7 +528,7 @@ encoding: HEX Caution has to be applied when discarding the anchors `^` and `$`, as the input is searched, not parsed, meaning even most incorrect regexes will produce valid -looking results when not anchored (however anchors are not guaranteed to prevent +looking results when not anchored (however, anchors are not guaranteed to prevent this). It is generally recommended to sanity check any files created using this conversion. @@ -550,7 +550,7 @@ nanoseconds by one each packet. * dir: the direction the packet was sent over the wire + The captured field is expected to be one character in length, any remaining -characters are ignored (e.g. given "Input" only the 'I' is looked at). This +characters are ignored (e.g., given "Input" only the 'I' is looked at). This character is compared to lists of characters corresponding to inbound and outbound and the packet is assigned the corresponding direction. If neither list yields a match, the direction is set to unknown. @@ -559,7 +559,7 @@ If this field is not specified the entire file has no directional information. + * seqno: an ID for this packet + -Each packet can be assigned a arbitrary ID that can used as field by Wireshark. +Each packet can be assigned an arbitrary ID that can used as field by Wireshark. This field is assumed to be a positive integer base 10. This field can e.g. be used to reorder out of order captures after the import. + @@ -635,10 +635,10 @@ Ignored whitespaces are `\r`, `\n`, `\t`, `\v`, ` ` and only for hex `:`, only for base64 `=`. + Any incomplete bytes at the field's end are assumed to be padding to fill the -last complete byte. These bits should be zero, however this is not checked. +last complete byte. These bits should be zero, however, this is not checked. Direction indication:: -The lists of characters indicating incoming vs. outgoing packets. Tese fields +The lists of characters indicating incoming vs. outgoing packets. These fields are only available when the regex contains a `(?<dir>...)` group. ===== Common items @@ -646,7 +646,7 @@ are only available when the regex contains a `(?<dir>...)` group. Timestamp Format:: This is the format specifier used to parse the timestamps in the text file to import. It uses the same format as `strptime(3)` with the addition of `%f` for -zero padded fractions of seconds. The precision of `%f` is determined from it's +zero padded fractions of seconds. The precision of `%f` is determined from its length. The most common fields are `%H`, `%M` and `%S` for hours, minutes and seconds. The straightforward HH:MM:SS format is covered by %T. For a full definition of the syntax look for `strptime(3)`, @@ -668,7 +668,7 @@ Dummy header:: When Ethernet encapsulation is selected you have to option to prepend dummy headers to the frames to import. These headers can provide artificial Ethernet, IP, UDP, TCP or SCTP headers or SCTP data chunks. When selecting a type of -dummy header the applicable entries are enabled, others are grayed out and +dummy header, the applicable entries are enabled, others are greyed out and default values are used. When the _Wireshark Upper PDU export_ encapsulation is selected the option _ExportPDU_ becomes available. This allows you to select the name of the @@ -705,7 +705,7 @@ some features to handle these file sets in a convenient way. **** A filename in a file set uses the format Prefix_Number_DateTimeSuffix which might look something like `test_00001_20220714183910.pcap`. All files of a file -set share the same prefix (e.g. “test”) and suffix (e.g. “.pcap”) and a +set share the same prefix (e.g., “test”) and suffix (e.g., “.pcap”) and a varying middle part. To find the files of a file set, Wireshark scans the directory where the @@ -791,7 +791,7 @@ This lets you save the packet list, packet details, and packet bytes as plain te .The “Export Packet Dissections” dialog box image::wsug_graphics/ws-export-packet-dissections.png[{medium-screenshot-attrs}] -The format can be selected from the “Export As” dropdown and further customized using the “<<ChIOPacketRangeSection,Packet Range>>” and “<<ChIOPacketRangeSection,Packet Format>>” controls. +The format can be selected from the “Export As” drop-down and further customized using the “<<ChIOPacketRangeSection,Packet Range>>” and “<<ChIOPacketRangeSection,Packet Format>>” controls. Some controls are unavailable for some formats, notably CSV and JSON. The following formats are supported: @@ -1027,7 +1027,7 @@ NOTE: The file produced has a `Wireshark Upper PDU` encapsulation type that has ==== The “Strip Headers...” Dialog Box -The “Strip Headers...” dialog box allows you to filter known encapsulation types on whatever protocol layer they appear and export them into a new capture file, removing lower level protocols. It allows you to export reassembled packets and frames without lower layers such as GPF, GRE, GSE, GTP-U, MPLS, MPE, PPP, and more. If Wireshark has performed decryption, then you can export decrypted IP from protocols like IEEE 802.11 or IPSec without having to save encryption keys. +The “Strip Headers...” dialog box allows you to filter known encapsulation types on whatever protocol layer they appear and export them into a new capture file, removing lower-level protocols. It allows you to export reassembled packets and frames without lower layers such as GPF, GRE, GSE, GTP-U, MPLS, MPE, PPP, and more. If Wireshark has performed decryption, then you can export decrypted IP from protocols like IEEE 802.11 or IPSec without having to save encryption keys. The procedure is similar to that of <<ChIOExportPDUSDialog>>: @@ -1189,7 +1189,7 @@ You can use it to specify which packets will be exported or printed. .The “Packet Range” frame image::wsug_graphics/ws-packet-range.png[{medium-screenshot-attrs}] -By default the btn:[Displayed] button is set, which only exports or prints the packets that match the current display filter. +By default, the btn:[Displayed] button is set, which only exports or prints the packets that match the current display filter. Selecting btn:[Captured] will export or print all packets. You can further limit what you export or print to the following: @@ -1206,7 +1206,7 @@ First to last marked:: Lets you mark an inclusive range of packets. Range:: -Lets you manually specify a range of packets, e.g. _5,10-15,20-_ will process the packet number five, the packets from packet number ten to fifteen (inclusive) and every packet from number twenty to the end of the capture. +Lets you manually specify a range of packets, e.g., _5,10-15,20-_ will process the packet number five, the packets from packet number ten to fifteen (inclusive) and every packet from number twenty to the end of the capture. Remove ignored packets:: Don't export or print ignored packets. @@ -1249,6 +1249,6 @@ For printing and some export formats, put each packet on a separate page. For example, when exporting to a text file this will put a form feed character between each packet. Capture information header:: -Add a header to each page with capture filename and the amount of total packets and shown packets. +Add a header to each page with capture filename and the number of total packets and shown packets. // End of WSUG Chapter IO diff --git a/docbook/wsug_src/WSUG_chapter_mate.adoc b/docbook/wsug_src/WSUG_chapter_mate.adoc index 2c9bd48583..5cacea4bdd 100644 --- a/docbook/wsug_src/WSUG_chapter_mate.adoc +++ b/docbook/wsug_src/WSUG_chapter_mate.adoc @@ -15,7 +15,7 @@ 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 -issues regarding a interaction between packets like response times, +issues regarding an interaction between packets like response times, incompleteness of transactions, presence/absence of certain attributes in a group of PDUs and more. @@ -49,7 +49,7 @@ These are the steps to try out MATE: * Run Wireshark and check if the plugin is installed correct (MATE should appear in Help->About->Plugins) -* Get a configuration file e.g. tcp.mate (see {wireshark-wiki-url}Mate/Examples[Mate/Examples] +* Get a configuration file e.g., tcp.mate (see {wireshark-wiki-url}Mate/Examples[Mate/Examples] 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) @@ -1086,7 +1086,7 @@ Extract client From ip.src; Next, we tell MATE to replace ( *dns_resp=1, client* ) with just *dns_resp=1* in the Pdu. That way, we'll keep the attribute *client* only in the DNS request -Pdus (i.e. packets coming from the client).To do so, we have to add a +Pdus (i.e., packets coming from the client).To do so, we have to add a _Transform_ declaration (in this case, with just one clause) before the Pdu declaration which uses it: @@ -1154,7 +1154,7 @@ declarations the following way: Member dns_req (host, client); ---- -Now we got it, every "usage" gets it's own Gog. +Now we got it, every "usage" gets its own Gog. [#ChMateConfigurationExamples] @@ -1419,7 +1419,7 @@ Lib=proto_name;_+. For Every protocol with a library entry, we'll find defined what from the PDU is needed to create a GoP for that protocol, eventually any criteria and the very -essential GoP definition (i.e. __GopDef__, _GopStart_ and _GopStop_). +essential GoP definition (i.e., __GopDef__, _GopStart_ and _GopStop_). [NOTE] ==== @@ -1445,7 +1445,7 @@ _Stop=TRUE;_ so the a TCP PDU is not created where we got already one going on. ===== DNS -will create a GoP containing every request and it's response (eventually +will create a GoP containing every request and its response (eventually retransmissions too). ---- @@ -1866,7 +1866,7 @@ Transforms can be used as helpers to manipulate an item's AVPL before the item is processed further. An item declaration may contain a Transform clause indicating a list of previously declared Transforms. Regardless whether the individual transforms succeed or fail, the list is always executed completely -and in the order given, i.e. left to right. +and in the order given, i.e., left to right. In MATE configuration file, a Transform must be declared before declaring any item which uses it. @@ -1931,13 +1931,13 @@ The Pdu's _Proto_, and its _Transport_ list of protocols separated by / tell MATE which fields of a frame can get into the Pdu's AVPL. In order that MATE would extract an attribute from a frame's protocol tree, the area representing the field in the hex display of the frame must be within the area of either the -_Proto_ or it's relative _Transport_ s. _Transport_ s are chosen moving backwards +_Proto_ or its relative _Transport_ s. _Transport_ s are chosen moving backwards from the protocol area, in the order they are given. _Proto http Transport tcp/ip_ does what you'd expect it to - it selects the nearest tcp range that precedes the current http range, and the nearest ip range that precedes that tcp range. If there is another ip range before the nearest -one (e.g. in case of IP tunneling), that one is not going to be selected. +one (e.g., in case of IP tunneling), that one is not going to be selected. _Transport_ tcp/ip/ip that "logically" should select the encapsulating IP header too doesn't work so far. @@ -1988,8 +1988,8 @@ AVPL, an AVPL match type (_Strict_, _Every_, or _Loose_) and the action to be performed (_Accept_ or _Reject_) if the match succeeds. Once every attribute has been extracted and eventual transform list has been executed, and if the _Criteria_ clause is present, the Pdu's AVPL is matched against the match AVPL; -if the match succeeds, the action specified is executed, i.e. the Pdu is -accepted or rejected. The default behaviours used if the respective keywords are +if the match succeeds, the action specified is executed, i.e., the Pdu is +accepted or rejected. The default behaviors used if the respective keywords are omitted are _Strict_ and _Accept_. Accordingly, if the clause is omitted, all Pdus are accepted. diff --git a/docbook/wsug_src/WSUG_chapter_statistics.adoc b/docbook/wsug_src/WSUG_chapter_statistics.adoc index e019f1ec62..c5813f0d72 100644 --- a/docbook/wsug_src/WSUG_chapter_statistics.adoc +++ b/docbook/wsug_src/WSUG_chapter_statistics.adoc @@ -13,7 +13,7 @@ the menu:Statistics[] menu. These statistics range from general information about the loaded capture file (like the number of captured packets), to statistics about specific protocols -(e.g. statistics about the number of HTTP requests and responses captured). +(e.g., statistics about the number of HTTP requests and responses captured). .General statistics @@ -21,9 +21,9 @@ These statistics range from general information about the loaded capture file - *Protocol Hierarchy* of the captured packets. - - *Conversations* e.g. traffic between specific IP addresses. + - *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 an IP addresses. - *I/O Graphs* visualizing the number of packets (or similar) in time. @@ -171,11 +171,11 @@ be counted for each packet. Example: In the screenshot IP has 99.9% and TCP Protocol layers can consist of packets that won’t contain any higher layer protocol, so the sum of all higher layer packets may not sum up to the protocols packet count. Example: In the screenshot TCP has 98.5% but the sum of the -subprotocols (TLS, HTTP, etc) is much less. This can be caused by continuation +subprotocols (TLS, HTTP, etc.) is much less. This can be caused by continuation frames, TCP protocol overhead, and other undissected data. A single packet can contain the same protocol more than once. In this case, the -protocol is counted more than once. For example ICMP replies and many tunneling +protocol is counted more than once. For example, ICMP replies and many tunneling protocols will carry more than one IP header. [#ChStatConversations] @@ -303,7 +303,7 @@ This window shows statistics about the endpoints captured. image::wsug_graphics/ws-stats-endpoints.png[{screenshot-attrs}] For each supported protocol, a tab is shown in this window. Each tab label shows -the number of endpoints captured (e.g. the tab label “Ethernet · 4” tells +the number of endpoints captured (e.g., the tab label “Ethernet · 4” tells you that four ethernet endpoints have been captured). If no endpoints of a specific protocol were captured, the tab label will be greyed out (although the related page can still be selected). @@ -410,7 +410,7 @@ Color:: The color to use for plotting the graph’s lines, bars, or points. Style:: -How to visually represent the graph’s data, e.g. by drawing a line, bar, circle, plus, etc. +How to visually represent the graph’s data, e.g., by drawing a line, bar, circle, plus, etc. Y Axis:: The value to use for the graph’s Y axis. Can be one of: diff --git a/docbook/wsug_src/WSUG_chapter_telephony.adoc b/docbook/wsug_src/WSUG_chapter_telephony.adoc index 525a6b2041..2ab7377856 100644 --- a/docbook/wsug_src/WSUG_chapter_telephony.adoc +++ b/docbook/wsug_src/WSUG_chapter_telephony.adoc @@ -99,15 +99,15 @@ RTP Player dialog stays open even live capture is stopped and then started again ==== RTP Decoding Settings -RTP is carried usually in UDP packets, on random source and destination port. Therefore without "help" Wireshark can't recognize it and shows just UDP packets. Wireshark recognizes RTP streams based on VoIP signaling, e. g. based on SDP message in SIP signaling. When signaling is not captured, Wireshark shows just UDP packets. There are multiple settings which helps Wireshark to recognize RTP even there is no related signaling. +RTP is carried usually in UDP packets with random source and destination ports. Therefore, Wireshark can only recognize RTP streams based on VoIP signaling, e.g., based on SDP messages in SIP signaling. If signaling is not captured, Wireshark shows just UDP packets. However, there are multiple settings which help Wireshark recognize RTP even when there is no related signaling. You can use <<ChAdvDecodeAsFig,Decode As...>> function from menu:Analyze[Decode As...] menu or in mouse context menu. Here you can set that traffic on specific source or destination should be decoded as RTP. You can save settings for later use. -Use of menu:Decode As...[] menu works fine, but for many streams it is arduous. +Use of menu:Decode As...[] menu works fine, but is arduous for many streams. -You can enable heuristic dissector menu:rtp_udp[] in menu:Analyze[Enabled Protocols...]. See <<ChCustProtocolDissectionSection>> for details. Once menu:rtp_udp[] is enabled, Wireshark tries every UDP packet to decode as RTP. If decoding is possible, packet (and entire UDP stream) is decoded as RTP. +You can enable heuristic dissector menu:rtp_udp[] in menu:Analyze[Enabled Protocols...]. See <<ChCustProtocolDissectionSection>> for details. Once menu:rtp_udp[] is enabled, Wireshark tries to decode every UDP packet as RTP. If decoding is possible, packet (and entire UDP stream) is decoded as RTP. -When RTP stream uses well know port, heuristic dissector ignores it. So you might miss some RTP streams. You can enable setting for udp protocol menu:Preferences[Protocols > udp > Try heuristic sub-dissectors first], see <<ChCustPreferencesSection>>. In this case heuristics dissector tries to decode UDP packet even it uses well known. +When an RTP stream uses a well-known port, the heuristic dissector ignores it. So you might miss some RTP streams. You can enable setting for udp protocol menu:Preferences[Protocols > udp > Try heuristic sub-dissectors first], see <<ChCustPreferencesSection>>. In this case heuristics dissector tries to decode UDP packet even it uses a well-known port. [NOTE] ==== @@ -525,7 +525,7 @@ Export options available: * for just one selected stream ** Payload - just payload with no information about coded is stored in the file -Audio is exported as multi-channel file - one channel per RTP stream. One or two channels are equal to mono or stereo, but Wireshark can export e.g. 100 channels. For playing a tool with multi-channel support must be used (e.g. https://www.audacityteam.org/). +Audio is exported as multi-channel file - one channel per RTP stream. One or two channels are equal to mono or stereo, but Wireshark can export e.g., 100 channels. For playing a tool with multi-channel support must be used (e.g., https://www.audacityteam.org/). Export of payload function is useful for codecs not supported by Wireshark. diff --git a/docbook/wsug_src/WSUG_chapter_use.adoc b/docbook/wsug_src/WSUG_chapter_use.adoc index 4126e72c01..c65e5f1f0c 100644 --- a/docbook/wsug_src/WSUG_chapter_use.adoc +++ b/docbook/wsug_src/WSUG_chapter_use.adoc @@ -30,7 +30,7 @@ When starting Wireshark it’s possible to specify optional settings using the command line. See <<ChCustCommandLine>> for details. ==== -In the following chapters a lot of screenshots from Wireshark will be shown. As +The following chapters contain many screenshots of Wireshark. As Wireshark runs on many different platforms with many different window managers, different styles applied and there are different versions of the underlying GUI toolkit used, your screen might look different from the provided screenshots. @@ -89,7 +89,7 @@ a capture file. See <<ChUseTabGo>> for additional navigation keystrokes. [options="header",cols="1,3"] |=== |Accelerator |Description -|kbd:[Tab] or kbd:[Shift+Tab]|Move between screen elements, e.g. from the toolbars to the packet list to the packet detail. +|kbd:[Tab] or kbd:[Shift+Tab]|Move between screen elements, e.g., from the toolbars to the packet list to the packet detail. |kbd:[↓] |Move to the next packet or detail item. |kbd:[↑] |Move to the previous packet or detail item. |kbd:[Ctrl+↓] or kbd:[F8] |Move to the next packet, even if the packet list isn’t focused. @@ -177,7 +177,7 @@ This menu contains various tools available in Wireshark, such as creating Firewall ACL Rules. See <<ChUseToolsMenuSection>>. menu:Help[]:: -This menu contains items to help the user, e.g. access to some basic help, +This menu contains items to help the user, e.g., access to some basic help, manual pages of the various command line tools, online access to some of the webpages, and the usual about dialog. See <<ChUseHelpMenuSection>>. @@ -187,7 +187,7 @@ Each of these menu items is described in more detail in the sections that follow .Shortcuts make life easier ==== Most common menu items have keyboard shortcuts. For example, you can -press the Control (or Strg in German) and the K keys together to open the +press the Control and the K keys together to open the “Capture Options” dialog. ==== @@ -366,11 +366,11 @@ of some or all packets. |menu:Packet Comment...[] |kbd:[Ctrl+Alt+C] | Opens the “Packet Comment” dialog, which lets you add a comment to a single packet. Note that the ability to save packet comments depends on -your file format. E.g. pcapng supports comments, pcap does not. +your file format. E.g., pcapng supports comments, pcap does not. |menu:Delete All Packet Comments[] || This will delete all comments from all packets. Note that the ability to save -capture comments depends on your file format. E.g. pcapng supports +capture comments depends on your file format. E.g., pcapng supports comments, pcap does not. |menu:Configuration Profiles...[] |kbd:[Ctrl+Shift+A]| @@ -642,7 +642,7 @@ Each menu item brings up a new window showing specific statistics. |menu:Conversations[]|| Display a list of conversations (traffic between two endpoints), see <<ChStatConversationsWindow>>. |menu:Endpoints[]|| Display a list of endpoints (traffic to/from an address), see <<ChStatEndpointsWindow>>. |menu:Packet Lengths[]||See <<ChStatPacketLengths>> -|menu:I/O Graphs[]|| Display user specified graphs (e.g. the number of packets in the course of time), see <<ChStatIOGraphs>>. +|menu:I/O Graphs[]|| Display user specified graphs (e.g., the number of packets in the course of time), see <<ChStatIOGraphs>>. |menu:Service Response Time[]|| Display the time between a request and the corresponding response, see <<ChStatSRT>>. |menu:DHCP (BOOTP)[]||See <<ChStatDHCPBOOTP>> |menu:NetPerfMeter[]||See <<ChStatNetPerfMeter>> @@ -889,7 +889,7 @@ Filter buttons are handy shortcuts that apply a display filter as soon as you pr You can create filter buttons by pressing the btn:[{plus}] button, right-clicking in the filter button area, or opening the Filter Button section of the <<ChCustPreferencesSection,Preferences Dialog>>. The example shows a filter button with the label “Squirrels”. If you have lots of buttons you can arrange them into groups by using “//” as a label separator. -For example if you create buttons named “Not Squirrels // Rabbits” and “Not Squirrels // Capybaras” they will show up in the toolbar under a single button named “Not Squirrels”. +For example, if you create buttons named “Not Squirrels // Rabbits” and “Not Squirrels // Capybaras” they will show up in the toolbar under a single button named “Not Squirrels”. |=== @@ -909,7 +909,7 @@ you select a line in this pane, more details will be displayed in the “Packet Details” and “Packet Bytes” panes. While dissecting a packet, Wireshark will place information from the protocol -dissectors into the columns. As higher level protocols might overwrite +dissectors into the columns. As higher-level protocols might overwrite information from lower levels, you will typically see the information from the highest possible level only. @@ -918,8 +918,8 @@ packet. The Ethernet dissector will write its data (such as the Ethernet addresses), the IP dissector will overwrite this by its own (such as the IP addresses), the TCP dissector will overwrite the IP information, and so on. -There are a lot of different columns available. Which columns are displayed can -be selected by preference settings. See <<ChCustPreferencesSection>>. +There are many different columns available. You can choose which columns are +displayed in the preferences. See <<ChCustPreferencesSection>>. The default columns will show: @@ -978,7 +978,7 @@ image:wsug_graphics/related-dup-ack.png[{related-attrs}]:: The selected packet is a duplicate acknowledgement of this packet. image:wsug_graphics/related-segment.png[{related-attrs}]:: - The selected packet is related to this packet in some other way, e.g. as part + The selected packet is related to this packet in some other way, e.g., as part of reassembly. The packet list has an _Intelligent Scrollbar_ which shows a miniature map of @@ -1099,7 +1099,7 @@ to change the size. .The initial Statusbar image::wsug_graphics/ws-statusbar-empty.png[{statusbar-attrs}] -This statusbar is shown while no capture file is loaded, e.g. when Wireshark is started. +This statusbar is shown while no capture file is loaded, e.g., when Wireshark is started. [#ChUseWiresharkStatusbarLoaded] .The Statusbar with a loaded capture file diff --git a/docbook/wsug_src/WSUG_chapter_work.adoc b/docbook/wsug_src/WSUG_chapter_work.adoc index 0295be7e73..76da78eb93 100644 --- a/docbook/wsug_src/WSUG_chapter_work.adoc +++ b/docbook/wsug_src/WSUG_chapter_work.adoc @@ -131,7 +131,7 @@ of some or all packets. |menu:Packet Comment...[] |menu:Edit[] | Opens the “Packet Comment” dialog, which lets you add a comment to a single packet. Note that the ability to save packet comments depends on -your file format. E.g. pcapng supports comments, pcap does not. +your file format. E.g., pcapng supports comments, pcap does not. |menu:Edit Resolved Name[]|| Allows you to enter a name to resolve for the selected address. @@ -597,7 +597,7 @@ numerical digits respectively: + `dns.qry.name contains "www.\x77\x69\x72\x65\x73\x68\x61\x72\x6b.org"` + -Alternatively a raw string syntax can be used. Such strings are prefixed with `r` or `R` and treat +Alternatively, a raw string syntax can be used. Such strings are prefixed with `r` or `R` and treat backslash as a literal character. + `http.user_agent matches r"\(X11;"` @@ -647,7 +647,7 @@ Comparisons are case-insensitive. tcp.flags & 0x02 ---- That display filter will match all packets that contain the “tcp.flags” field with the 0x02 bit, -i.e. the SYN bit, set. +i.e., the SYN bit, set. ==== Possible Pitfalls Using Regular Expressions @@ -655,8 +655,8 @@ String literals containing regular expressions are parsed twice. Once by Wiresha filter engine and again by the PCRE2 library. It's important to keep this in mind when using the "matches" operator with regex escape sequences and special characters. -For example the filter expression `+frame matches "AB\x43"+` uses the string `+"ABC"+` as input -pattern to PCRE. However the expression `+frame matches "AB\\x43"+` uses the string `+"AB\x43"+` +For example, the filter expression `+frame matches "AB\x43"+` uses the string `+"ABC"+` as input +pattern to PCRE. However, the expression `+frame matches "AB\\x43"+` uses the string `+"AB\x43"+` as the pattern. In this case both expressions give the same result because Wireshark and PCRE both support the same byte escape sequence (0x43 is the ASCII hex code for `C`). @@ -821,7 +821,7 @@ make the transition easier. For example, the DHCP dissector was originally developed for the BOOTP protocol but as of Wireshark 3.0 all of the “bootp” display filter fields have been renamed to their “dhcp” equivalents. You can still use -the old filter names for the time being, e.g. “bootp.type” is equivalent +the old filter names for the time being, e.g., “bootp.type” is equivalent to “dhcp.type” but Wireshark will show the warning “"bootp" is deprecated” when you use it. Support for the deprecated fields may be removed in the future. @@ -831,7 +831,7 @@ when you use it. Support for the deprecated fields may be removed in the future. When you are accustomed to Wireshark’s filtering system and know what labels you wish to use in your filters it can be very quick to simply type a filter string. -However if you are new to Wireshark or are working with a slightly unfamiliar +However, if you are new to Wireshark or are working with a slightly unfamiliar protocol it can be very confusing to try to figure out what to type. The “Display Filter Expression” dialog box helps with this. @@ -986,7 +986,7 @@ You can search using the following criteria: Display filter:: Enter a display filter string into the text entry field and click the btn:[Find] button. + - For example, to find the three way handshake for a connection from host 192.168.0.1, use the following filter string: + For example, to find the three-way handshake for a connection from host 192.168.0.1, use the following filter string: + ---- ip.src==192.168.0.1 and tcp.flags.syn==1 @@ -1094,7 +1094,7 @@ with the middle mouse button. You can ignore packets in the “Packet List” pane. Wireshark will then pretend that they not exist in the capture file. An ignored packet will -be shown with white background and gray foreground, regardless of the +be shown with white background and grey foreground, regardless of the coloring rules set. Ignored packet information is not stored in the capture file or anywhere @@ -1167,7 +1167,7 @@ you use Seconds it would show simply 1 and if you use Nanoseconds it shows The user can set time references to packets. A time reference is the starting point for all subsequent packet time calculations. It will be useful, if you -want to see the time values relative to a special packet, e.g. the start of a +want to see the time values relative to a special packet, e.g., the start of a new request. It’s possible to set multiple time references in the capture file. The time references will not be saved permanently and will be lost when you diff --git a/docbook/wsug_src/editcap-h.txt b/docbook/wsug_src/editcap-h.txt index 3d9e22f6fb..ab4472286e 100644 --- a/docbook/wsug_src/editcap-h.txt +++ b/docbook/wsug_src/editcap-h.txt @@ -27,7 +27,7 @@ Duplicate packet removal: -w <dup time window> remove packet if duplicate packet is found EQUAL TO OR LESS THAN <dup time window> prior to current packet. A <dup time window> is specified in relative seconds - (e.g. 0.000001). + (e.g., 0.000001). NOTE: The use of the 'Duplicate packet removal' options with other editcap options except -v may not always work as expected. Specifically the -r, -t or -S options will very likely NOT have the @@ -47,10 +47,10 @@ Packet manipulation: this option more than once, allowing up to 2 chopping regions within a packet provided that at least 1 choplen is positive and at least 1 is negative. - -L adjust the frame (i.e. reported) length when chopping + -L adjust the frame (i.e., reported) length when chopping and/or snapping. -t <time adjustment> adjust the timestamp of each packet. - <time adjustment> is in relative seconds (e.g. -0.5). + <time adjustment> is in relative seconds (e.g., -0.5). -S <strict adjustment> adjust timestamp of packets if necessary to ensure strict chronological increasing order. The <strict adjustment> is specified in relative seconds with @@ -73,7 +73,7 @@ Packet manipulation: Useful to remove duplicated packets taken on several routers (different mac addresses for example). - e.g. -I 26 in case of Ether/IP will ignore + e.g., -I 26 in case of Ether/IP will ignore ether(14) and IP header(20 - 4(src ip) - 4(dst ip)). -a <framenum>:<comment> Add or replace comment for given frame number diff --git a/docbook/wsug_src/text2pcap-h.txt b/docbook/wsug_src/text2pcap-h.txt index 1be5c7fd92..b5b6fece7b 100644 --- a/docbook/wsug_src/text2pcap-h.txt +++ b/docbook/wsug_src/text2pcap-h.txt @@ -21,7 +21,7 @@ Input: -D the text before the packet starts with an I or an O, indicating that the packet is inbound or outbound. This is used when generating dummy headers if the - output format supports it (e.g. pcapng). + output format supports it (e.g., pcapng). -a enable ASCII text dump identification. The start of the ASCII text dump can be identified and excluded from the packet data, even if it looks diff --git a/docbook/wsug_src/tshark-h.txt b/docbook/wsug_src/tshark-h.txt index df72efdd9e..a1d0f4d897 100644 --- a/docbook/wsug_src/tshark-h.txt +++ b/docbook/wsug_src/tshark-h.txt @@ -91,11 +91,11 @@ Output: -T pdml|ps|psml|json|jsonraw|ek|tabs|text|fields|? format of text output (def: text) -j <protocolfilter> protocols layers filter if -T ek|pdml|json selected - (e.g. "ip ip.flags text", filter does not expand child + (e.g., "ip ip.flags text", filter does not expand child nodes, unless child is specified also in the filter) -J <protocolfilter> top level protocol filter if -T ek|pdml|json selected - (e.g. "http tcp", filter which expands all child nodes) - -e <field> field to print if -Tfields selected (e.g. tcp.port, + (e.g., "http tcp", filter which expands all child nodes) + -e <field> field to print if -Tfields selected (e.g., tcp.port, _ws.col.Info) this option can be repeated to print multiple fields -E<fieldsoption>=<value> set options for output when -Tfields selected: @@ -110,7 +110,7 @@ Output: output format of time stamps (def: r: rel. to first) -u s|hms output format of seconds (def: s: seconds) -l flush standard output after each packet - -q be more quiet on stdout (e.g. when using statistics) + -q be more quiet on stdout (e.g., when using statistics) -Q only log true errors to stderr (quieter than -q) -g enable group read access on the output file(s) -W n Save extra information in the file, if supported. |