Wireshark User’s Guide
Richard Sharpe Ed Warnicke Ulf Lamping
Chapter 7. Advanced Topics

Table of Contents

7.1. Introduction

7.2. Following Protocol Streams

7.3. Show Packet Bytes

7.4. Expert Information

7.4.1. Expert Information Entries

7.4.2. The “Expert Information” Dialog

7.4.3. “Colorized” Protocol Details Tree

7.4.4. “Expert” Packet List Column (Optional)

7.5. TCP Analysis

7.6. Time Stamps

7.6.1. Wireshark Internals

7.6.2. Capture File Formats

7.6.3. Accuracy

7.7. Time Zones

7.7.1. Wireshark and Time Zones

7.8. Packet Reassembly

7.8.1. What Is It?

7.8.2. How Wireshark Handles It

7.8.3. TCP Reassembly

7.9. Name Resolution

7.9.1. Name Resolution Drawbacks

7.9.2. Ethernet Name Resolution (MAC Layer)

7.9.3. IP Name Resolution (Network Layer)

7.9.4. TCP/UDP Port Name Resolution (Transport Layer)

7.9.5. VLAN ID Resolution

7.9.6. SS7 Point Code Resolution

7.10. Checksums

7.10.1. Wireshark Checksum Validation

7.10.2. Checksum Offloading

7.10.3. Partial Checksums

7.1. Introduction

This chapter will describe some of Wireshark’s advanced features.

7.2. Following Protocol Streams

It can be very helpful to see a protocol in the way that the application layer sees it. Perhaps you are looking for passwords in a Telnet stream, or you are trying to make sense of a data stream. Maybe you just need a display filter to show only the packets in a TLS or SSL stream. If so, Wireshark’s ability to follow protocol streams will be useful to you.

To filter to a particular stream, select a TCP, UDP, DCCP, TLS, HTTP, HTTP/2, QUIC or SIP packet in the packet list of the stream/connection you are interested in and then select the menu item Analyze → Follow → TCP Stream (or use the context menu in the packet list). Wireshark will set an appropriate display filter and display a dialog box with the data from the stream laid out, as shown in Figure 7.1, “The “Follow TCP Stream” dialog box”.

Figure 7.1. The “Follow TCP Stream” dialog box

The stream content is displayed in the same sequence as it appeared on the network. Non-printable characters are replaced by dots. Traffic from the client to the server is colored red, while traffic from the server to the client is colored blue. These colors can be changed by opening Edit → Preferences and under Appearance → Font and Colors, selecting different colors for the Sample "Follow Stream" client text and Sample "Follow Stream" server text options.

The stream content won’t be updated while doing a live capture. To get the latest content you’ll have to reopen the dialog.

You can choose from the following actions:

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.

By default, Wireshark displays both client and server data. You can select the Entire conversation to switch between both, client to server, or server to client data.

You can choose to view the data in one of the following formats:

ASCII

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

C Arrays

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

EBCDIC

For the big-iron freaks out there.

HEX Dump

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

UTF-8

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

UTF-16

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

YAML

This allows you to load the stream as YAML.

The YAML output is divided into 2 main sections:

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=

The same example but in old YAML format (before version 3.5):

# Packet 1 peer0_0: !!binary | aGVsbG8K # Packet 3 peer1_0: !!binary | Ym9uam91cgo=

How the old format data can be found in the new format:

New YAML format Old YAML format

Raw

This allows you to load the unaltered stream data into a different program for further examination. The display will show the data as strings of hex characters with each frame on a separate line, but “Save As” will result in a binary file without any added line separators.

You can optionally show the delta time each time the direction changes (turns) or for every packet or event.

You can switch between streams using the “Stream” selector.

You can search for text by entering it in the “Find” entry box and pressing Find Next.

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

The HTTP/2 Stream dialog is similar to the "Follow TCP Stream" dialog, except for an additional "Substream" dialog field. HTTP/2 Streams are identified by a HTTP/2 Stream Index (field name http2.streamid) which are unique within a TCP connection. The “Stream” selector determines the TCP connection whereas the “Substream” selector is used to pick the HTTP/2 Stream ID.

The QUIC protocol is similar, the first number selects the QUIC connection number while the "Substream" field selects the QUIC Stream ID.

Figure 7.3. The “Follow SIP Call” dialog box

The SIP call is shown with same dialog, just filter is based on sip.Call-ID field. Count of streams is fixed to 0 and the field is disabled.

7.3. Show Packet Bytes

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.

This dialog can also be used to decode field bytes from base64, various compressed formats or quoted-printable and show the decoded bytes as configurable output. It’s also possible to select a subset of bytes setting the start byte and end byte.

You can choose from the following actions:

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.

You can choose to decode the data from one of the following formats:

None

This is the default which does not decode anything.

Base64

This will decode from Base64 or Base64Url.

Compressed

This will decompress the buffer using lz77, lz77huff, lznt1, snappy, zlib or zstd.

Hex Digits

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

Percent-Encoding

This will decode from a Percent-Encoded string.

Quoted-Printable

This will decode from a Quoted-Printable string.

ROT-13

This will decode ROT-13 encoded text.

You can choose to view the data in one of the following formats:

ASCII

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

ASCII & Control

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

C Array

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

EBCDIC

For the big-iron freaks out there.

Hex Dump

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

HTML

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.

Image

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

ISO 8859-1

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

Raw

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

UTF-8

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

UTF-16

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

YAML

This will show the bytes as a YAML binary dump.

You can search for text by entering it in the “Find” entry box and pressing Find Next.

7.4. 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 behavior and to let novice and expert users find network problems faster than manually scanning through the packet list.

The amount of expert information largely depends on the protocol being used. While dissectors for some common protocols like TCP and IP will show detailed information, other dissectors will show little or none.

The following describes the components of a single expert information entry along with the expert user interface.

7.4.1. Expert Information Entries

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

Table 7.1. Example expert information items

Packet # Summary Group Protocol

592

TCP: [TCP Out-Of-Order] …​

Malformed

TCP

1202

DNS: Standard query response …​

Protocol

DNS

443

TCP: 80 → 59322 [RST] Seq=12761 Win=0 Len=0

Sequence

TCP

7.4.1.1. Severity

Every expert information item has a severity level. The following levels are used, from lowest to highest. Wireshark marks them using different colors, which are shown in parentheses:

Chat (blue)

Information about usual workflow, e.g., a TCP packet with the SYN flag set.

Note (cyan)

Notable events, e.g., an application returned a common error code such as HTTP 404.

Warn (yellow)

Warnings, e.g., application returned an unusual error code like a connection problem.

Error (red)

Serious problems, such as malformed packets.

7.4.1.2. Summary

Short explanatory text for each expert information item.

7.4.1.3. Group

Along with severity levels, expert information items are categorized by group. The following groups are currently implemented:

Assumption

The protocol field has incomplete data and was dissected based on assumed value.

Checksum

A checksum was invalid.

Comment

Packet comment.

Debug

Debugging information. You shouldn’t see this group in release versions of Wireshark.

Decryption

A decryption issue.

Deprecated

The protocol field has been deprecated.

Malformed

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). Dissection of this packet probably continued.

Reassemble

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.

Response Code

An application response code indicates a potential problem, e.g., HTTP 404 page not found.

Security

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.

Undecoded

Dissection incomplete or data can’t be decoded for other reasons.

It’s possible that more groups will be added in the future.

7.4.1.4. Protocol

The protocol dissector that created the expert information item.

7.4.2. The “Expert Information” Dialog

You can open the expert info dialog by selecting Analyze → Expert Info or by clicking the expert level indicator in the main status bar.

Right-clicking on an item will allow you to apply or prepare a filter based on the item, copy its summary text, and other tasks.

Figure 7.4. The “Expert Information” dialog box

You can choose from the following actions:

Limit to display filter

Only show expert information items present in packets that match the current display filter.

Group by summary

Group items by their summary instead of the groups described above.

Search

Only show items that match the search string, such as “dns”. Regular expressions are supported.

Show…​

Lets you show or hide each severity level. For example, you can deselect Chat and Note severities if desired.

Help

Takes you to this section of the User’s Guide.

Close

Closes the dialog

7.4.3. “Colorized” Protocol Details Tree

Figure 7.5. The “Colorized” protocol details tree

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. To make it easier find that item in the packet tree, the IP protocol toplevel item is marked cyan as well.

7.4.4. “Expert” Packet List Column (Optional)

Figure 7.6. The “Expert” packet list column

An optional “Expert Info Severity” packet list column is available that displays the most significant severity of a packet or stays empty if everything seems OK. This column is not displayed by default but can be easily added using the Preferences Columns page described in Section 11.5, “Preferences”.

7.5. TCP Analysis

By default, Wireshark’s TCP dissector tracks the state of each TCP session and provides additional information when problems or potential problems are detected. Analysis is done once for each TCP packet when a capture file is first opened. Packets are processed in the order in which they appear in the packet list. You can enable or disable this feature via the “Analyze TCP sequence numbers” TCP dissector preference.

