Как запустить wireshark на windows

1. Foreword

2. Who should read this document?

3. Acknowledgements

• Gerald Combs, for initiating the Wireshark project and funding to do this
  documentation.
• Guy Harris, for many helpful hints and a great deal of patience in reviewing
  this document.
• Gilbert Ramirez, for general encouragement and helpful hints along the way.

• Pat Eyler, for his suggestions on improving the example on generating a backtrace.
• Martin Regner, for his various suggestions and corrections.
• Graeme Hewson, for many grammatical corrections.

• Scott Renfro from whose mergecap man page Section D.8, “mergecap: Merging multiple capture files into one” is derived.
• Ashok Narayanan from whose text2pcap man page Section D.9, “text2pcap: Converting ASCII hexdumps to network captures” is derived.

4. About this document

6. Providing feedback about this document

7. Typographic Conventions

Table 1. Typographic Conventions

Important and notable items are marked as follows:

	This is a warning
You should pay attention to a warning, otherwise data loss might occur.

	This is a caution
Act carefully (i.e., exercise care).

	This is important information
RTFM — Read The Fine Manual

	This is a tip
Tips are helpful for your everyday work using Wireshark.

	This is a note
A note will point you to common mistakes and things that might not be obvious.

Bourne shell, normal user. 

$ # This is a comment
$ git config --global log.abbrevcommit true

Bourne shell, root user. 

# # This is a comment
# ninja install

Command Prompt (cmd.exe). 

>rem This is a comment
>cd C:\Development

PowerShell. 

PS$># This is a comment
PS$> choco list -l

C Source Code. 

#include "config.h"

/* This method dissects foos */
static int
dissect_foo_message(tvbuff_t *tvb, packet_info *pinfo _U_, proto_tree *tree _U_, void *data _U_)
{
    /* TODO: implement your dissecting code */
    return tvb_captured_length(tvb);
}

1.1. What is Wireshark?

Here are some reasons people use Wireshark:

Wireshark can also be helpful in many other situations.

The following are some of the many features Wireshark provides:

However, to really appreciate its power you have to start using it.

Figure 1.1, “Wireshark captures packets and lets you examine their contents.” shows Wireshark having captured some packets and waiting for you
to examine them.

Wireshark can capture traffic from many different network media types,
including Ethernet, Wireless LAN, Bluetooth, USB, and more. The specific media
types supported may be limited by several factors, including your hardware
and operating system. An overview of the supported media types can be found at
https://gitlab.com/wireshark/wireshark/-/wikis/CaptureSetup/NetworkMedia.

Wireshark can open packet captures from a large number of capture
programs. For a list of input formats see Section 5.2.2, “Input File Formats”.

Wireshark can save captured packets in many formats, including those used by other
capture programs. For a list of output formats see Section 5.3.2, “Output File Formats”.

There are protocol dissectors (or decoders, as they are known in other products)
for a great many protocols: see Appendix C, Protocols and Protocol Fields.

Wireshark is an open source software project, and is released under the
GNU General Public License (GPL). You can freely use
Wireshark on any number of computers you like, without worrying about license
keys or fees or such. In addition, all source code is freely available under the
GPL. Because of that, it is very easy for people to add new protocols to
Wireshark, either as plugins, or built into the source, and they often do!

Here are some things Wireshark does not provide:

1.2. System Requirements

Wireshark should support any version of Windows that is still within its
extended support
lifetime. At the time of writing this includes Windows 10, 8.1,
Server 2019,
Server 2016,
Server 2012 R2,
and Server 2012.
It also requires the following:

Older versions of Windows which are outside Microsoft’s extended lifecycle
support window are no longer supported. It is often difficult or impossible to
support these systems due to circumstances beyond our control, such as third
party libraries on which we depend or due to necessary features that are only
present in newer versions of Windows such as hardened security or memory
management.

See the Wireshark
release lifecycle page for more details.

Wireshark supports macOS 10.14 and later.
Similar to Windows, supported macOS versions depend on third party libraries and on Apple’s requirements.
Apple Silicon hardware is supported natively starting with version 4.0

The system requirements should be comparable to the specifications listed above for Windows.

Wireshark runs on most UNIX and UNIX-like platforms including Linux and most BSD variants.
The system requirements should be comparable to the specifications listed above for Windows.

Binary packages are available for most Unices and Linux distributions
including the following platforms:

If a binary package is not available for your platform you can download
the source and try to build it. Please report your experiences to
wireshark-dev[AT]wireshark.org.

1.3. Where To Get Wireshark

1.4. A Brief History Of Wireshark

1.5. Development And Maintenance Of Wireshark

1. Other people who find your contributions useful will appreciate them, and you
   will know that you have helped people in the same way that the developers of
   Wireshark have helped you.
2. The developers of Wireshark can further improve your changes or implement
   additional features on top of your code, which may also benefit you.
3. The maintainers and developers of Wireshark will maintain your code,
   fixing it when API changes or other changes are made, and generally keeping it
   in tune with what is happening with Wireshark. So when Wireshark is updated
   (which is often), you can get a new Wireshark version from the website
   and your changes will already be included without any additional effort from you.

1.6. Reporting Problems And Getting Help

The Wireshark Wiki at https://gitlab.com/wireshark/wireshark/-/wikis/ provides a
wide range of information related to Wireshark and packet capture in general.
You will find a lot of information not part of this user’s guide. For example,
it contains an explanation how to capture on a switched network, an ongoing effort
to build a protocol reference, protocol-specific information, and much more.

And best of all, if you would like to contribute your knowledge on a specific
topic (maybe a network protocol you know well), you can edit the wiki pages
with your web browser.

The Wireshark Q&A site at https://ask.wireshark.org/ offers a resource where
questions and answers come together. You can search for
questions asked before and see what answers were given by people who
knew about the issue. Answers are ranked, so you can easily pick out the best
ones. If your question hasn’t been discussed before you can post
one yourself.

The Frequently Asked Questions lists often asked questions and their
corresponding answers.

	Read the FAQ
Before sending any mail to the mailing lists below, be sure to read the FAQ. It will often answer any questions you might have. This will save yourself and others a lot of time. Keep in mind that a lot of people are subscribed to the mailing lists.

You will find the FAQ inside Wireshark by clicking the menu item Help/Contents
and selecting the FAQ page in the dialog shown.

An online version is available at the Wireshark website at
https://www.wireshark.org/faq.html. You might prefer this online version, as it’s
typically more up to date and the HTML format is easier to use.

There are several mailing lists of specific Wireshark topics available:

You can subscribe to each of these lists from the Wireshark web site:
https://www.wireshark.org/lists/. From there, you can choose which mailing
list you want to subscribe to by clicking on the
Subscribe/Unsubscribe/Options button under the title of the relevant
list. The links to the archives are included on that page as well.

	The lists are archived
You can search in the list archives to see if someone asked the same question some time before and maybe already got an answer. That way you don’t have to wait until someone answers your question.

	Note
Before reporting any problems, please make sure you have installed the latest version of Wireshark.

When reporting problems with Wireshark please supply the following information:

	Don’t send confidential information!
If you send capture files to the mailing lists be sure they don’t contain any sensitive or confidential information like passwords or personally identifiable information (PII). In many cases you can use a tool like TraceWrangler to sanitize a capture file before sharing it.

	Don’t send large files
Do not send large files (> 1 MB) to the mailing lists. Instead, provide a download link. For bugs and feature requests, you can create an issue on GitLab Issues and upload the file there.

When reporting crashes with Wireshark it is helpful if you supply the traceback
information along with the information mentioned in “Reporting Problems”.

You can obtain this traceback information with the following commands on UNIX or
Linux (note the backticks):

$ gdb `whereis wireshark | cut -f2 -d: | cut -d' ' -f2` core >& backtrace.txt
backtrace
^D

If you do not have gdb available, you will have to check out your operating system’s debugger.