For analysis of data or protocols layered on top of TCP (such as HTTP), see Section 7.8.3, “TCP Reassembly”.

Figure 7.7. “TCP Analysis” packet detail items

TCP Analysis flags are added to the TCP protocol tree under “SEQ/ACK analysis”. Each flag is described below. Terms such as “next expected sequence number” and “next expected acknowledgment number” refer to the following”:

Next expected sequence number

The last-seen sequence number plus segment length. Set when there are no analysis flags and for zero window probes. This is initially zero and calculated based on the previous packet in the same TCP flow. Note that this may not be the same as the tcp.nxtseq protocol field.

Next expected acknowledgment number

The last-seen sequence number for segments. Set when there are no analysis flags and for zero window probes.

Last-seen acknowledgment number

Always updated for each packet. Note that this is not the same as the next expected acknowledgment number.

TCP ACKed unseen segment

Set when the expected next acknowledgment number is set for the reverse direction and it’s less than the current acknowledgment number.

TCP Dup ACK <frame>#<acknowledgment number>

Set when all of the following are true:

The segment size is zero.

The window size is non-zero and hasn’t changed, or there is valid SACK data.

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 Fast Retransmission

Set when all of the following are true:

This is not a keepalive packet.

In the forward direction, the segment size is greater than zero or the SYN or FIN is set.

The next expected sequence number is greater than the current sequence number.

We have at least two duplicate ACKs in the reverse direction.

The current sequence number equals the next expected acknowledgment number.

We saw the last acknowledgment less than 20ms ago.

Supersedes “Out-Of-Order” and “Retransmission”.

TCP Keep-Alive

Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence number, and none of SYN, FIN, or RST are set.

Supersedes “Fast Retransmission”, “Out-Of-Order”, “Spurious Retransmission”, and “Retransmission”.

TCP Keep-Alive ACK

Set when all of the following are true:

The segment size is zero.

The window size is non-zero and hasn’t changed.

The current sequence number is the same as the next expected sequence number.

The current acknowledgment number is the same as the last-seen acknowledgment number.

The most recently seen packet in the reverse direction was a keepalive.

The packet is not a SYN, FIN, or RST.

Supersedes “Dup ACK” and “ZeroWindowProbeAck”.

TCP Out-Of-Order

Set when all of the following are true:

This is not a keepalive packet.

In the forward direction, the segment length is greater than zero or the SYN or FIN is set.

The next expected sequence number is greater than the current sequence number.

The next expected sequence number and the next sequence number differ.

The last segment arrived within the Out-Of-Order RTT threshold. The threshold is either the value shown in the “iRTT” (tcp.analysis.initial_rtt) field under “SEQ/ACK analysis” if it is present, or the default value of 3ms if it is not.

Supersedes “Retransmission”.

TCP Port numbers reused

Set when the SYN flag is set (not SYN+ACK), we have an existing conversation using the same addresses and ports, and the sequence number is different than the existing conversation’s initial sequence number.

TCP Previous segment not captured

Set when the current sequence number is greater than the next expected sequence number.

TCP Spurious Retransmission

Checks for a retransmission based on analysis data in the reverse direction. Set when all of the following are true:

The SYN or FIN flag is set.

This is not a keepalive packet.

The segment length is greater than zero.

Data for this flow has been acknowledged. That is, the last-seen acknowledgment number has been set.

The next sequence number is less than or equal to the last-seen acknowledgment number.

Supersedes “Fast Retransmission”, “Out-Of-Order”, and “Retransmission”.

TCP Retransmission

Set when all of the following are true:

This is not a keepalive packet.

In the forward direction, the segment length is greater than zero or the SYN or FIN flag is set.

The next expected sequence number is greater than the current sequence number.

TCP Window Full

Set when the segment size is non-zero, we know the window size in the reverse direction, and our segment size exceeds the window size in the reverse direction.

TCP Window Update

Set when the all of the following are true:

The segment size is zero.

The window size is non-zero and not equal to the last-seen window size, and there is no valid SACK data.

The sequence number is equal to the next expected sequence number.

The acknowledgment number is equal to the last-seen acknowledgment number,

or to the next expected sequence number when answering to a ZeroWindowProbe.

None of SYN, FIN, or RST are set.

TCP ZeroWindow

Set when the receive window size is zero and none of SYN, FIN, or RST are set.

The window field in each TCP header advertises the amount of data a receiver can accept. If the receiver can’t accept any more data it will set the window value to zero, which tells the sender to pause its transmission. In some specific cases this is normal — for example, a printer might use a zero window to pause the transmission of a print job while it loads or reverses a sheet of paper. However, in most cases this indicates a performance or capacity problem on the receiving end. It might take a long time (sometimes several minutes) to resume a paused connection, even if the underlying condition that caused the zero window clears up quickly.

TCP ZeroWindowProbe

Set when the sequence number is equal to the next expected sequence number, the segment size is one, and last-seen window size in the reverse direction was zero.

If the single data byte from a Zero Window Probe is dropped by the receiver (not ACKed), then a subsequent segment should not be flagged as retransmission if all of the following conditions are true for that segment: * The segment size is larger than one. * The next expected sequence number is one less than the current sequence number.

This affects “Fast Retransmission”, “Out-Of-Order”, or “Retransmission”.

TCP ZeroWindowProbeAck

Set when the all of the following are true:

The segment size is zero.

The window size is zero.

The sequence number is equal to the next expected sequence number.

The acknowledgment number is equal to the last-seen acknowledgment number.

The last-seen packet in the reverse direction was a zero window probe.

Supersedes “TCP Dup ACK”.

TCP Ambiguous Interpretations

Some captures are quite difficult to analyze automatically, particularly when the time frame may cover both Fast Retransmission and Out-Of-Order packets. A TCP preference allows to switch the precedence of these two interpretations at the 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 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 :

1 : SYN

2 : SYN-ACK

4 : ACK

8 : DATA

16 : FIN

32 : RST

For example, a conversation containing only a three-way handshake will be found with the filter 'tcp.completeness==7' (1+2+4) while a complete conversation with data transfer will be found with a longer filter as closing a connection can be associated with FIN or RST packets, or even both : 'tcp.completeness==31 or tcp.completeness==47 or tcp.completeness==63'

Another way to select specific conversation values is to filter on individual flags, the summary field, or a combination of them. Thus, '(tcp.completeness.fin==1 || tcp.completeness.rst==1) && tcp.completeness.str contains "DASS"' will find all 'Complete, WITH_DATA' conversations, while the 'Complete, NO_DATA' ones will be found with '(tcp.completeness.fin==1 || tcp.completeness.rst==1) && tcp.completeness.data==0 && tcp.completeness.str contains "ASS"'.

7.6. Time Stamps

Time stamps, their precisions and all that can be quite confusing. This section will provide you with information about what’s going on while Wireshark processes time stamps.

While packets are captured, each packet is time stamped as it comes in. These time stamps will be saved to the capture file, so they also will be available for (later) analysis.

So where do these time stamps come from? While capturing, Wireshark gets the time stamps from the libpcap (Npcap) library, which in turn gets them from the operating system kernel. If the capture data is loaded from a capture file, Wireshark obviously gets the data from that file.

7.6.1. Wireshark Internals

The internal format that Wireshark uses to keep a packet time stamp consists of the date (in days since 1.1.1970) and the time of day (in nanoseconds since midnight). You can adjust the way Wireshark displays the time stamp data in the packet list, see the “Time Display Format” item in the Section 3.7, “The “View” Menu” for details.

While reading or writing capture files, Wireshark converts the time stamp data between the capture file format and the internal format as required.

While capturing, Wireshark uses the libpcap (Npcap) capture library which supports nanosecond resolution for both pcapng and pcap files, though some devices may only provide microsecond resolution, in which case that will be used. Unless you are working with specialized capturing hardware, this resolution should be adequate.

7.6.2. Capture File Formats

The vast majority of capture file formats that Wireshark knows support 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, “0.123456”), while some file formats are capable of storing the time stamp precision itself or even having a different precision for different records in the file (whatever the benefit may be).

The pcapng capture file format supports a wide range of time stamp resolutions, which can be different for each interface in the file, as well as records without time stamps. The common libpcap capture file format, which is widely supported by many other tools, supports two possible fixed resolutions, microsecond or nanosecond, indicated by a magic number at the start of the file. Wireshark and tools like editcap can convert pcap files with nanosecond resolution to microsecond resolution for use with tools that only support the original time stamp precision.

Writing data into a capture file format that doesn’t provide the capability to store the actual precision will lead to loss of information. For example, if you load a capture file with nanosecond resolution and store the capture data in a libpcap file (with microsecond resolution) Wireshark obviously must reduce the precision from nanosecond to microsecond.

7.6.3. Accuracy

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 above question is difficult to answer in a general way.

7.7. Time Zones

If you travel across the planet, time zones can be confusing. If you get a capture file from somewhere around the world time zones can even be a lot more confusing ;-)

First of all, there are two reasons why you may not need to think about time zones at all:

You are only interested in the time differences between the packet time stamps and don’t need to know the exact date and time of the captured packets (which is often the case).

You don’t get capture files from different time zones than your own, so there are simply no time zone problems. For example, everyone in your team is working in the same time zone as yourself.

What are time zones?

People expect that the time reflects the sunset. Dawn should be in the morning maybe around 06:00 and dusk in the evening maybe at 20:00. These times will obviously vary depending on the season. It would be very confusing if everyone on earth would use the same global time as this would correspond to the sunset only at a small part of the world.

For that reason, the earth is split into several different time zones, each zone with a local time that corresponds to the local sunset.

The time zone’s base time is UTC (Coordinated Universal Time) or Zulu Time (military and aviation). The older term GMT (Greenwich Mean Time) shouldn’t be 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 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)!

Further information can be found at: https://en.wikipedia.org/wiki/Time_zone and https://en.wikipedia.org/wiki/Coordinated_Universal_Time.

What is daylight saving time (DST)?

Daylight Saving Time (DST), also known as Summer Time is intended to “save” some daylight during the summer months. To do this, a lot of countries (but not all!) add a DST hour to the already existing UTC offset. So you may need to take another hour (or in very rare cases even two hours!) difference into your “time 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 Australia).

Keep in mind: UTC remains the same all year around, regardless of DST!

Further information can be found at https://en.wikipedia.org/wiki/Daylight_saving.

Further time zone and DST information can be found at https://wwp.greenwichmeantime.com/ and https://www.timeanddate.com/worldclock/.

Set your computer’s time correctly!

If you work with people around the world it’s very helpful to set your computer’s time and time zone right.

You should set your computers time and time zone in the correct sequence:

Set your time zone to your current location

Set your computer’s clock to the local time

This way you will tell your computer both the local time and also the time offset to UTC. Many organizations simply set the time zone on their servers and networking gear to UTC in order to make coordination and troubleshooting easier.

You can use the Network Time Protocol (NTP) to automatically adjust your computer to the correct time, by synchronizing it to Internet NTP clock servers. NTP clients are available for all operating systems that Wireshark supports (and for a lot more), for examples see http://www.ntp.org/.

7.7.1. Wireshark and Time Zones

So what’s the relationship between Wireshark and time zones anyway?

Wireshark’s native capture file format (libpcap format), and some other capture file formats, such as the Windows Sniffer, *Peek, Sun snoop formats, and newer versions of the Microsoft Network Monitor and Network Instruments/Viavi Observer formats, save the arrival time of packets as UTC values. UN*X systems, and “Windows NT based” systems represent time internally as UTC. When Wireshark is capturing, no conversion is necessary. However, if the system time zone is not set correctly, the system’s UTC time might not be correctly set even if the system clock appears to display correct local time. When capturing, Npcap has to convert the time to UTC before supplying it to Wireshark. If the system’s time zone is not set correctly, that conversion will not be done correctly.

Other capture file formats, such as the OOS-based Sniffer format and older versions of the Microsoft Network Monitor and Network Instruments/Viavi Observer formats, save the arrival time of packets as local time values.

Internally to Wireshark, time stamps are represented in UTC. This means that when reading capture files that save the arrival time of packets as local time values, Wireshark must convert those local time values to UTC values.

Wireshark in turn will display the time stamps always in local time. The displaying computer will convert them from UTC to local time and displays this (local) time. For capture files saving the arrival time of packets as UTC values, this means that the arrival time will be displayed as the local time in your time zone, which might not be the same as the arrival time in the time zone in which the packet was captured. For capture files saving the arrival time of packets as local time values, the conversion to UTC will be done using your time zone’s offset from UTC and DST rules, which means the conversion will not be done correctly; the conversion back to local time for display might undo this correctly, in which case the arrival time will be displayed as the arrival time in which the packet was captured.

Table 7.2. Time zone examples for UTC arrival times (without DST)

Los Angeles New York Madrid London Berlin Tokyo

Capture File (UTC)

10:00

10:00

10:00

10:00

10:00

10:00

Local Offset to UTC

-8

-5

-1

0

+1

+9

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

Now you have a phone call, video conference or Internet meeting with that one to talk about that capture file. As you are both looking at the displayed time on your local computers, the one in Los Angeles still sees 2 o’clock but you in Berlin will see 11 o’clock. The time displays are different as both Wireshark displays will show the (different) local times at the same point in time.

Conclusion: You may not bother about the date/time of the time stamp you currently look at unless you must make sure that the date/time is as expected. So, if you get a capture file from a different time zone and/or DST, you’ll have to find out the time zone/DST difference between the two local times and “mentally adjust” the time stamps accordingly. In any case, make sure that every computer in question has the correct time and time zone setting.

7.8. Packet Reassembly

7.8.1. 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 packet size), or is stream-based like TCP, which doesn’t know data chunks at all.

In that case the network protocol has to handle the chunk boundaries itself and (if required) spread the data over multiple packets. It obviously also needs a 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.).

7.8.2. How Wireshark Handles It

For some of the network protocols Wireshark knows of, a mechanism is implemented to find, decode and display these chunks of data. Wireshark will try to find the corresponding packets of this chunk, and will show the combined data as additional tabs in the “Packet Bytes” pane (for information about this pane. See Section 3.20, “The “Packet Bytes” Pane”).

Figure 7.8. The “Packet Bytes” pane with a reassembled tab

Reassembly might take place at several protocol layers, so it’s possible that multiple tabs in the “Packet Bytes” pane appear.

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.

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 reassembly can be enabled or disabled via the protocol preferences.

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.

7.8.3. TCP Reassembly

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 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 (Section 7.5, “TCP Analysis”). Keep in mind, 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 are lost or delivered out-of-order.

To reassemble of out-of-order TCP segments, the TCP protocol preference “Reassemble out-of-order segments” (currently disabled by default) must be 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 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. Applications usually retransmit segments until these are acknowledged, but if the packet capture drops packets, then Wireshark will not be able to reconstruct the TCP stream. In such cases, you can try to disable this preference and hopefully have a partial dissection instead of seeing just “[TCP segment of a reassembled PDU]” for every TCP segment.

When doing a capture in monitor mode (IEEE 802.11), packets are more likely to get lost due to signal reception issues. In that case it is recommended to disable the option.

If the new and missing segments are in fact part of different PDUs, then processing is currently delayed until no more segments are missing, even if the begin of the missing segments completed a PDU. For example, assume six segments forming two PDUs ABC and DEF. When received as ABECDF, an application can start processing the first PDU after receiving ABEC. Wireshark however requires the missing segment D to be received as well. This issue will be addressed in the future.

In the GUI and during a two-pass dissection (tshark -2), the previous scenario will display both PDUs in the packet with last segment (F) rather than displaying it in the first packet that has the final missing segment of a PDU. This issue will be addressed in the future.

When enabled, fields such as the SMB “Time from request” (smb.time) might be smaller if the request follows other out-of-order segments (this reflects application behavior). If the previous scenario however occurs, then the time of the request is based on the frame where all missing segments are received.

Regardless of the setting of these two reassembly-related preferences, you can always use the “Follow TCP Stream” option (Section 7.2, “Following Protocol Streams”) which displays segments in the expected order.

7.9. Name Resolution

Name resolution tries to convert some of the numerical address values into a human readable format. There are two possible ways to do these conversions, depending on the resolution to be done: calling system/network services (like the gethostname() function) and/or resolving from Wireshark specific configuration files. For details about the configuration files Wireshark uses for name resolution and alike, see Appendix B, Files and Folders.

The name resolution feature can be enabled individually for the protocol layers listed in the following sections.

7.9.1. Name Resolution Drawbacks

Name resolution can be invaluable while working with Wireshark and may even save you hours of work. Unfortunately, it also has its drawbacks.

Name resolution can often fail. The name to be resolved might simply be unknown by the name servers asked, or the servers are just not available and 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 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 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.

Resolved DNS names are cached by Wireshark. This is required for acceptable 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.

Name resolution in the packet list is done while the list is filled. If a name can be resolved after a packet is added to the list, its former entry won’t be changed. As the name resolution results are cached, you can use View → Reload to rebuild the packet list with the correctly resolved names. However, this isn’t possible while a capture is in progress.

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

ARP name resolution (system service): Wireshark will ask the operating system to convert an Ethernet address to the corresponding IP address (e.g. 00:09:5b:01:02:03 → 192.168.0.1).

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 → homerouter).

Ethernet manufacturer codes (manuf file): If neither ARP or ethers returns a result, Wireshark tries to convert the first 3 bytes of an ethernet address to an abbreviated manufacturer name, which has been assigned by the IEEE (e.g. 00:09:5b:01:02:03 → Netgear_01:02:03).

7.9.3. IP Name Resolution (Network Layer)

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

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. Capture file analysis is different. A given file might have hundreds, thousands, or millions of IP addresses so for usability and performance reasons Wireshark uses asynchronous resolution. Both mechanisms convert IP addresses to human readable (domain) names and typically use different sources such as the system hosts file (/etc/hosts) and any configured DNS servers.

Since Wireshark doesn’t wait for DNS responses, the host name for a given address might be missing from a given packet when you view it the first time but be present when you view it subsequent times.