Email backtrace.txt to wireshark-dev[AT]wireshark.org.

2.1. Introduction

1. Download the relevant package for your needs, e.g., source or binary
   distribution.
2. For source distributions, compile the source into a binary.
   This may involve building and/or installing other necessary packages.
3. Install the binaries into their final destinations.

2.2. Obtaining the source and binary distributions

2.3. Installing Wireshark under Windows

On the Choose Components page of the installer you can select from the following:

By default Wireshark installs into %ProgramFiles%\Wireshark on 32-bit Windows
and %ProgramFiles64%\Wireshark on 64-bit Windows. This expands to C:\Program
Files\Wireshark on most systems.

The Wireshark installer contains the latest Npcap installer.

If you don’t have Npcap installed you won’t be able to capture live network
traffic but you will still be able to open saved capture files. By default the
latest version of Npcap will be installed. If you don’t wish to do this or if
you wish to reinstall Npcap you can check the Install Npcap box as needed.

For more information about Npcap see https://npcap.com/ and
https://gitlab.com/wireshark/wireshark/-/wikis/Npcap.

For special cases, there are some command line parameters available:

Example:

> Wireshark-4.2.5-x64.exe /NCRC /S /desktopicon=yes /quicklaunchicon=no /D=C:\Program Files\Foo

> Wireshark-4.2.5-x64.exe /S /EXTRACOMPONENTS=sshdump,udpdump

Running the installer without any parameters shows the normal interactive installer.

As mentioned above, the Wireshark installer also installs Npcap.
If you prefer to install Npcap manually or want to use a different version than the
one included in the Wireshark installer, you can download Npcap from
the main Npcap site at https://npcap.com/.

Wireshark updates may also include a new version of Npcap.
Manual Npcap updates instructions can be found on the Npcap web
site at https://npcap.com/. You may have to reboot your machine after installing
a new Npcap version.

You can uninstall Wireshark using the Programs and Features control panel.
Select the “Wireshark” entry to start the uninstallation procedure.

The Wireshark uninstaller provides several options for removal. The default is
to remove the core components but keep your personal settings and Npcap.
Npcap is kept in case other programs need it.

You can uninstall Npcap independently of Wireshark using the Npcap entry
in the Programs and Features control panel. Remember that if you uninstall
Npcap you won’t be able to capture anything with Wireshark.

2.5. Installing Wireshark under macOS

2.6. Installing the binaries under UNIX

Building RPMs from Wireshark’s source code results in several packages (most
distributions follow the same system):

Many distributions use yum or a similar package management tool to make
installation of software (including its dependencies) easier. If your
distribution uses yum, use the following command to install Wireshark
together with the Qt GUI:

yum install wireshark wireshark-qt

If you’ve built your own RPMs from the Wireshark sources you can install them
by running, for example:

rpm -ivh wireshark-2.0.0-1.x86_64.rpm wireshark-qt-2.0.0-1.x86_64.rpm

If the above command fails because of missing dependencies, install the
dependencies first, and then retry the step above.

If you can just install from the repository then use

apt install wireshark

Apt should take care of all of the dependency issues for you.

Use the following command to install Wireshark under Gentoo Linux with all of
the extra features:

USE="c-ares ipv6 snmp ssl kerberos threads selinux" emerge wireshark

Use the following command to install Wireshark under FreeBSD:

pkg_add -r wireshark

pkg_add should take care of all of the dependency issues for you.

2.8. Updating Wireshark

3.1. Introduction

• How the Wireshark user interface works
• How to capture packets in Wireshark
• How to view packets in Wireshark
• How to filter packets in Wireshark
• …​ and many other things!

3.2. Start Wireshark

3.3. The Main window

Figure 3.1. The Main window

1. The menu (see Section 3.4, “The Menu”) is used to start actions.
2. The main toolbar (see Section 3.16, “The “Main” Toolbar”) provides quick access to
   frequently used items from the menu.
3. The filter toolbar (see Section 3.17, “The “Filter” Toolbar”) allows users to
   set display filters to filter which packets are displayed (see
   Section 6.3, “Filtering Packets While Viewing”).
4. The packet list pane (see Section 3.18, “The “Packet List” Pane”) displays a summary
   of each packet captured. By clicking on packets in this pane you control what is
   displayed in the other two panes.
5. The packet details pane (see Section 3.19, “The “Packet Details” Pane”) displays the
   packet selected in the packet list pane in more detail.
6. The packet bytes pane (see Section 3.20, “The “Packet Bytes” Pane”) displays the
   data from the packet selected in the packet list pane, and highlights the field
   selected in the packet details pane.
7. The packet diagram pane (see Section 3.21, “The “Packet Diagram” Pane”) displays the
   packet selected in the packet list as a textbook-style diagram.
8. The statusbar (see Section 3.22, “The Statusbar”) shows some detailed
   information about the current program state and the captured data.

Packet list and detail navigation can be done entirely from the keyboard.
Table 3.1, “Keyboard Navigation” shows a list of keystrokes that will let you quickly move around
a capture file. See Table 3.6, “Go menu items” for additional navigation keystrokes.

→ → will show a list of all shortcuts
in the main window. Additionally, typing anywhere in the main window will start
filling in a display filter.

3.4. The Menu

This menu contains items to open and merge capture files, save, print, or export
capture files in whole or in part, and to quit the Wireshark application. See
Section 3.5, “The “File” Menu”.

This menu contains items to find a packet, time reference or mark one or more
packets, handle configuration profiles, and set your preferences; (cut, copy,
and paste are not presently implemented). See Section 3.6, “The “Edit” Menu”.

This menu controls the display of the captured data, including colorization of
packets, zooming the font, showing a packet in a separate window, expanding and
collapsing trees in packet details, …​. See Section 3.7, “The “View” Menu”.

This menu contains items to go to a specific packet. See Section 3.8, “The “Go” Menu”.

This menu allows you to start and stop captures and to edit capture filters. See
Section 3.9, “The “Capture” Menu”.

This menu contains items to manipulate display filters, enable or disable the
dissection of protocols, configure user specified decodes and follow a TCP
stream. See Section 3.10, “The “Analyze” Menu”.

This menu contains items to display various statistic windows, including a
summary of the packets that have been captured, display protocol hierarchy
statistics and much more. See Section 3.11, “The “Statistics” Menu”.

This menu contains items to display various telephony related statistic windows,
including a media analysis, flow diagrams, display protocol hierarchy statistics
and much more. See Section 3.12, “The “Telephony” Menu”.

This menu contains items to display Bluetooth and IEEE 802.11 wireless statistics.

This menu contains various tools available in Wireshark, such as creating
Firewall ACL Rules. See Section 3.14, “The “Tools” Menu”.

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 Section 3.15, “The “Help” Menu”.

3.5. The “File” Menu

Figure 3.3. The “File” Menu

Table 3.2. File menu items

3.6. The “Edit” Menu

Figure 3.4. The “Edit” Menu

Table 3.3. Edit menu items

3.7. The “View” Menu

Figure 3.5. The “View” Menu

Table 3.4. View menu items

Table 3.5. Internals menu items

3.8. The “Go” Menu

Figure 3.6. The “Go” Menu

Table 3.6. Go menu items

3.9. The “Capture” Menu

Figure 3.7. The “Capture” Menu

Table 3.7. Capture menu items

3.10. The “Analyze” Menu

Figure 3.8. The “Analyze” Menu

Table 3.8. Analyze menu items

3.11. The “Statistics” Menu

Figure 3.9. The “Statistics” Menu

Table 3.9. Statistics menu items

3.12. The “Telephony” Menu

Figure 3.10. The “Telephony” Menu

Table 3.10. Telephony menu items

3.13. The “Wireless” Menu

Figure 3.11. The “Wireless” Menu

Table 3.11. Wireless menu items

3.14. The “Tools” Menu

Figure 3.12. The “Tools” Menu