You can adjust name resolution behavior in the Name Resolution section in the Preferences Dialog. You can control resolution itself by adding a hosts file to your personal configuration directory. You can also edit your system hosts file, but that isn’t generally recommended.

7.9.4. TCP/UDP Port Name Resolution (Transport Layer)

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

7.9.5. VLAN ID Resolution

To get a descriptive name for a VLAN tag ID a vlans file can be used.

7.9.6. SS7 Point Code Resolution

To get a node name for a SS7 point code a ss7pcs file can be used.

7.10. Checksums

Several network protocols use checksums to ensure data integrity. Applying checksums as described here is also known as redundancy checking.

What are checksums for?

Checksums are used to ensure the integrity of data portions for data transmission or storage. A checksum is basically a calculated summary of such a data portion.

Network data transmissions often produce errors, such as toggled, missing or duplicated bits. As a result, the data received might not be identical to the data transmitted, which is obviously a bad thing.

Because of these transmission errors, network protocols very often use checksums to detect such errors. The transmitter will calculate a checksum of the data and transmits the data together with the checksum. The receiver will calculate the checksum of the received data with the same algorithm as the transmitter. If the received and calculated checksums don’t match a transmission error has occurred.

Some checksum algorithms are able to recover (simple) errors by calculating where the expected error must be and repairing it.

If there are errors that cannot be recovered, the receiving side throws away the packet. Depending on the network protocol, this data loss is simply ignored or the sending side needs to detect this loss somehow and retransmits the required packet(s).

Using a checksum drastically reduces the number of undetected transmission errors. However, the usual checksum algorithms cannot guarantee an error detection of 100%, so a very small number of transmission errors may remain undetected.

There are several different kinds of checksum algorithms; an example of an often used checksum algorithm is CRC32. The checksum algorithm actually chosen for a specific network protocol will depend on the expected error rate of the network medium, the importance of error detection, the processor load to perform the calculation, the performance needed and many other things.

Further information about checksums can be found at: https://en.wikipedia.org/wiki/Checksum.

7.10.1. Wireshark Checksum Validation

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

If the checksum validation is enabled and it detected an invalid checksum, features like packet reassembly won’t be processed. This is avoided as incorrect connection data could “confuse” the internal database.

7.10.2. Checksum Offloading

The checksum calculation might be done by the network driver, protocol driver or even in hardware.

For example: The Ethernet transmitting hardware calculates the Ethernet CRC32 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 implementation and the completed packet is then handed over to the hardware.

Recent network hardware can perform advanced features such as IP checksum calculation, also known as checksum offloading. The network driver won’t calculate the checksum itself but will simply hand over an empty (zero or garbage filled) checksum field to the hardware.

Checksum offloading can be confusing and having a lot of [invalid] messages on the screen can be quite annoying. As mentioned above, invalid checksums may lead to unreassembled packets, making the analysis of the packet data much harder.

You can do two things to avoid this checksum offloading problem:

Turn off the checksum offloading in the network driver, if this option is available.

Turn off checksum validation of the specific protocol in the Wireshark preferences. Recent releases of Wireshark disable checksum validation by default due to the prevalence of offloading in modern hardware and operating systems.

7.10.3. Partial Checksums

TCP and UDP checksums are calculated over both the payload and from selected elements from the IPv4 or IPv6 header, known as the pseudo header. Linux and Windows, when offloading checksums, will calculate the contribution from the pseudo header and place it in the checksum field. The driver then directs the hardware to calculate the checksum over the payload area, which will produce the correct result including the pseudo header’s portion of the sum as a matter of mathematics.

This precomputation speeds up the hardware checksum calculation later, allows the driver to direct the hardware to do checksums over encapsulated payloads (Local Checksum Offload), and allows applications to send the kernel large "superpacket" buffers that will be later divided by the hardware into multiple maximum size packets when sent on the network (TCP Segmentation Offload (TSO) and Generic Segmentation Offload (GSO)).

Chapter 11. Customizing Wireshark

Table of Contents

11.1. Introduction

11.2. Start Wireshark from the command line

11.3. Packet colorization

11.4. Control Protocol Dissection

11.4.1. The “Enabled Protocols” dialog box

11.4.2. User Specified Decodes

11.5. Preferences

11.5.1. Appearance

11.5.2. Columns

11.5.3. Font and Colors

11.5.4. Layout

11.5.5. Capture

11.5.6. Expert Items

11.5.7. Filter Buttons

11.5.8. Name Resolution

11.5.9. Protocols

11.5.10. RSA Keys

11.5.11. Statistics

11.5.12. Advanced

11.6. Configuration Profiles

11.6.1. Automatic Profile Switching

11.7. User Accessible Tables

11.8. ESS Category Attributes

11.9. MaxMind Database Paths

11.10. IEEE 802.11 WLAN Decryption Keys

11.10.1. Adding Keys

11.10.2. Gotchas

11.11. IKEv2 decryption table

11.12. Object Identifiers

11.13. PRES Users Context List

11.14. SCCP users Table

11.15. SMI (MIB and PIB) Modules

11.16. SMI (MIB and PIB) Paths

11.17. SNMP Enterprise Specific Trap Types

11.18. SNMP users Table

11.19. Tektronix K12xx/15 RF5 protocols Table

11.20. User DLTs dissector table

11.21. Protobuf Search Paths

11.22. Protobuf UDP Message Types

11.1. Introduction

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:

How to start Wireshark with command line parameters

How to colorize the packet list

How to control protocol dissection

How to use the various preference settings

11.2. Start Wireshark from the command line

You can start Wireshark from the command line, but it can also be started from most Window managers as well. In this section we will look at starting it from the command line.

Wireshark supports a large number of command line parameters. To see what they are, simply enter the command wireshark -h and the help information shown in Help information available from Wireshark (or something similar) should be printed.

Help information available from Wireshark.

Wireshark 4.3.2 (v4.3.2rc0-41-gbaf0bfc263ea) Interactively dump and analyze network traffic. See https://www.wireshark.org for more information. Usage: wireshark [options] ... [ <infile> ] Capture interface: -i <interface>, --interface <interface> name or idx of interface (def: first non-loopback) -f <capture filter> packet filter in libpcap filter syntax -s <snaplen>, --snapshot-length <snaplen> packet snapshot length (def: appropriate maximum) -p, --no-promiscuous-mode don't capture in promiscuous mode -I, --monitor-mode capture in monitor mode, if available -B <buffer size>, --buffer-size <buffer size> size of kernel buffer (def: 2MB) -y <link type>, --linktype <link type> link layer type (def: first appropriate) --time-stamp-type <type> timestamp method for interface -D, --list-interfaces print list of interfaces and exit -L, --list-data-link-types print list of link-layer types of iface and exit --list-time-stamp-types print list of timestamp types for iface and exit Capture display: -k start capturing immediately (def: do nothing) -S update packet display when new packets are captured --update-interval interval between updates with new packets (def: 100ms) -l turn on automatic scrolling while -S is in use Capture stop conditions: -c <packet count> stop after n packets (def: infinite) -a <autostop cond.> ..., --autostop <autostop cond.> ... duration:NUM - stop after NUM seconds filesize:NUM - stop this file after NUM KB files:NUM - stop after NUM files packets:NUM - stop after NUM packets Capture output: -b <ringbuffer opt.> ..., --ring-buffer <ringbuffer opt.> duration:NUM - switch to next file after NUM secs filesize:NUM - switch to next file after NUM KB files:NUM - ringbuffer: replace after NUM files packets:NUM - switch to next file after NUM packets interval:NUM - switch to next file when the time is an exact multiple of NUM secs Input file: -r <infile>, --read-file <infile> set the filename to read from (no pipes or stdin!) Processing: -R <read filter>, --read-filter <read filter> packet filter in Wireshark display filter syntax -n disable all name resolutions (def: all enabled) -N <name resolve flags> enable specific name resolution(s): "mtndsNvg" -d <layer_type>==<selector>,<decode_as_protocol> ... "Decode As", see the man page for details Example: tcp.port==8888,http --enable-protocol <proto_name> enable dissection of proto_name --disable-protocol <proto_name> disable dissection of proto_name --only-protocols <proto_name> Only enable dissection of these protocols, comma separated. Disable everything else --disable-all-protocols Disable dissection of all protocols --enable-heuristic <short_name> enable dissection of heuristic protocol --disable-heuristic <short_name> disable dissection of heuristic protocol User interface: -C <config profile> start with specified configuration profile -H hide the capture info dialog during packet capture -Y <display filter>, --display-filter <display filter> start with the given display filter -g <packet number> go to specified packet number after "-r" -J <jump filter> jump to the first packet matching the (display) filter -j search backwards for a matching packet after "-J" -t (a|ad|adoy|d|dd|e|r|u|ud|udoy)[.[N]]|.[N] format of time stamps (def: r: rel. to first) -u s|hms output format of seconds (def: s: seconds) -X <key>:<value> eXtension options, see man page for details -z <statistics> show various statistics, see man page for details Output: -w <outfile|-> set the output filename (or '-' for stdout) -F <capture type> set the output file type; default is pcapng. an empty "-F" option will list the file types. --capture-comment <comment> add a capture file comment, if supported --temp-dir <directory> write temporary files to this directory (default: /tmp) Diagnostic output: --log-level <level> sets the active log level ("critical", "warning", etc.) --log-fatal <level> sets level to abort the program ("critical" or "warning") --log-domains <[!]list> comma-separated list of the active log domains --log-fatal-domains <list> list of domains that cause the program to abort --log-debug <[!]list> list of domains with "debug" level --log-noisy <[!]list> list of domains with "noisy" level --log-file <path> file to output messages to (in addition to stderr) Miscellaneous: -h, --help display this help and exit -v, --version display version info and exit -P <key>:<path> persconf:path - personal configuration files persdata:path - personal data files -o <name>:<value> ... override preference or recent setting -K <keytab> keytab file to use for kerberos decryption --display <X display> X display to use --fullscreen start Wireshark in full screen

We will examine each of the command line options in turn.

The first thing to notice is that issuing the command wireshark by itself will launch Wireshark. However, you can include as many of the command line parameters as you like. Their meanings are as follows ( in alphabetical order ):

-a <capture autostop condition>, --autostop <capture autostop condition>

Specify a criterion that specifies when Wireshark is to stop writing to a capture file. The criterion is of the form test:value, where test is one of:

duration:value

Stop writing to a capture file after value of seconds have elapsed.

filesize:value

Stop writing to a capture file after it reaches a size of value kilobytes (where a kilobyte is 1000 bytes, not 1024 bytes). If this option is used together with the -b option, Wireshark will stop writing to the current capture file and switch to the next one if filesize is reached.

files:value

Stop writing to capture files after value number of files were written.

packets:value

Stop writing to a capture file after value number of packets were written.

-b <capture ring buffer option>

If a maximum capture file size was specified, this option causes Wireshark to run in “ring buffer” mode, with the specified number of files. In “ring buffer” mode, Wireshark will write to several capture files. Their name is based on the number of the file and on the creation date and time.

When the first capture file fills up Wireshark will switch to writing to the next file, and so on. With the files option it’s also possible to form a “ring buffer.” This will fill up new files until the number of files specified, at which point the data in the first file will be discarded so a new file can be written.

If the optional duration is specified, Wireshark will also switch to the next file when the specified number of seconds has elapsed even if the current file is not completely filled up.

duration:value

Switch to the next file after value seconds have elapsed, even if the current file is not completely filled up.

filesize:value

Switch to the next file after it reaches a size of value kilobytes (where a kilobyte is 1000 bytes, not 1024 bytes).

files:value

Begin again with the first file after value number of files were written (form a ring buffer).

packets:value

Switch to the next file after value number of packets were written, even if the current file is not completely filled up.

interval:value

Switch to the next file when the time is an exact multiple of value seconds.

-B <capture buffer size>, --buffer-size <capture buffer size>

Set capture buffer size (in MB, default is 2MB). This is used by the capture driver to buffer packet data until that data can be written to disk. If you encounter packet drops while capturing, try to increase this size. Not supported on some platforms.

-C <config profile>

Start with the specified configuration profile.

-c <capture packet count>

This option specifies the maximum number of packets to capture when capturing live data. It would be used in conjunction with the -k option.

--capture-comment <comment>

Add the comment string to the capture file, if supported by the file format.

-d <layer_type>==<selector>,<decode_as_protocol>

"Decode As", see Section 11.4.2, “User Specified Decodes” for details. Example: tcp.port==8888,http

-D, --list-interfaces

Print a list of the interfaces on which Wireshark can capture, then exit. For each network interface, a number and an interface name, possibly followed by a text description of the interface, is printed. The interface name or the number can be supplied to the -i flag to specify an interface on which to capture.

This can be useful on systems that don’t have a command to list them (e.g., Windows systems, or UNIX systems lacking ifconfig -a). The number can be especially useful on Windows, where the interface name is a GUID.

Note that “can capture” means that Wireshark was able to open that device to do a live capture. If, on your system, a program doing a network capture must be run from an account with special privileges, then, if Wireshark is run with the -D flag and is not run from such an account, it will not list any interfaces.

--display <DISPLAY>

Set the X display to use, instead of the one defined in the environment, or the default display.

--enable-protocol <proto_name>, --disable-protocol <proto_name>

Enable and disable the dissection of the protocol.

--enable-heuristic <short_name>, --disable-heuristic <short_name>

Enable and disable the dissection of the heuristic protocol.

-f <capture filter>

This option sets the initial capture filter expression to be used when capturing packets.

--fullscreen

Start Wireshark in full screen.

-g <packet number>

After reading in a capture file using the -r flag, go to the given packet number.

-h, --help

This option requests Wireshark to print its version and usage instructions (as shown here) and exit.

-H

Hide the capture info dialog during live packet capture.

-i <capture interface>, --interface <capture interface>

Set the name of the network interface or pipe to use for live packet capture.

Network interface names should match one of the names listed in wireshark -D (described above). A number, as reported by wireshark -D, can also be used. If you’re using UNIX, netstat -i, ifconfig -a or ip link might also work to list interface names, although not all versions of UNIX support the -a flag to ifconfig.

If no interface is specified, Wireshark searches the list of interfaces, choosing the first non-loopback interface if there are any non-loopback interfaces, and choosing the first loopback interface if there are no non-loopback interfaces; if there are no interfaces, Wireshark reports an error and doesn’t start the capture.

Pipe names should be either the name of a FIFO (named pipe) or “-” to read data from the standard input. Data read from pipes must be in standard libpcap format.

-J <jump filter>

After reading in a capture file using the -r flag, jump to the first packet which matches the filter expression. The filter expression is in display filter format. If an exact match cannot be found the first packet afterwards is selected.

-I, --monitor-mode

Capture wireless packets in monitor mode if available.

-j

Use this option after the -J option to search backwards for a first packet to go to.

-k

The -k option specifies that Wireshark should start capturing packets immediately. This option requires the use of the -i parameter to specify the interface that packet capture will occur from.

-K <keytab file>

Use the specified file for Kerberos decryption.

-l

This option turns on automatic scrolling if the packet list pane is being updated automatically as packets arrive during a capture (as specified by the -S flag).

-L, --list-data-link-types

List the data link types supported by the interface and exit.

--list-time-stamp-types

List timestamp types configurable for the interface and exit.

-m <font>

This option sets the name of the font used for most text displayed by Wireshark.

-n

Disable network object name resolution (such as hostname, TCP and UDP port names).

-N <name resolving flags>

Turns on name resolving for particular types of addresses and port numbers. The argument is a string that may contain the following letters:

N

Use external name resolver.

d

Enable name resolution from captured DNS packets.

m

Enable MAC address resolution.

n

Enable network address resolution.

t

Enable transport layer port number resolution.

v

Enable VLAN ID resolution.

-o <preference or recent settings>

Sets a preference or recent value, overriding the default value and any value read from a preference or recent file. The argument to the flag is a string of the form prefname:value, where prefname is the name of the preference (which is the same name that would appear in the preferences or recent file), and value is the value to which it should be set. Multiple instances of `-o <preference settings> ` can be given on a single command line.

An example of setting a single preference would be:

wireshark -o mgcp.display_dissect_tree:TRUE

An example of setting multiple preferences would be:

wireshark -o mgcp.display_dissect_tree:TRUE -o mgcp.udp.callagent_port:2627

You can get a list of all available preference strings from the preferences file. See Appendix B, Files and Folders for details.

User Accessible Tables can be overridden using “uat,” followed by the UAT file name and a valid record for the file:

wireshark -o "uat:user_dlts:\"User 0 (DLT=147)\",\"http\",\"0\",\"\",\"0\",\"\""

The example above would dissect packets with a libpcap data link type 147 as HTTP, just as if you had configured it in the DLT_USER protocol preferences.

-p, --no-promiscuous-mode

Don’t put the interface into promiscuous mode. Note that the interface might be in promiscuous mode for some other reason. Hence, -p cannot be used to ensure that the only traffic that is captured is traffic sent to or from the machine on which Wireshark is running, broadcast traffic, and multicast traffic to 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.

The criterion is of the form key:path, where key is one of:

persconf:path

Path of personal configuration files, like the preferences files.

persdata:path

Path of personal data files, it’s the folder initially opened. After the initialization, the recent file will keep the folder last used.

-r <infile>, --read-file <infile>

This option provides the name of a capture file for Wireshark to read and display. This capture file can be in one of the formats Wireshark understands.

-R <read (display) filter>, --read-filter <read (display) filter>

This option specifies a display filter to be applied when reading packets from a capture file. The syntax of this filter is that of the display filters discussed in Section 6.3, “Filtering Packets While Viewing”. Packets not matching the filter are discarded.

-s <capture snapshot length>, --snapshot-length <capture snapshot length>

This option specifies the snapshot length to use when capturing packets. Wireshark will only capture snaplen bytes of data for each packet.

-S

This option specifies that Wireshark will display packets as it captures them. This is done by capturing in one process and displaying them in a separate process. This is the same as “Update list of packets in real time” in the “Capture Options” dialog box.