Table 3.12. Tools menu items

3.15. The “Help” Menu

Figure 3.13. The “Help” Menu

Table 3.13. Help menu items

3.16. The “Main” Toolbar

Figure 3.14. The “Main” toolbar

Table 3.14. Main toolbar items

3.17. The “Filter” Toolbar

Figure 3.15. The “Filter” toolbar

Table 3.15. Filter toolbar items

3.18. The “Packet List” Pane

Figure 3.16. The “Packet List” pane

• No. The number of the packet in the capture file. This number won’t
  change, even if a display filter is used.
• Time The timestamp of the packet. The presentation format of this
  timestamp can be changed, see Section 6.12, “Time Display Formats And Time References”.
• Source The address where this packet is coming from.
• Destination The address where this packet is going to.
• Protocol The protocol name in a short (perhaps abbreviated) version.
• Length The length of each packet.
• Info Additional information about the packet content.

Table 3.16. Related packet symbols

3.19. The “Packet Details” Pane

Figure 3.17. The “Packet Details” pane

• Generated fields. Wireshark itself will generate additional protocol
  information which isn’t present in the captured data. This information
  is enclosed in square brackets (“[” and “]”). Generated information
  includes response times, TCP analysis, IP geolocation information, and
  checksum validation.
• Links. If Wireshark detects a relationship to another packet in the capture
  file it will generate a link to that packet. Links are underlined and
  displayed in blue. If you double-clicked on a link Wireshark will jump to the
  corresponding packet.

3.20. The “Packet Bytes” Pane

Figure 3.18. The “Packet Bytes” pane

• Temporary By holding down the Ctrl button while moving the mouse, the
  highlighted field will not change
• Permanently Using the context menu (right mouse click) the hover highlighting
  may be activated/deactivated. This setting is stored in the selected profile
  recent file.

Figure 3.19. The “Packet Bytes” pane with tabs

3.21. The “Packet Diagram” Pane

Figure 3.20. The “Packet Diagram” pane

3.22. The Statusbar

Figure 3.21. The initial Statusbar

Figure 3.22. The Statusbar with a loaded capture file

The colorized bullet…​

on the left shows the highest expert information level found in the currently loaded capture file.
Hovering the mouse over this icon will show a description of the expert info level, and clicking the icon will bring up the Expert Information dialog box.
For a detailed description of this dialog and each expert level, see Section 7.4, “Expert Information”.

The edit icon…​

on the left side lets you add a comment to the capture file using the Capture File Properties dialog.

The left side…​

shows the capture file name by default.
It also shows field information when hovering over and selecting items in the packet detail and packet bytes panes, as well as general notifications.

The middle…​

shows the current number of packets in the capture file.
The following values are displayed:

Packets

The number of captured packets.

Displayed

The number of packets currently being displayed.

Marked

The number of marked packets. Only displayed if you marked any packets.

Dropped

The number of dropped packets Only displayed if Wireshark was unable to capture all packets.

Ignored

The number of ignored packets Only displayed if you ignored any packets.

The right side…​

shows the selected configuration profile.
Clicking on this part of the statusbar will bring up a menu with all available configuration profiles, and selecting from this list will change the configuration profile.

Figure 3.23. The Statusbar with a configuration profile menu

Figure 3.24. The Statusbar with a selected protocol field

Figure 3.25. The Statusbar with a display filter message

4.1. Introduction

• Capture from different kinds of network hardware such as Ethernet or 802.11.
• Simultaneously capture from multiple network interfaces.
• Stop the capture on different triggers such as the amount of captured data,
  elapsed time, or the number of packets.
• Simultaneously show decoded packets while Wireshark is capturing.
• Filter packets, reducing the amount of data to be captured. See
  Section 4.10, “Filtering while capturing”.
• Save packets in multiple files while doing a long-term capture, optionally
  rotating through a fixed number of files (a “ringbuffer”). See
  Section 4.8, “Capture files and file modes”.

• Stop capturing (or perform some other action) depending on the captured data.

4.2. Prerequisites

• You may need special privileges to start a live capture.
• You need to choose the right network interface to capture packet data from.
• You need to capture at the right place in the network to see the traffic you
  want to see.

4.3. Start Capturing

• You can double-click on an interface in the welcome screen.
• You can select an interface in the welcome screen, then select → or click the first toolbar button.
• You can get more detailed information about available interfaces using Section 4.5, “The “Capture Options” Dialog Box” ( → ).
• If you already know the name of the capture interface you can start Wireshark from the command line:

4.4. The “Capture” Section Of The Welcome Screen

Figure 4.1. Capture interfaces on Microsoft Windows

Figure 4.2. Capture interfaces on macOS

4.5. The “Capture Options” Dialog Box

Figure 4.3. The “Capture Options” input tab

Interface

The interface name.

Some interfaces allow or require configuration prior to capture.
This will be indicated by a configuration icon
()
to the left of the interface name.
Clicking on the icon will show the configuration dialog for that interface.

Traffic

A sparkline showing network activity over time.

Link-layer Header

The type of packet captured by this interface.
In some cases it is possible to change this.
See Section 4.9, “Link-layer header type” for more details.

Promiscuous

Lets you put this interface in promiscuous mode while capturing.
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.

Buffer

The size of the kernel buffer that is reserved for capturing packets.
You can increase or decrease this as needed, but the default is usually sufficient.

Monitor Mode

Lets you capture full, raw 802.11 headers.
Support depends on the interface type, hardware, driver, and OS.
Note that enabling this might disconnect you from your wireless network.

Capture Filter

The capture filter applied to this interface.
You can edit the filter by double-clicking on it.
See Section 4.10, “Filtering while capturing” for more details about capture filters.

Figure 4.4. The “Capture Options” output tab

Capture to a permanent file

File

This field allows you to specify the file name that will be used for the capture file.
It is left blank by default.
If left blank, the capture data will be stored in a temporary file.
See Section 4.8, “Capture files and file modes” for details.
You can also click on the button to the right of this field to browse through the filesystem.

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.
See https://gitlab.com/wireshark/wireshark/-/wikis/Development/PcapNg for more details on pcapng.

Create a new file automatically…​

Sets the conditions for switching a new capture file.
A new capture file can be created based on the following conditions:

• The number of packets in the capture file.
• The size of the capture file.
• The duration of the capture file.
• The wall clock time.

Use a ring buffer with

Multiple files only.
Form a ring buffer of the capture files with the given number of files.

Figure 4.5. The “Capture Options” options tab

Display Options

Update list of packets in real-time

Updates the packet list pane in real time during capture.
If you do not enable this, Wireshark will not display any packets until you stop the capture.
When you check this, Wireshark captures in a separate process and feeds the captures to the display process.

Automatically scroll during live capture

Scroll the packet list pane as new packets come in, so you are always looking at the most recent packet.
Automatic scrolling is temporarily disabled when manually scrolling upwards or performing a «Go» action so that the selected packet can be examined.
It will resume upon manually scrolling to the end of the packet list.
If you do not specify this Wireshark adds new packets to the packet list but does not scroll the packet list pane.
This option has no effect if “Update list of packets in real-time” is disabled.

Show capture information during capture

If this option is enabled, the capture information dialog described in Section 4.11, “While a Capture is running …​” will be shown while packets are captured.

Name Resolution

Resolve MAC addresses

Translate MAC addresses into names.

Resolve network names

Translate network addresses into names.

Resolve transport names

Translate transport names (port numbers).

Stop capture automatically after…​

Capturing can be stopped based on the following conditions:

• The number of packets in the capture file.
• The number of capture files.
• The capture file size.
• The capture file duration.

4.6. The “Manage Interfaces” Dialog Box

Figure 4.6. The “Manage Interfaces” dialog box

Show

Whether or not to show or hide this interface in the welcome screen and the “Capture Options” dialog.

Friendly Name

A name for the interface that is human readable.

Interface Name

The device name of the interface.