-t <time stamp format>

This option sets the format of packet timestamps that are displayed in the packet list window. The format can be one of:

r

Relative, which specifies timestamps are displayed relative to the first packet captured.

a

Absolute, which specifies that actual times be displayed for all packets.

ad

Absolute with date, which specifies that actual dates and times be displayed for all packets.

adoy

Absolute with YYYY/DOY date, which specifies that actual dates and times be displayed for all packets.

d

Delta, which specifies that timestamps are relative to the previous packet.

dd: Delta, which specifies that timestamps are relative to the previous displayed packet.

e

Epoch, which specifies that timestamps are seconds since epoch (Jan 1, 1970 00:00:00)

u

Absolute, which specifies that actual times be displayed for all packets in UTC.

ud

Absolute with date, which specifies that actual dates and times be displayed for all packets in UTC.

udoy

Absolute with YYYY/DOY date, which specifies that actual dates and times be displayed for all packets in UTC.

-u <s | hms>

Show timesamps as seconds (“s”, the default) or hours, minutes, and seconds (“hms”)

-v, --version

This option requests Wireshark to print out its version information and exit.

-w <savefile>

This option sets the name of the file to be used to save captured packets. This can be '-' for stdout.

-y <capture link type>, --link-type <capture like types>

If a capture is started from the command line with -k, set the data link type to use while capturing packets. The values reported by -L are the values that can be used.

--time-stamp-type <type>

If a capture is started from the command line with -k, set the time stamp type to use while capturing packets. The values reported by --list-time-stamp-types are the values that can be used.

-X <eXtension option>

Specify an option to be passed to a Wireshark/TShark module. The eXtension option is in the form extension_key:value, where extension_key can be:

lua_script:<lua_script_filename>

Tells Wireshark to load the given script in addition to the default Lua scripts.

lua_script[num]:argument

Tells Wireshark to pass the given argument to the lua script identified by num, which is the number indexed order of the lua_script command. For example, if only one script was loaded with -X lua_script:my.lua, then -X lua_script1:foo will pass the string foo to the my.lua script. If two scripts were loaded, such as -X lua_script:my.lua -X lua_script:other.lua in that order, then a -X lua_script2:bar would pass the string bar to the second lua script, ie., other.lua.

read_format:<file_type>

Tells Wireshark to use a specific input file type, instead of determining it automatically.

stdin_descr:<description>

Define a description for the standard input interface, instead of the default: "Standard input".

-Y <display filter>, --display-filter <display filter>

Start with the given display filter.

-z <statistics-string>

Get Wireshark to collect various types of statistics and display the result in a window that updates in semi-real time. For the currently implemented statistics consult the Wireshark manual page.

11.3. Packet colorization

A very useful mechanism available in Wireshark is packet colorization. You can set up Wireshark so that it will colorize packets according to a display filter. This allows you to emphasize the packets you might be interested in.

You can find a lot of coloring rule examples at the Wireshark Wiki Coloring Rules page at https://wiki.wireshark.org/ColoringRules.

There are two types of coloring rules in Wireshark: temporary rules that are only in effect until you quit the program, and permanent rules that are saved in a preference file so that they are available the next time you run Wireshark.

Temporary rules can be added by selecting a packet and pressing the Ctrl key together with one of the number keys. This will create a coloring rule based on the currently selected conversation. It will try to create a conversation filter based on TCP first, then UDP, then IP and at last Ethernet. Temporary filters can also be created by selecting the Colorize with Filter → Color X menu items when right-clicking in the packet detail pane.

To permanently colorize packets, select View → Coloring Rules…​. Wireshark will display the “Coloring Rules” dialog box as shown in Figure 11.1, “The “Coloring Rules” dialog box”.

Figure 11.1. The “Coloring Rules” dialog box

If this is the first time using the Coloring Rules dialog and you’re using the default configuration profile you should see the default rules, shown above.

You can create a new rule by clicking on the + button. You can delete one or more rules by clicking the - button. The “copy” button will duplicate a rule.

You can edit a rule by double-clicking on its name or filter. In Figure 11.1, “The “Coloring Rules” dialog box” the name of the rule “Checksum Errors” is being edited. Clicking on the Foreground and Background buttons will open a color chooser (Figure 11.2, “A color chooser”) for the foreground (text) and background colors respectively.

Figure 11.2. A color chooser

The color chooser appearance depends on your operating system. The macOS color picker is shown. Select the color you desire for the selected packets and click OK.

Figure 11.3, “Using color filters with Wireshark” shows an example of several color filters being used in Wireshark. Note that the frame detail shows that the “Bad TCP” rule was applied, along with the matching filter.

Figure 11.3. Using color filters with Wireshark

11.4. Control Protocol Dissection

The user can control how protocols are dissected.

Each protocol has its own dissector, so dissecting a complete packet will typically involve several dissectors. As Wireshark tries to find the right dissector for each packet (using static “routes” and heuristics “guessing”), it might choose the wrong dissector in your specific case. For example, Wireshark won’t know if you use a common protocol on an uncommon TCP port, e.g., using HTTP on TCP port 800 instead of the standard port 80.

There are two ways to control the relations between protocol dissectors: disable a protocol dissector completely or temporarily divert the way Wireshark calls the dissectors.

11.4.1. The “Enabled Protocols” dialog box

The Enabled Protocols dialog box lets you enable or disable specific protocols. Most protocols are enabled by default. When a protocol is disabled, Wireshark stops processing a packet whenever that protocol is encountered.

To enable or disable protocols select Analyze → Enabled Protocols…​. Wireshark will pop up the “Enabled Protocols” dialog box as shown in Figure 11.4, “The “Enabled Protocols” dialog box”.

Figure 11.4. The “Enabled Protocols” dialog box

To disable or enable a protocol, simply click the checkbox using the mouse. Note that typing a few letters of the protocol name in the search box will limit the list to those protocols that contain these letters.

You can choose from the following actions:

Enable All

Enable all protocols in the list.

Disable All

Disable all protocols in the list.

Invert

Toggle the state of all protocols in the list.

OK

Save and apply the changes and close the dialog box, see Appendix B, Files and Folders for details.

Cancel

Cancel the changes and close the dialog box.

11.4.2. User Specified Decodes

The “Decode As” functionality lets you temporarily divert specific protocol dissections. This might be useful for example, if you do some uncommon experiments on your network.

Decode As is accessed by selecting the Analyze → Decode As…​. Wireshark will pop up the “Decode As” dialog box as shown in Figure 11.5, “The “Decode As” dialog box”.

Figure 11.5. The “Decode As” dialog box

In this dialog you are able to edit entries by means of the edit buttons on the left.

You can also pop up this dialog box from the context menu in the packet list or packet details. It will then contain a new line based on the currently selected packet.

These settings will be lost if you quit Wireshark or change profile unless you save the entries.

+

Add new entry for selected packet

-

Remove the selected entry.

Copy

Copy the selected entry.

Clear

Clear the list of user specified decodes.

OK

Apply the user specified decodes and close the dialog box.

Save

Save and apply the user specified decodes and close the dialog box.

Cancel

Cancel the changes and close the dialog box.

11.5. Preferences

There are a large number of preferences you can set. Simply select the Edit → Preferences…​ (Wireshark → Preferences…​ on macOS) and Wireshark will pop up the Preferences dialog box as shown in Figure 11.6, “The preferences dialog box”, with the “Appearance” page as default. On the left side is a tree where you can select the page to be shown.

The OK button will apply the preferences settings and close the dialog.

The Cancel button will restore all preferences settings to the last saved state.

11.5.1. Appearance

These preferences give you the option to control the makeup of the GUI.

Figure 11.6. The preferences dialog box

Selecting Remember main window size and placement allow for a repeatable experience when restarting Wireshark.

Selecting Open files in allows you to determine where to start the file selection dialog when opening capture files.

The preference Show up to allows you to determine how much history is tracked for display filter entries and recent files shown in the main application window.

Selecting Confirm unsaved capture files causes a dialog to appear when closing a capture file when it was not yet saved. This may help preventing inadvertent loss of data, eg., when Wireshark is closed.

Selecting Display autocompletion for filter text causes a drop down list to appear when you enter a display filter. This drop down list contains known display filters for easy selection.

The preference Main toolbar style allows you to tailor the toolbar style in one of three ways.

The Wireshark main window title is replaced by the name of the opened capture file. The preferences Window title and Prepend window title allow you to add bracketed strings after and before the window title. These window title strings can contain variables which will be replaced by their respective values.

The following variables are available.

%C = Capture comment from command line

%F = File path of the capture file

%P = Currently selected profile name

%S = Conditional separator (dash) that only shows when surrounded by variables with values or static text

%V = Wireshark version info

The Language preference allows you to select the language used in the GUI. Note that the protocol information and details are kept in the language commonly used in this field, that being English.

11.5.2. Columns

These preferences give you the option to control the definition of the columns shown in the packet list, once a capture file is loaded.

Figure 11.7. Column preferences

+

Add new entry to the list.

-