Comment

Can be used to add a descriptive comment for the interface.

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.

Port

Set the port number where the Remote Packet Capture Protocol service is listening on.
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.

Password authentication

Lets you specify the username and password required to connect to the Remote Packet Capture Protocol service.

4.7. The “Compiled Filter Output” Dialog Box

Figure 4.7. The “Compiled Filter Output” dialog box

4.8. Capture files and file modes

Figure 4.8. Capture output options

Table 4.1. Capture file mode selected by capture options

Single temporary file

A temporary file will be created and used (this is the default).
After capturing is stopped this file can be saved later under a user specified name.

Single named file

A single capture file will be used.
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).

Multiple files, ring buffer

Much like “Multiple files continuous”, reaching one of the multiple files switch
conditions (one of the “Next file every …​” values) will switch to the next
file. This will be a newly created file if value of “Ring buffer with n files”
is not reached, otherwise it will replace the oldest of the formerly used files
(thus forming a “ring”).

This mode will limit the maximum disk usage, even for an unlimited amount of
capture input data, only keeping the latest captured data.

4.9. Link-layer header type

4.10. Filtering while capturing

Example 4.1. A capture filter for telnet that captures traffic to and from a particular host

tcp port 23 and host 10.0.0.5

Example 4.2. Capturing all telnet traffic not from 10.0.0.5

tcp port 23 and not src host 10.0.0.5

A primitive is simply one of the following: [src|dst] host <host>

This primitive allows you to filter on a host IP address or name. You can
optionally precede the primitive with the keyword src|dst to specify that you
are only interested in source or destination addresses. If these are not
present, packets where the specified address appears as either the source or the
destination address will be selected.

ether [src|dst] host <ehost>

This primitive allows you to filter on Ethernet host addresses. You can
optionally include the keyword src|dst between the keywords ether and host
to specify that you are only interested in source or destination addresses. If
these are not present, packets where the specified address appears in either the
source or destination address will be selected.

gateway host <host>

This primitive allows you to filter on packets that used host as a gateway.
That is, where the Ethernet source or destination was host but neither the
source nor destination IP address was host.

[src|dst] net <net> [{mask <mask>}|{len <len>}]

This primitive allows you to filter on network numbers. You can optionally
precede this primitive with the keyword src|dst to specify that you are only
interested in a source or destination network. If neither of these are present,
packets will be selected that have the specified network in either the source or
destination address. In addition, you can specify either the netmask or the CIDR
prefix for the network if they are different from your own.

[tcp|udp] [src|dst] port <port>

This primitive allows you to filter on TCP and UDP port numbers. You can
optionally precede this primitive with the keywords src|dst and tcp|udp
which allow you to specify that you are only interested in source or destination
ports and TCP or UDP packets respectively. The keywords tcp|udp must appear
before src|dst.

If these are not specified, packets will be selected for both the TCP and UDP
protocols and when the specified address appears in either the source or
destination port field.

less|greater <length>

This primitive allows you to filter on packets whose length was less than or
equal to the specified length, or greater than or equal to the specified length,
respectively.

ip|ether proto <protocol>

This primitive allows you to filter on the specified protocol at either the
Ethernet layer or the IP layer.

ether|ip broadcast|multicast

This primitive allows you to filter on either Ethernet or IP broadcasts or
multicasts.

<expr> relop <expr>

This primitive allows you to create complex filter expressions that select bytes or ranges of bytes in packets.
Please see the pcap-filter man page at https://www.tcpdump.org/manpages/pcap-filter.7.html for more details.

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.

To avoid this, Wireshark tries to figure out if it’s remotely connected (by
looking at some specific environment variables) and automatically creates a
capture filter that matches aspects of the connection.

The following environment variables are analyzed:

On Windows it asks the operating system if it’s running in a Remote Desktop Services environment.

4.11. While a Capture is running …​

Figure 4.9. The “Capture Information” dialog box

A running capture session will be stopped in one of the following ways:

A running capture session can be restarted with the same capture options as the
last time, this will remove all packets previously captured. This can be useful,
if some uninteresting packets are captured and there’s no need to keep them.

Restart is a convenience function and equivalent to a capture stop following by
an immediate capture start. A restart can be triggered in one of the following
ways:

5.1. Introduction

• Open capture files in various capture file formats
• Save and export capture files in various formats
• Merge capture files together
• Import text files containing hex dumps of packets
• Print packets

5.2. Open Capture Files

The “Open Capture File” dialog box allows you to search for a capture file
containing previously captured packets for display in Wireshark. The following
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 behavior on all systems:

Wireshark adds the following controls:

This is the common Windows file open dialog along with some Wireshark extensions.

This is the common Qt file open dialog along with some Wireshark extensions.

The native capture file formats used by Wireshark are:

The following file formats from other capture tools can be opened by Wireshark:

New file formats are added from time to time.

It may not be possible to read some formats dependent on the packet types
captured. Ethernet captures are usually supported for most file formats but it
may not be possible to read other packet types such as PPP or IEEE 802.11 from
all file formats.

5.3. Saving Captured Packets

The “Save Capture File As” dialog box allows you to save the current capture to a file.
The exact appearance of this dialog depends on your system.
However, the functionality is the same across systems.
Examples are shown below.

This is the common Windows file save dialog with some additional Wireshark extensions.

This is the common Qt file save dialog with additional Wireshark extensions.

You can perform the following actions:

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.

	Wireshark can convert file formats
You can convert capture files from one format to another by opening a capture and saving it as a different format.

If you wish to save some of the packets in your capture file you can do so via Section 5.7.1, “The “Export Specified Packets” Dialog Box”.

Wireshark can save the packet data in its native file format (pcapng) and in the
file formats of other protocol analyzers so other tools can read the capture
data.

	Saving in a different format might lose data
Saving your file in a different format might lose information such as comments, name resolution, and time stamp resolution. See Section 7.6, “Time Stamps” for more information on time stamps.

The following file formats can be saved by Wireshark (with the known file extensions):

New file formats are added from time to time.

Whether or not the above tools will be more helpful than Wireshark is a different question

	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 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.

5.4. Merging Capture Files

• Use the → menu to open the “Merge” dialog.
  See Section 5.4.1, “The “Merge With Capture File” Dialog Box” for details.
  This menu item will be disabled unless you have loaded a capture file.
• 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.
• Use the mergecap tool from the command line to merge capture files.
  This tool provides the most options to merge capture files.
  See Section D.8, “mergecap: Merging multiple capture files into one” for details.

This lets you select a file to be merged into the currently loaded file.
If your current data has not been saved you will be asked to save it first.

Most controls of this dialog will work the same way as described in the “Open Capture File” dialog box.
See Section 5.2.1, “The “Open Capture File” Dialog Box” for details.

Specific controls of this merge dialog are:

This is the common Windows file open dialog with additional Wireshark extensions.

This is the Qt file open dialog with additional Wireshark extensions.

5.5. Import Hex Dump

Wireshark understands a hexdump of the form generated by od -Ax -tx1 -v.
In other words, each byte is individually displayed, with spaces separating
the bytes from each other. Hex digits can be upper or lowercase.

In normal operation, each line must begin with an offset describing the
position in the packet, followed a colon, space, or tab separating it from
the bytes. There is no limit on the width or number of bytes per line, but
lines with only hex bytes without a leading offset are ignored (i.e.,
line breaks should not be inserted in long lines that wrap.) Offsets are more
than two digits; they are in hex by default, but can also be in octal or
decimal. Each packet must begin with offset zero, and an offset
zero indicates the beginning of a new packet. Offset values must be correct;
an unexpected value causes the current packet to be aborted and the next
packet start awaited. There is also a single packet mode with no offsets.