Remove the selected entry.

Selecting Show displayed columns only hides all non-displayed columns from the list, possibly making navigating the list easier.

The rows can be dragged and dropped to arrange them in the desired order.

The columns in the entries are as follows.

Selecting Displayed causes the column to be shown in the packet list.

The Title is the text shown in the header of the column in the packet list.

The Type is the type of value to be shown. This can be a predefined type, ie. a value in a defined format, or custom.

The following settings are applicable when the Type is set to "custom"

The Fields setting is the display filter name of the field to be shown in the column in the packet list.

The Field Occurrence setting is count of the given field in the frame, for fields that appear more than once in a frame.

Selecting Resolved causes name resolution to be applied to the field value, when available.

11.5.3. Font and Colors

These preferences give you the option to select the font and colors used in the various packet panes. Most usable is to select a mono spaced font, which allows for a cleaner presentation, but using a proportional font is possible too.

Figure 11.8. Font and colors preferences

11.5.4. Layout

These preferences allow you to define the layout of the GUI once a capture file is loaded.

Figure 11.9. Layout preferences

Make sure that you have at least one pane configured to contain the Packet list. Three panes can be active at the same time and they can be laid out as shown in the top layer. The exact sizes of these panes can be changed as needed once a capture file is opened.

Selecting Show packet list separator causes the packet list entries to be slightly set apart, which may improve readability at the cost of the amount of packets shown in the packet list.

Selecting Show column definition in column context menu make the column context menu wider to show the currently configured field type for the column. This may help identify the column to select or modify.

Selecting Allow the list to be sorted enables the sort operator on all the columns. This may prevent inadvertently triggering a sort, which may take considerable time for larger capture files.

The Maximum number of cached rows setting determines how much packet list information is cached to speed up sort operations, where a larger number causes more memory to be consumed by the cache. Be aware that changing other dissection settings may invalidate the cache content.

Selecting Enable mouse-over colorization enables the highlighting of the currently pointed to packet in the packet list. The currently selected packet is always highlighted.

Selecting Show selected packet number adds the selected packet number to the capture file details in the status bar, taking up some space in the status bar.

Selecting Show file load time adds the time it took to load the capture file to the status bar, taking up some space in the status bar.

11.5.5. Capture

These preferences allow you to set the default conditions for packet capture.

Figure 11.10. Capture preferences

The default interface is the interface used for packet capture in case no other is selected on the opening page of GUI. Note that this can be multiple interfaces separated by a comma.

Selecting Capture packets in promiscuous mode causes the network interface(s) to capture on to be configured in promiscuous mode. This allows all (Ethernet) frames to be received by the network interface to be capture, not only those that are addressed to the capture interface.

Selecting Capture packets in pcapng format causes the Next-Generation packet capture file format to be used when capturing. This much more capable packet capture file format has many advantages over the original format, although not every external tool may be capable of handling packet captures in this format.

Selecting Update list of packets in real time causes the packet list to fill up and possibly scroll up during the packet capture process. This does give an insight in the packets captured, although it takes processing power to dissect the capture packets.

The preference Interval between updates (ms) allows you to configure how often the packet list is updated during the packet capture process. A higher interval reduces processing, but causes more delay between capture and display in the packet list.

Selecting Don’t load interfaces on startup prevents Wireshark from spawning dumpcap to populate the list of capture interfaces on the local system. This might be a time consuming operation delaying the start of the program, however on most systems this is not an issue. The interface list can always be populated after Wireshark is started via Capture → Refresh Interfaces.

Selecting Disable external capture interfaces prevents Wireshark from spawning extcap programs to list off their capture interfaces. This might be a time consuming operation delaying the start of the program, however on most systems this is not an issue.

11.5.6. Expert Items

These preferences allow you to modify the severity set for expert items.

Figure 11.11. Expert item preferences

If, for whatever reason, you find that the severity for certain expert items does not match your needs you can change them here and have them used as such, showing up in the appropriate lists and overviews. Get the Field name from selecting the field in the packet details pane, then observe the name shown in the status bar. This is the name you enter on a new line in the list, while setting the desired Severity in the next column.

+

Add new entry to the list.

-

Remove the selected entry.

Copy

Copy the selected entry.

⌃

Move the selected entry up in the list.

⌄

Move the selected entry down in the list.

Clear

Clear the list of user specified expert item severities.

Copy from

Copy the list of user specified expert item severities from another profile.

11.5.7. Filter Buttons

Having quick access to regularly used display filter expressions can be a real productivity boost. Here you can define your own display filter buttons.

Figure 11.12. Filter buttons

+

Add new entry to the list.

-

Remove the selected entry.

Copy

Copy the selected entry.

⌃

Move the selected entry up in the list.

⌄

Move the selected entry down in the list.

Clear

Clear the list of user specified display filter buttons.

Copy from

Copy the list of user specified display filter buttons from another profile.

The columns in the entries are as follows.

Selecting Show in toolbar causes the button to be shown in the toolbar besides the display filter text entry.

The Button Label is the text shown on the button in the toolbar. The use of a double slash causes the button to create a dropdown list to allow grouping of multiple buttons, e.g. TCP//Syn and TCP//Res.

The Filter Expression is the display filter expression entered into the display filter text entry when the button is clicked.

The Comment is the comment text which appears in a bubble when the mouse hovers over the button.

11.5.8. Name Resolution

These preferences allow you to configure which numeric identifiers in protocols are translated into human readable text. For some of these identifiers the readable texts are read from configurable external sources.

Figure 11.13. Name resolution preferences

Selecting Resolve MAC addresses causes the OUI (Organizationally Unique Identifier) at the start of an Ethernet address to be translated into the name registered with the IEEE for that OUI.

Selecting Resolve transport names causes the UDP and TCP port numbers to be translated into the service registered to these ports by IANA.

Selecting Resolve network (IP) addresses causes IPv4, IPv6 and IPX addresses to be translated into their corresponding host name. To do this Wireshark reaches out to DNS servers to request names for addresses it finds in packets. There are several way to do this, which can be controlled through the following preferences.

Selecting Use captured DNS packet data for name resolution causes DNS response packets in the capture file to fill the network address resolution table. These can then be used to resolve addresses found in the packets.

Selecting Use your system’s DNS settings for name resolution causes DNS requests to be made as would be for other network applications.

Selecting Use a custom list of DNS servers for name resolution causes DNS requests to be made to manually configured DNS servers.

The DNS Servers Edit…​ button provides access to the dialog to manage these manually configured DNS servers.

The Maximum concurrent requests input field allows you to limit the amount of DNS queries made at the same time.

Selecting Resolve VLAN IDs causes the file "vlans" to be read and used to name VLANs. This file has the simple format of one line per VLAN, starting wit VLAN ID, a tab character, followed by the name of the VLAN.

Selecting Resolve SS7 PCs causes the file "ss7pcs" to be read and used to name SS7 Point Codes. This file has the simple format of one line per Point Code, starting with Network Indicator, a dash, the Point Code in decimal, a tab character, followed by the name of the Point Code.

Selecting Enable OID resolution causes the SMI library to be initialized. This library is capable of loading MIB/PIB files to provide name resolution for SMI objects, as present in SNMP packets.

Selecting Suppress SMI errors prevents the SMI library from emitting error messages while loading MIB/PIB files. The SMI library is very sensitive to irregularities in these files often resulting in harmless error being emitted.

The SMI (MIB and PIB) paths Edit…​ button provides access to the dialog to manage the directories where the MIB/PIB files to be loaded can be found.

The SMI (MIB and PIB) modules Edit…​ button provides access to the dialog to manage the MIB/PIB modules to be loaded.

Selecting Enable IP geolocation causes the background MaxMind database IP geolocation resolver to be used to attempt to geolocate IP addresses in the packets.

The MaxMind database directories Edit…​ button provides access to the dialog to manage the directories where the MaxMind database files can be found. See Section 11.9, “MaxMind Database Paths”.

11.5.9. Protocols

Wireshark supports quite a few protocols, which is reflected in the long list of child entries of the “Protocols” pane. You can jump to the preferences for a specific protocol by expanding “Protocols” and typing the first few letters of the protocol name.

Figure 11.14. Protocol preferences

There are a few general protocol related preferences, listed below.

Selecting Display hidden protocol items influences what is shown in the packet details pane of the packet selected from the packet list. Some protocol dissectors add hidden protocol items that provide additional interpretations of the packet data, or with different display filter strings. These may or may not provide valuable information to the user and may clutter the output, therefor these items can be hidden.

Selecting Display byte fields with a space character between bytes influences the way a byte field in shown in the packet details pane of the packet selected in the packet list, if the dissector creates a byte field that is. The bytes in the byte field are normally shown as a concatenated sequence of hexadecimals. This preference allows you to get the representation of each byte separated by a space. This may improve readability of the individual bytes in the byte field.

Selecting Look for incomplete dissectors causes expert items to be added to the dissection of packet data for which the dissector does not create an interpretation. Dissectors should strive to not skip packet bytes and this preference allows you to be made aware of this.