Packets may be preceded by a direction indicator (‘I’ or ‘O’) and/or a
timestamp if indicated. If both are present, the direction indicator precedes
the timestamp. The format of the timestamps must be specified. If no timestamp
is parsed, in the case of the first packet the current system time is used,
while subsequent packets are written with timestamps one microsecond later than
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
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;
the beginning of the preamble is scanned for the direction indicator and
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.

In general, short of these restrictions, Wireshark is pretty liberal
about reading in hexdumps and has been tested with a variety of
mangled outputs (including being forwarded through email multiple
times, with limited line wrap etc.)

Here is a sample dump that can be imported, including optional
directional indicator and timestamp:

I 2019-05-14T19:04:57Z
000000 00 e0 1e a7 05 6f 00 10 ........
000008 5a a0 b9 12 08 00 46 00 ........
000010 03 68 00 00 00 00 0a 2e ........
000018 ee 33 0f 19 08 7f 0f 19 ........
000020 03 80 94 04 00 00 10 01 ........
000028 16 a2 0a 00 03 50 00 0c ........
000030 01 01 0f 19 03 80 11 01 ........

Wireshark is also capable of scanning the input using a custom Perl regular
expression as specified by GLib’s 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
(the last character has to be \n and is ignored)
for non-overlapping (and non-empty) strings matching the given regex and then
identify the fields to import using named capturing subgroups. Using provided
format information for each field they are then decoded and translated into a
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:

> 0:00:00.265620 a130368b000000080060
> 0:00:00.280836 a1216c8b00000000000089086b0b82020407
< 0:00:00.295459 a2010800000000000000000800000000
> 0:00:00.296982 a1303c8b00000008007088286b0bc1ffcbf0f9ff
> 0:00:00.305644 a121718b0000000000008ba86a0b8008
< 0:00:00.319061 a2010900000000000000001000600000
> 0:00:00.330937 a130428b00000008007589186b0bb9ffd9f0fdfa3eb4295e99f3aaffd2f005
> 0:00:00.356037 a121788b0000000000008a18

could be imported using these settings:

regex: ^(?<dir>[<>])\s(?<time>\d+:\d\d:\d\d.\d+)\s(?<data>[0-9a-fA-F]+)$
timestamp: %H:%M:%S.%f
dir: in: <   out: >
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
this). It is generally recommended to sanity check any files created using
this conversion.

Supported fields:

This dialog box lets you select a text file, containing a hex dump of packet
data, to be imported and set import parameters.

Specific controls of this import dialog are split in three sections:

This section is split in the two alternatives for input conversion, accessible in
the two Tabs «Hex Dump» and «Regular Expression»

In addition to the conversion mode specific inputs, there are also common
parameters, currently only the timestamp format.

Once all input and import parameters are setup click Import to start the
import. If your current data wasn’t saved before you will be asked to save it
first.

If the import button doesn’t unlock, make sure all encapsulation parameters are
in the expected range and all unlocked fields are populated when using regex mode
(the placeholder text is not used as default).

When completed there will be a new capture file loaded with the frames imported
from the text file.

5.6. File Sets

• The “List Files” dialog box will list the files Wireshark has recognized as
  being part of the current file set.
• Next File closes the current and opens the next file in the file
  set.
• Previous File closes the current and opens the previous file in the
  file set.

Each line contains information about a file of the file set:

The last line will contain info about the currently used directory where all of
the files in the file set can be found.

The content of this dialog box is updated each time a capture file is
opened/closed.

The Close button will, well, close the dialog box.

5.7. Exporting Data

This is similar to the “Save” dialog box, but it lets you save specific packets.
This can be useful for trimming irrelevant or unwanted packets from a capture file.
See Packet Range for details on the range controls.

This lets you save the packet list, packet details, and packet bytes as plain text, CSV, JSON, and other formats.

The format can be selected from the “Export As” drop-down and further customized using the “Packet Range” and “Packet Format” controls.
Some controls are unavailable for some formats, notably CSV and JSON.
The following formats are supported:

Here are some examples of exported data:

Plain text. 

No.     Time           Source                Destination           Protocol Length SSID       Info
      1 0.000000       200.121.1.131         172.16.0.122          TCP      1454              10554 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=1400 [TCP segment of a reassembled PDU]

Frame 1: 1454 bytes on wire (11632 bits), 1454 bytes captured (11632 bits)
Ethernet II, Src: 00:50:56:c0:00:01, Dst: 00:0c:29:42:12:13
Internet Protocol Version 4, Src: 200.121.1.131 (200.121.1.131), Dst: 172.16.0.122 (172.16.0.122)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 1440
    Identification: 0x0141 (321)
    Flags: 0x0000
    ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 106
    Protocol: TCP (6)
    Header checksum: 0xd390 [validation disabled]
    [Header checksum status: Unverified]
    Source: 200.121.1.131 (200.121.1.131)
    Destination: 172.16.0.122 (172.16.0.122)
    [Source GeoIP: PE, ASN 6147, Telefonica del Peru S.A.A.]
Transmission Control Protocol, Src Port: 10554, Dst Port: 80, Seq: 1, Ack: 1, Len: 1400

Tip

If you would like to be able to import any previously exported packets from a plain text file it is recommended that you do the following: Add the “Absolute date and time” column. Temporarily hide all other columns. Disable the → → → “Show not dissected data on new Packet Bytes pane” preference. More details are provided in Section 11.5, “Preferences” Include the packet summary line. Exclude column headings. Exclude packet details. Include the packet bytes.

CSV. 

"No.","Time","Source","Destination","Protocol","Length","SSID","Info","Win Size"
"1","0.000000","200.121.1.131","172.16.0.122","TCP","1454","","10554  >  80 [ACK] Seq=1 Ack=1 Win=65535 Len=1400 [TCP segment of a reassembled PDU]","65535"
"2","0.000011","172.16.0.122","200.121.1.131","TCP","54","","[TCP ACKed unseen segment] 80  >  10554 [ACK] Seq=1 Ack=11201 Win=53200 Len=0","53200"
"3","0.025738","200.121.1.131","172.16.0.122","TCP","1454","","[TCP Spurious Retransmission] 10554  >  80 [ACK] Seq=1401 Ack=1 Win=65535 Len=1400 [TCP segment of a reassembled PDU]","65535"
"4","0.025749","172.16.0.122","200.121.1.131","TCP","54","","[TCP Window Update] [TCP ACKed unseen segment] 80  >  10554 [ACK] Seq=1 Ack=11201 Win=63000 Len=0","63000"
"5","0.076967","200.121.1.131","172.16.0.122","TCP","1454","","[TCP Previous segment not captured] [TCP Spurious Retransmission] 10554  >  80 [ACK] Seq=4201 Ack=1 Win=65535 Len=1400 [TCP segment of a reassembled PDU]","65535"

JSON. 

{
    "_index": "packets-2014-06-22",
    "_type": "doc",
    "_score": null,
    "_source": {
      "layers": {
        "frame": {
          "frame.encap_type": "1",
          "frame.time": "Jun 22, 2014 13:29:41.834477000 PDT",
          "frame.offset_shift": "0.000000000",
          "frame.time_epoch": "1403468981.834477000",
          "frame.time_delta": "0.450535000",
          "frame.time_delta_displayed": "0.450535000",
          "frame.time_relative": "0.450535000",
          "frame.number": "2",
          "frame.len": "86",
          "frame.cap_len": "86",
          "frame.marked": "0",
          "frame.ignored": "0",
          "frame.protocols": "eth:ethertype:ipv6:icmpv6",
          "frame.coloring_rule.name": "ICMP",
          "frame.coloring_rule.string": "icmp || icmpv6"
        },
        "eth": {
          "eth.dst": "33:33:ff:9e:e3:8e",
          "eth.dst_tree": {
            "eth.dst_resolved": "33:33:ff:9e:e3:8e",
            "eth.dst.oui": "3355647",
            "eth.addr": "33:33:ff:9e:e3:8e",
            "eth.addr_resolved": "33:33:ff:9e:e3:8e",
            "eth.addr.oui": "3355647",
            "eth.dst.lg": "1",
            "eth.lg": "1",
            "eth.dst.ig": "1",
            "eth.ig": "1"
          },
          "eth.src": "00:01:5c:62:8c:46",
          "eth.src_tree": {
            "eth.src_resolved": "00:01:5c:62:8c:46",
            "eth.src.oui": "348",
            "eth.src.oui_resolved": "Cadant Inc.",
            "eth.addr": "00:01:5c:62:8c:46",
            "eth.addr_resolved": "00:01:5c:62:8c:46",
            "eth.addr.oui": "348",
            "eth.addr.oui_resolved": "Cadant Inc.",
            "eth.src.lg": "0",
            "eth.lg": "0",
            "eth.src.ig": "0",
            "eth.ig": "0"
          },
          "eth.type": "0x000086dd"
        },
        "ipv6": {
          "ipv6.version": "6",
          "ip.version": "6",
          "ipv6.tclass": "0x00000000",
          "ipv6.tclass_tree": {
            "ipv6.tclass.dscp": "0",
            "ipv6.tclass.ecn": "0"
          },
          "ipv6.flow": "0x00000000",
          "ipv6.plen": "32",
          "ipv6.nxt": "58",
          "ipv6.hlim": "255",
          "ipv6.src": "2001:558:4080:16::1",
          "ipv6.addr": "2001:558:4080:16::1",
          "ipv6.src_host": "2001:558:4080:16::1",
          "ipv6.host": "2001:558:4080:16::1",
          "ipv6.dst": "ff02::1:ff9e:e38e",
          "ipv6.addr": "ff02::1:ff9e:e38e",
          "ipv6.dst_host": "ff02::1:ff9e:e38e",
          "ipv6.host": "ff02::1:ff9e:e38e",
          "ipv6.geoip.src_summary": "US, ASN 7922, Comcast Cable Communications, LLC",
          "ipv6.geoip.src_summary_tree": {
            "ipv6.geoip.src_country": "United States",
            "ipv6.geoip.country": "United States",
            "ipv6.geoip.src_country_iso": "US",
            "ipv6.geoip.country_iso": "US",
            "ipv6.geoip.src_asnum": "7922",
            "ipv6.geoip.asnum": "7922",
            "ipv6.geoip.src_org": "Comcast Cable Communications, LLC",
            "ipv6.geoip.org": "Comcast Cable Communications, LLC",
            "ipv6.geoip.src_lat": "37.751",
            "ipv6.geoip.lat": "37.751",
            "ipv6.geoip.src_lon": "-97.822",
            "ipv6.geoip.lon": "-97.822"
          }
        },
        "icmpv6": {
          "icmpv6.type": "135",
          "icmpv6.code": "0",
          "icmpv6.checksum": "0x00005b84",
          "icmpv6.checksum.status": "1",
          "icmpv6.reserved": "00:00:00:00",
          "icmpv6.nd.ns.target_address": "2001:558:4080:16:be36:e4ff:fe9e:e38e",
          "icmpv6.opt": {
            "icmpv6.opt.type": "1",
            "icmpv6.opt.length": "1",
            "icmpv6.opt.linkaddr": "00:01:5c:62:8c:46",
            "icmpv6.opt.src_linkaddr": "00:01:5c:62:8c:46"
          }
        }
      }
    }
  }
]

Export the bytes selected in the “Packet Bytes” pane into a raw binary file.

The “Export PDUs to File…​” dialog box allows you to filter the captured Protocol Data Units (PDUs) and export them into the file. It allows you to export reassembled PDUs avoiding lower layers such as HTTP without TCP, and decrypted PDUs without the lower protocols such as HTTP without TLS and TCP.

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 Section 5.7.4, “The “Export PDUs to File…​” Dialog Box”:

Transport Layer Security (TLS) encrypts the communication between a client and a server. The most common use for it is web browsing via HTTPS.

Decryption of TLS traffic requires TLS secrets. You can get them in the form of stored session keys in a «key log file», or by using an RSA private key file. For more details, see the TLS wiki page.

The → menu option generates a new «key log file» which contains TLS session secrets known by Wireshark. This feature is useful if you typically decrypt TLS sessions using the RSA private key file. The RSA private key is very sensitive because it can be used to decrypt other TLS sessions and impersonate the server. Session keys can be used only to decrypt sessions from the packet capture file. However, session keys are the preferred mechanism for sharing data over the Internet.

To export captured TLS session keys, follow the steps below:

This feature scans through the selected protocol’s streams in the currently
open capture file or running capture and allows the user to export reassembled
objects to the disk. For example, if you select HTTP, you can export HTML
documents, images, executables, and any other files transferred over HTTP
to the disk. If you have a capture running, this list is automatically
updated every few seconds with any new objects seen. The saved objects can then
be opened or examined independently of Wireshark.

Columns:

Filename:
The filename for this object. Each protocol generates
the filename differently. For example, HTTP uses the
final part of the URI and IMF uses the subject of the email.

Inputs:

5.8. Printing Packets

The “Print” dialog box shows a preview area which shows the result of changing the packet format settings.
You can zoom in and out using the + and — keys and reset the zoom level using the 0 key.
The following settings are available in the Print dialog box:

Page Setup…​ lets you select the page size and orientation.

Print…​ prints to your default printer.

Cancel will close the dialog without printing.

Help will display this section of the “User’s Guide”.

5.9. The “Packet Range” Frame

Figure 5.17. The “Packet Range” frame

All packets

All captured or displayed packets depending on the primary selection above.

Selected packet

Only the selected packet.

Marked packets

Only marked packets. See Section 6.10, “Marking Packets”.

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.

Remove ignored packets

Don’t export or print ignored packets.
See Section 6.11, “Ignoring Packets”.

5.10. The Packet Format Frame

Figure 5.18. The “Packet Format” frame

Packet summary line

Export or print each summary line as shown in the “Packet List” pane.

Packet details

Export or print the contents of the “Packet Details” tree.

All collapsed

Export or print as if the “Packet Details” tree is in the “all collapsed” state.

As displayed

Export or print as if the “Packet Details” tree is in the “as displayed” state.

All expanded

Export or print as if the “Packet Details” tree is in the “all expanded” state.

Packet Bytes

Export or print the contents of the “Packet Bytes” pane.

Each packet on a new page

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 number of total packets and shown packets.

6.1. Viewing Packets You Have Captured

Figure 6.1. Wireshark with a TCP packet selected for viewing

Figure 6.2. Viewing a packet in a separate window

• Hold down the shift key and double-click on a frame link in the packet
  details.
• From Table 6.2, “The menu items of the “Packet List” pop-up menu”.
• From Table 6.3, “The menu items of the “Packet Details” pop-up menu”.

6.2. Pop-up Menus

The following table gives an overview of which functions are available
in this header, where to find the corresponding function in the main
menu, and a description of each item.

The following table gives an overview of which functions are available
in this pane, where to find the corresponding function in the main menu,
and a short description of each item.

The following table gives an overview of which functions are available in this
pane, where to find the corresponding function in the main menu, and a short
description of each item.

The following table gives an overview of which functions are available
in this pane along with a short description of each item.

The following table gives an overview of which functions are available
in this pane along with a short description of each item.

6.3. Filtering Packets While Viewing

• Protocol
• The presence of a field
• The values of fields
• A comparison between fields
• …​ and a lot more!

Figure 6.8. Filtering on the TCP protocol

6.4. Building Display Filter Expressions

The simplest display filter is one that displays a single protocol.
To only display packets containing a particular protocol, type the protocol
into Wireshark’s display filter toolbar. For example, to only
display TCP packets, type tcp into Wireshark’s display filter toolbar.
Similarly, to only display
packets containing a particular field, type the field
into Wireshark’s display filter toolbar. For example, to only display
HTTP requests, type http.request into Wireshark’s display filter toolbar.