Selecting Enable stricter conversation tracking heuristics allows dissectors to take more identifiers into consideration when creating "conversations". These are used to track related packets. The heuristics for these conversations are sensitive to mis-identification of packets, possibly corrupting conversation analysis. Adding more identifiers can reduce the change of this happening. Currently only the IPv4, ICMP and ICMPv6 dissector use this preference.

Selecting Ignore duplicate frames causes a duplicate frame to appear in the packet list, but flagged as ignored, hence not dissected. The determination of a duplicate frame is made based on the SHA256 hash of the bytes in the frame.

The preference Deinterlacing conversations key gives you options for deinterlacing the conversations. While NONE keeps the historical behaviour, the other options are built on three keys with the following meanings: V (VLAN), M (Mac Address), I (Interface). Packets which seem identical because they have the same payload but have a different value for their VLAN Tag, a MAC Address, or were captured on different interfaces, will then be part of different conversations if the respective deinterlacing key is activated.

The preference The max number of hashes to keep in memory for determining duplicate frames allows you to set how large the set of frames to consider for duplication is.

11.5.10. RSA Keys

For more information see https://wiki.wireshark.org/TLS.

Figure 11.15. RSA keys

11.5.11. Statistics

These preference have influence on the Statistics Tree (stats_tree) based dialogs accessible via the Statistics menu.

Figure 11.16. Statistics preferences

The preference Tap update interval in ms allows you to set how quickly protocol taps are being updated, partially determining the update speed of various dialogs and graphs.

Selecting Enable the calculation of burst information allows the Statistics Tree system to calculate burst information.

Selecting Show burst count for item rather than rate allows the statistics nodes to show the count of events within the burst window instead of a burst rate. Burst rate is calculated as number of events within burst window divided by the burst window length.

The preference Burst rate resolution (ms) sets the duration of the time interval into which events are grouped when calculating the burst rate. Setting a higher resolution (ie., a smaller number) increases processing overhead.

The preference Burst rate window size (ms) sets the duration of the sliding window during which the burst rate is measured. Longer window relative to burst rate resolution increases processing overhead. This value will be truncated to a multiple of the Burst rate resolution preference setting.

The preference Default sort column for stats_tree stats gives you to option to select one of the columns to sort on.

Selecting Default stats_tree sort order is descending causes a descending sort order based on the previously selected column.

Selecting Case sensitive sort of stats_tree item names causes a case sensitive sort based on the previous selected order and column.

Selecting Always sort 'range' nodes by name causes the sort to take place by name rather than values.

Selecting Always sort 'range' nodes in ascending order makes an exception for range nodes to the previously selected sort order.

Selecting Display the full stats_tree plug-in name causes the full menu path of the Statistics Tree plugin to be shown in the title.

11.5.12. Advanced

The “Advanced” pane will let you view and edit all of Wireshark’s preferences, similar to about:config and chrome:flags in the Firefox and Chrome web browsers.

Figure 11.17. Advanced preferences

You can search for a preference by typing text into the “Search” entry. You can also pass preference names to Wireshark and TShark on the command line. For example, the gui.prepend_window_title can be used to differentiate between different instances of Wireshark on your screen:

$ wireshark -o "gui.prepend_window_title:LAN" & $ wireshark -o "gui.prepend_window_title:External Network" &

11.6. Configuration Profiles

Configuration Profiles can be used to configure and use more than one set of preferences and configurations. Select the Edit → Configuration Profiles…​ menu item or press Shift+Ctrl+A or Shift+Cmd+A (macOS) and Wireshark will pop up the Configuration Profiles dialog box as shown in Figure 11.18, “The configuration profiles dialog box”. It is also possible to click in the “Profile” part of the statusbar to popup a menu with available Configuration Profiles (Figure 3.23, “The Statusbar with a configuration profile menu”).

Configuration files stored in each profile include:

Preferences (preferences) (Section 11.5, “Preferences”)

Capture Filters (cfilters) (Section 6.6, “Defining And Saving Filters”)

Display Filters (dfilters) (Section 6.6, “Defining And Saving Filters”)

Display Filter Macros (dmacros) (Section 6.7, “Defining And Saving Filter Macros”)

Coloring Rules (colorfilters) (Section 11.3, “Packet colorization”)

Disabled Protocols (disabled_protos) (Section 11.4.1, “The “Enabled Protocols” dialog box”)

Most User Accessible Tables (Section 11.7, “User Accessible Tables”)

Changed dissector assignments (decode_as_entries), which can be set in the “Decode As…​” dialog box (Section 11.4.2, “User Specified Decodes”).

Some recent settings (recent), such as pane sizes in the Main window (Section 3.3, “The Main window”), column widths in the packet list (Section 3.18, “The “Packet List” Pane”), all selections in the View menu (Section 3.7, “The “View” Menu”) and the last directory navigated to in the “File Open” dialog.

All other configurations are stored in the personal configuration folder and are common to all profiles.

Figure 11.18. The configuration profiles dialog box

Search for profile …​

The list of profiles can be filtered by entering part of the profile’s name into the search box.

Type selection

Profiles can be filtered between displaying "All profiles", "Personal profiles" and "Global profiles"

Personal profiles - these are profiles stored in the user’s configuration directory

Global profiles - these are profiles provided with Wireshark

New (+)

Create a new profile. The name of the created profile is “New profile” and is highlighted so that you can more easily change it.

Delete (-)

Deletes the selected profile. This includes all configuration files used in this profile. Multiple profiles can be selected and deleted at the same time. It is not possible to delete the “Default” profile or global profiles. Deletion of the "Default" profile will reset this profile.

Copy

Copies the selected profile. This copies the configuration of the profile currently selected in the list. The name of the created profile is the same as the copied profile, with the text “(copy)” and is highlighted so that you can more easily change it.

Auto switch packet limit

The number of packets to check for automatic profile switching, described below. Setting this to zero disables automatic profile switching.

Import

Profiles can be imported from zip-archives as well as directly from directory structures. Profiles, which already exist by name will be skipped, as well as profiles named "Default".

Export

Profiles can be exported to a zip-archive. Global profiles, as well as the default profile will be skipped during export. Profiles can be selected in the list individually and only the selected profiles will be exported

OK

This button saves all changes, applies the selected profile and closes the dialog.

Cancel

Close this dialog. This will discard unsaved settings, new profiles will not be added and deleted profiles will not be deleted.

Help

Show this help page.

11.6.1. Automatic Profile Switching

You can configure Wireshark to automatically change configuration profiles by adding a display filter to the "Auto Switch Filter" setting for a profile. When you open a capture file, Wireshark will check each filter against a limited number of packets and will switch to the first profile with a matching filter. The number of packets is determined by the "Auto switch packet limit" setting, and a limit of 0 will disable this feature. Manually changing your profile will disable this behavior until you open a different capture file.

11.7. User Accessible Tables

User Accessible Tables are a type of preference table which may be associated with particular protocols or with the application as a whole.

User Accessible Tables have a common editor dialog which works as described in Section 11.5.6, “Expert Items” and Section 11.5.7, “Filter Buttons”. Note that the name of the file appears in the lower right corner of the dialog.

The files are saved in a CSV format, where values are either double quoted ASCII strings (using C-style backslash escapes for non-printable characters) or unquoted hexstrings, depending on the field type. They can be edited directly when Wireshark is not running, though this is discouraged. Entries can also be appended to the table by passing an appropriate CSV formatted record string on the command line.

Most UATs are stored in the configuration profile:

Custom HTTP headers (custom_http_header_fields)

Custom IMF headers (imf_header_fields)

Custom LDAP AttributeValue types (custom_ldap_attribute_types)

Display Filter Buttons (dfilter_buttons)

Display Filter Macros (dfilter_macros), prior to Wireshark 4.4

DNS Servers (addr_resolve_dns_servers)

ESS Category Attributes (ess_category_attributes)

Expert Item Severity (expert_severity)

IEEE 802.11 WLAN Decryption Keys (80211_keys)

IKEv2 decryption table (ikev2_decryption_table)

I/O Graphs (io_graphs)

K12 Protocols (k12_protos)

Object Identifier Names and Associated Syntaxes ()

Packet Lengths (packet_lengths)

PRES Users Context List (pres_context_list)

SCCP Users Table (sccp_users)

SNMP Enterprise Specific Trap Types (snmp_specific_traps)

SNMP Users (snmp_users)

User DLTs Table (user_dlts)

Protobuf Search Paths (protobuf_search_paths)

Protobuf UDP Message Types (protobuf_udp_message_types)

Other UATs are stored in the personal configuration directory and are common to all profiles:

11.8. ESS Category Attributes

Wireshark uses this table to map ESS Security Category attributes to textual representations. The values to put in this table are usually found in an XML SPIF, which is used for defining security labels.

This table is a user table, as described in Section 11.7, “User Accessible Tables”, with the following fields:

Tag Set

An Object Identifier representing the Category Tag Set.

Value

The value (Label And Cert Value) representing the Category.

Name

The textual representation for the value.

11.9. MaxMind Database Paths

If your copy of Wireshark supports MaxMind’s MaxMindDB library, you can use their d