You can filter on any protocol that Wireshark supports. You can
also filter on any field that a dissector adds to the tree view, if the dissector
has added an abbreviation for that field. A full list of the available protocols
and fields is available through the menu item
→ → .

You can build display filters that compare values using a number of different
comparison operators. For example, to only display packets to or
from the IP address 192.168.0.1, use ip.addr==192.168.0.1.

A complete list of available comparison operators is shown in Table 6.6, “Display Filter comparison operators”.

	Tip
English and C-like operators are interchangeable and can be mixed within a filter string.

	Note
The meaning of != (all not equal) was changed in Wireshark 3.6. Before it used to mean «any not equal».

All protocol fields have a type. Section 6.4.2.1, “Display Filter Field Types” provides a list
of the types with examples of how to use them in display filters.

udp contains 81:60:03

sip.To contains "a1762"

http.host matches "acme\\.(org|com|net)"

tcp.flags & 0x02

6.4.2.3. Possible Pitfalls Using Regular Expressions

String literals containing regular expressions are parsed twice. Once by Wireshark’s display
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"
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).

An example where this fails badly is foo matches "bar\x28". Because 0x28 is the ASCII
code for ( the pattern input to PCRE is "bar(". This regular expression is syntactically
invalid (missing closing parenthesis). To match a literal parenthesis in a display filter regular
expression it must be escaped (twice) with backslashes.

	Tip
Using raw strings avoids most problem with the «matches» operator and double escape requirements.

You can combine filter expressions in Wireshark using the logical operators shown in Table 6.7, “Display Filter Logical Operations”

Wireshark allows you to select a subsequence of a sequence in rather elaborate
ways. After a label you can place a pair of brackets [] containing a comma
separated list of range specifiers.

eth.src[0:3] == 00:00:83

The example above uses the n:m format to specify a single range. In this case n
is the beginning offset and m is the length of the range being specified.

eth.src[1-2] == 00:83

The example above uses the n-m format to specify a single range. In this case n
is the beginning offset and m is the ending offset.

eth.src[:4] == 00:00:83:00

The example above uses the :m format, which takes everything from the beginning
of a sequence to offset m. It is equivalent to 0:m

eth.src[4:] == 20:20

The example above uses the n: format, which takes everything from offset n to
the end of the sequence.

eth.src[2] == 83

The example above uses the n format to specify a single range. In this case the
element in the sequence at offset n is selected. This is equivalent to n:1.

eth.src[0:3,1-2,:4,4:,2] ==
00:00:83:00:83:00:00:83:00:20:20:83

Wireshark allows you to string together single ranges in a comma separated list
to form compound ranges as shown above.

A field can be restricted to a certain layer in the protocol stack using the
layer operator (#), followed by a decimal number:

ip.addr#2 == 192.168.30.40

matches only the inner (second) layer in the packet.
Layers use simple stacking semantics and protocol layers are counted sequentially starting from 1.
For example, in a packet that contains two IPv4 headers, the outer (first) source address can be matched with «ip.src#1» and the inner (second) source address can be matched with «ip.src#2».

For more complicated ranges the same syntax used with slices is valid:

tcp.port#[2-4]

means layers number 2, 3 or 4 inclusive. The hash symbol is required to
distinguish a layer range from a slice.

Wireshark allows you to test a field for membership in a set of values or
fields. After the field name, use the in operator followed by the set items
surrounded by braces {}. For example, to display packets with a TCP source or
destination port of 80, 443, or 8080, you can use tcp.port in {80, 443, 8080}.
Set elements must be separated by commas.
The set of values can also contain ranges: tcp.port in {443,4430..4434}.

Note

The display filter tcp.port in {80, 443, 8080} is equivalent to tcp.port == 80 || tcp.port == 443 || tcp.port == 8080 However, the display filter tcp.port in {443, 4430..4434} is not equivalent to tcp.port == 443 || (tcp.port >= 4430 && tcp.port <= 4434) This is because comparison operators are satisfied when any field matches the filter, so a packet with a source port of 56789 and destination port of port 80 would also match the second filter since 56789 >= 4430 && 80 <= 4434 is true. In contrast, the membership operator tests a single field against the range condition.

Sets are not just limited to numbers, other types can be used as well:

http.request.method in {"HEAD", "GET"}
ip.addr in {10.0.0.5 .. 10.0.0.9, 192.168.1.1..192.168.1.9}
frame.time_delta in {10 .. 10.5}

You can perform the arithmetic operations on numeric fields shown in Table 6.8, “Display Filter Arithmetic Operations”

Arithmetic expressions can be grouped using curly braces.

For example, frames where capture length resulted in truncated TCP options:

frame.cap_len < { 14 +  ip.hdr_len + tcp.hdr_len }

The display filter language has a number of functions to convert fields, see
Table 6.9, “Display Filter Functions”.

The upper and lower functions can used to force case-insensitive matches:
lower(http.server) contains "apache".

To find HTTP requests with long request URIs: len(http.request.uri) > 100.
Note that the len function yields the string length in bytes rather than
(multi-byte) characters.

Usually an IP frame has only two addresses (source and destination), but in case
of ICMP errors or tunneling, a single packet might contain even more addresses.
These packets can be found with count(ip.addr) > 2.

The string function converts a field value to a string, suitable for use with operators
like «matches» or «contains». Integer fields are converted to their decimal representation.
It can be used with IP/Ethernet addresses (as well as others), but not with string or
byte fields.

For example, to match odd frame numbers:

string(frame.number) matches "[13579]$"

To match IP addresses ending in 255 in a block of subnets (172.16 to 172.31):

string(ip.dst) matches r"^172\.(1[6-9]|2[0-9]|3[0-1])\.[0-9]{1,3}\.255"

The functions max() and min() take any number of arguments of the same type
and returns the largest/smallest respectively of the set.

max(tcp.srcport, tcp.dstport) <= 1024

As protocols evolve they sometimes change names or are superseded by
newer standards. For example, DHCP extends and has largely replaced
BOOTP and TLS has replaced SSL. If a protocol dissector originally used
the older names and fields for a protocol the Wireshark development team
might update it to use the newer names and fields. In such cases they
will add an alias from the old protocol name to the new one in order to
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
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.

In some particular cases relational expressions (equal, less than, etc.)
can be ambiguous. The filter name of a protocol or protocol field can contain
any letter and digit in any order, possibly separated by dots. That can be
indistinguishable from a literal value (usually numerical values in hexadecimal).
For example the semantic value of fc can be the protocol Fibre Channel or the
number 0xFC in hexadecimal because the 0x prefix is optional for hexadecimal numbers.

Any value that matches a registered protocol or protocol field filter name is
interpreted semantically as such. If it doesn’t match a protocol name the normal
rules for parsing literal values apply.

So in the case of ‘fc’ the lexical token is interpreted as «Fibre Channel» and
not 0xFC. In the case of ‘fd’ it would be interpreted as 0xFD because it is a
well-formed hexadecimal literal value (according to the rules of display filter
language syntax) and there is no protocol registered with the filter name ‘fd’.

How ambiguous values are interpreted may change in the future. To avoid this
problem and resolve the ambiguity there is additional syntax available.
Values prefixed with a dot are always treated as a protocol name. The
dot stands for the root of the protocol namespace and is optional). Values
prefixed with a colon are always interpreted as a byte array.

frame[10:] contains .fc or frame[10] == :fc

If you are writing a script, or you think your expression may not be giving the
expected results because of the syntactical ambiguity of some filter expression
it is advisable to use the explicit syntax to indicate the correct meaning for
that expression.

6.5. The “Display Filter Expression” Dialog Box

Figure 6.9. The “Display Filter Expression” dialog box

Field Name

Select a protocol field from the protocol field tree. Every protocol with
filterable fields is listed at the top level. You can search for a particular
protocol entry by entering the first few letters of the protocol name. By
expanding a protocol name you can get a list of the field names available for
filtering for that protocol.

Relation

Select a relation from the list of available relation. The is present is a
unary relation which is true if the selected field is present in a packet. All
other listed relations are binary relations which require additional data (e.g.
a Value to match) to complete.

When you select a field from the field name list and select a binary relation
(such as the equality relation ==) you will be given the opportunity to enter a
value, and possibly some range information.

Value

You may enter an appropriate value in the Value text box. The Value will
also indicate the type of value for the Field Name you have selected (like
character string).

Predefined Values

Some of the protocol fields have predefined values available, much like enumerations
in C. If the selected protocol field has such values defined, you can choose one
of them here.

Search

Lets you search for a full or partial field name or description.
Regular expressions are supported.
For example, searching for “tcp.*flag” shows the TCP flags fields supported by a wide variety of dissectors, while “^tcp.flag” shows only the TCP flags fields supported by the TCP dissector.

Range

A range of integers or a group of ranges, such as 1-12 or 39-42,98-2000.

Help

Opens this section of the User’s Guide.

OK

When you have built a satisfactory expression click OK and a filter string
will be built for you.

Cancel

You can leave the “Add Expression…​” dialog box without any effect by
clicking the Cancel button.

6.6. Defining And Saving Filters

Figure 6.10. The “Capture Filters” and “Display Filters” dialog boxes

+

Adds a new filter to the list.
You can edit the filter name or expression by double-clicking on it.

The filter name is used in this dialog to identify the filter for your convenience and is not used elsewhere.
You can create multiple filters with the same name, but this is not very useful.

When typing in a filter string, the background color will change depending on the validity of the filter similar to the main capture and display filter toolbars.

—

Delete the selected filter.
This will be greyed out if no filter is selected.

Copy

Copy the selected filter.
This will be greyed out if no filter is selected.

OK

Saves the filter settings and closes the dialog.

Cancel

Closes the dialog without saving any changes.

6.7. Defining And Saving Filter Macros

1. In the main menu select → . Wireshark will open a corresponding dialog Figure 6.11, “Display Filter Macros window”.

   Figure 6.11. Display Filter Macros window

2. To add a new filter macro, click the + button in the bottom-left corner. A new row will appear in the Display Filter Macros table above.
3. Enter the name of your macro in the Name column. Enter your filter macro in the Text column.
4. To save your modifications, click the OK button in the bottom-right corner of the Figure 6.11, “Display Filter Macros window”.

6.8. Finding Packets

You can search using the following criteria:

6.9. Go To A Specific Packet

Go back in the packet history, works much like the page history in most
web browsers.

Go forward in the packet history, works much like the page history in
most web browsers.

This toolbar can be opened by selecting → from
the main menu. It appears between the main toolbar and the packet list,
similar to the ”Find Packet” toolbar.

When you enter a packet number and press Go to packet
Wireshark will jump to that packet.

If a protocol field is selected which points to another packet in the capture
file, this command will jump to that packet.

As these protocol fields now work like links (just as in your Web browser), it’s
easier to simply double-click on the field to jump to the corresponding field.

This command will jump to the first packet displayed.

This command will jump to the last packet displayed.

6.10. Marking Packets

• toggles the marked state of a single packet.
  This option is also available in the packet list context menu.
• set the mark state of all displayed packets.
• reset the mark state of all packets.

6.11. Ignoring Packets

• toggles the ignored state of a single
  packet. This option is also available in the packet list context menu.
• set the ignored state of all displayed packets.
• reset the ignored state of all packets.

6.12. Time Display Formats And Time References

• The absolute date and time
  of the day when the packet was captured.
• The absolute time of the day when the packet
  was captured.
• The time relative to the
  start of the capture file or the first “Time Reference” before this packet
  (see Section 6.12.1, “Packet Time Referencing”).
• The time relative to the
  previous captured packet.
• The time relative to the
  previous displayed packet.
• The time relative to
  epoch (midnight UTC of January 1, 1970).

• The timestamp precision of the loaded capture file format will be
  used (the default).
• , , ,
  , or The
  timestamp precision will be forced to the given setting. If the
  actually available precision is smaller, zeros will be appended. If
  the precision is larger, the remaining decimal places will be cut off.

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
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
close the capture file.

Time referencing will only be useful if the time display format is set to
“Seconds Since First Captured Packet”. If one of the other time display formats
are used, time referencing will have no effect (and will make no sense either).

To work with time references, choose one of the items in
the menu:[Edit] menu or from the pop-up menu of the “Packet List” pane. See
Section 3.6, “The “Edit” Menu”.

A time referenced packet will be marked with the string *REF* in the Time
column (see packet number 10). All subsequent packets will show the time since
the last time reference.

7.1. Introduction

7.2. Following Protocol Streams

Figure 7.1. The “Follow TCP Stream” dialog box

Help

Show this help.

Filter out this stream

Apply a display filter removing the current
stream data from the display.

Print

Print the stream data in the currently selected format.

Save as…​

Save the stream data in the currently selected format.

Back

Close this dialog box and restore the previous display filter.

Close

Close this dialog box, leaving the current display filter in
effect.

In this view you see the data from each direction in ASCII.
Obviously best for ASCII based protocols, e.g., HTTP.

This allows you to import the stream data into your own C
program.

For the big-iron freaks out there.

This allows you to see all the data. This will require a lot of
screen space and is best used with binary protocols.

Like ASCII, but decode the data as UTF-8.

Like ASCII, but decode the data as UTF-16.

This allows you to load the stream as YAML.

• The peers section where for each peer you found the peer index, the host address and the port number.
• The packets section where for each packet you found the packet number in the original capture, the peer index,
  the packet index for this peer, the timestamp in seconds and the data in base64 encoding.

Example 7.1. Follow Stream YAML output

peers:
  - peer: 0
    host: 127.0.0.1
    port: 54048
  - peer: 1
    host: 127.0.10.1
    port: 5000
packets:
  - packet: 1
    peer: 0
    index: 0
    timestamp: 1599485409.693955274
    data: !!binary |
      aGVsbG8K
  - packet: 3
    peer: 1
    index: 0
    timestamp: 1599485423.885866692
    data: !!binary |
      Ym9uam91cgo=

This allows you to load the unaltered stream data into a different
program for further examination. The display will look the same as the ASCII
setting, but “Save As” will result in a binary file.

Figure 7.2. The “Follow HTTP/2 Stream” dialog box

Figure 7.3. The “Follow SIP Call” dialog box

7.3. Show Packet Bytes

Help

Show this help.

Print

Print the bytes in the currently selected format.

Copy

Copy the bytes to the clipboard in the currently selected format.

Save As

Save the bytes in the currently selected format.

Close

Close this dialog box.

This is the default which does not decode anything.

This will decode from Base64.

This will decompress the buffer using zlib.

This will decode from a string of hex digits. Non-hex characters are skipped.

This will decode from a Quoted-Printable string.

This will decode ROT-13 encoded text.

In this view you see the bytes as ASCII.
All control characters and non-ASCII bytes are replaced by dot.

In this view all control characters are shown using a
UTF-8 symbol and all non-ASCII bytes are replaced by dot.

This allows you to import the field data into your own C program.

For the big-iron freaks out there.

This allows you to see all the data. This will require a lot of
screen space and is best used with binary protocols.

This allows you to see all the data formatted as a HTML document.
The HTML supported is what’s supported by the Qt QTextEdit class.

This will try to convert the bytes into an image.
Most popular formats are supported including PNG, JPEG, GIF, and BMP.

In this view you see the bytes as ISO 8859-1.

This allows you to load the unaltered stream data into a different
program for further examination. The display will show HEX data, but
“Save As” will result in a binary file.

In this view you see the bytes as UTF-8.

In this view you see the bytes as UTF-16.

This will show the bytes as a YAML binary dump.

7.4. Expert Information

Expert information entries are grouped by severity level (described below) and contain the following: