Wireshark filtering techniques: Syntax, expressions, operators and common troubleshooting

1. Preface

Wireshark is a powerful network protocol analysis tool capable of capturing and analyzing packets in a network. This article will provide a detailed introduction on how to use Wireshark’s precise filtering rules to help users accurately extract the required packets from a vast amount of data, thereby conducting network troubleshooting and security analysis more effectively.

The article is composed of two main parts. The first part introduces techniques for filtering fields in Wireshark, while the second part focuses on case analyses in various application scenarios. Wireshark supports over 3,000 protocols and more than 240,000 filter fields. Therefore, it’s impossible for this article to cover each one, but the filtering methods are consistent: filter what needs to be filtered.

Readers are strongly encouraged to consult the official documentation guide for a more comprehensive understanding of Wireshark, as no tutorial manual can surpass the level of detail and accuracy found there.

file name	Document Links
wireshark-filter(4) Manual Page	https://www.wireshark.org/docs/man-pages/wireshark-filter.html
Wireshark User’s Guide	https://www.wireshark.org/docs/wsug_html_chunked/
Document download page	https://www.wireshark.org/download/docs/

At the same time, the filter commands you use in Wireshark can also be used in Tshark. Tshark is an official component produced by Wireshark and can be understood as the CLI version of Wireshark. Both Wireshark and Tshark are tools based on the libpcap library, sharing the same filtering syntax known as pcap-filter. For usage examples of Tshark, you can refer to the author’s.

2. Filtering Techniques, Operators, and Expressions

2.1 Any field can be used as a filter condition

2.1.1 Mouse Drag to Filter Any Field

After expanding the message, any field you click on with your mouse can be used as a filter condition. For instance, if you click on the “Sequence Number” field, the corresponding field filter syntax will be displayed in the bottom left corner.

You don’t even need to manually type this filter condition; simply drag it to the top filter box using your mouse:

The same applies to all other fields.

2.1.2 View and Search Filter Fields

In View –> Internals –> Supported Protocols, you can see all the protocols that are supported. Type the field you want to search for in the search box:

All matching protocol fields will be displayed, and even protocol subfields that match the search content will be shown. For example, when searching for “dns,” do not press enter; wait a few seconds, and the results will appear:

Typically, when troubleshooting through protocol analysis, it is first necessary to understand the normal interaction behavior of the protocol and the function of each message field. Only then can one further filter out abnormal interaction requests and response messages.

2.2 Logical Operators

The basic operations of “and,” “or,” and “not” are not elaborated here; you can refer to the examples in the table above. This section mainly discusses the three operators: exclusive or (xor), subsequence, and set.

2.2.1 Exclusive Or (xor)

This is true only when one condition is satisfied, and the two conditions cannot be satisfied simultaneously. This filters out the corresponding packets.

For example, the following expression:

Selects packets with an IP address of 192.168.1.1, or packets with ip.addr as 10.10.0.100, but not both conditions simultaneously. That is, interactions between 192.168.1.1 and 10.10.0.100 will not be matched, but interactions between them and other IPs can be matched normally.

2.2.2 Subsequence (…)

Similar to the usage of arrays or slicing in Python.

For example, this example filters HTTP request methods where the first three characters are “GET”:

Or specifies that the first three digits of the source MAC address can be:

2.2.3 Set (in)

As long as the elements within the set are matched, all can be filtered.

Multiple IP addresses can be selected at the same time:

Combining this with the “and” logical operator, only SYN requests can be filtered:

Similarly, if you want to simultaneously filter packets for multiple ports and TCP streams where there is no received SYN-ACK second handshake packet from the peer, you can:

It can be seen that only ports 443 and 8080 meet the filtering criteria. The tested peer server did not listen on these two ports, so it responded with RST-ACK.

Sets can also be used for continuous ranges, such as filtering port 443 and ports 4430~4434:

Or an IP address range:

Operators	C-style	describe	Example
and	&&	Logical AND	ip.src==10.0.0.5 and tcp.flags.fin==1
or	||	Logical OR	ip.src==10.0.0.5 or ip.src==192.1.1.1
xor	^^	Logical XOR	tr.dst0:3 == 0.6.29 xor tr.src0:3 == 0.6.29
not	!	Logical NOT	! udp
…	Not involved	Subsequence/Slice Operators	eth.src:4 == 00:00:83:00
in	Not involved	Set the members of the collection	http.request.method in {“HEAD”, “GET”}

We’ll skip over the three basic operations: AND, OR, and NOT, as they can be referenced from the examples in the table above. Instead, we’ll focus on three operators: XOR, subsequence, and set.

2.2.1 XOR (exclusive or)

It is true if and only if one condition is met but the two conditions cannot be satisfied simultaneously, filtering out the corresponding packets.

For example, consider the following expression:

Filter packets with the IP address 192.168.1.1, or packets where ip.addr is 10.10.0.100, but both conditions cannot be met simultaneously. In other words, interaction requests between 192.168.1.1 and 10.10.0.100 will not be matched, but interactions between those two and other IPs can be matched normally.

2.2.2 Subsequence (…)

This is similar to the usage of arrays or slicing in Python.

For example, the following example filters HTTP request methods where the first three characters are “GET”:

Or you can specify that the first three bytes of the source MAC address can be:

Similar to the usage of arrays or the slicing method in Python.

For example, in the following example, filter HTTP request methods where the first three characters of the packet are GET:

Or you may specify that the first three bytes of the source MAC address can be:

2.2.3 Sets (in)

In the context of filtering conditions, as long as the elements within the set match, they all pass the filter.

For example, if filtering multiple IP addresses at once, one can do so like this:

Combine this with the ‘and’ logical operator to filter only SYN requests:

Similarly, to filter packets on multiple ports at once, and ensure the TCP stream does not receive the second handshake packet (SYN-ACK), it can be done like this:

Only ports 443 and 8080 meet the criteria; the tested server does not listen on these ports, hence it responded with RST-ACK.

The use of sets can also be continuous, like filtering for port 443 and ports 4430 through 4434:

Or for a range of IP addresses:

Based on the filtering conditions, as long as the elements within the set meet the criteria, they all match.

Multiple IP addresses can be filtered simultaneously, such as:

Combine with the above ‘and’ logical operator to filter only SYN requests:

Similarly, if you want to filter packets from multiple ports at once and have not captured the SYN-ACK handshake packet from the remote in the TCP stream, you can do so by:

It can be seen that only ports 443 and 8080 met the filtering criteria. The tested remote server did not have these ports open, hence it responded with RST-ACK.

The use of sets can also be continuous, for example, filtering port 443 and ports 4430~4434:

Or IP address range:

Comparative Operators

Operators	Aliases	C-style	describe	Example
eq	any_eq	==	equal	ip.src == 10.0.0.5
ne	all_ne	!=	Not equal to	ip.src != 10.0.0.5
	all_eq	===	congruent	ip.src === 10.0.0.5
	any_ne	!==	Not all equal	ip.src !== 10.0.0.5
gt		>	Greater than	frame.len > 10
lt		<	Less than	frame.len < 128
ge		>=	Greater than or equal to	frame.len ge 0x100
le		<=	Less than or equal to	frame.len <= 0x20
contains			A protocol, field, or slice contains a value	sip.To contains “a1762”
matches		~	Use Perl regular expressions (PCRE) to match a protocol or text field	http.host matches “acme\.(org|com|net)”

The basic operators mentioned earlier, such as equals, not equals, greater than, less than, greater than or equal to, and less than or equal to, will not be introduced one by one. Instead, we’ll introduce some less common yet very useful operators.

2.3.1 Identity (===)

Difference between equality (==) and strict equality (===):

For example, consider the following example, which filters requests with a TCP port number of 80:

For the same packet, using “equal to” (==) can filter packets with either the source or destination port of 80, while using “strictly equal to” (===) will match packets where both the source and destination ports are 80.

Due to the source and destination ports, the above filtering conditions, once written, all belong to the fields that need to be verified by tcp.port, and are matched and screened according to their respective leniency.

Take the following example, where the source and destination IP must be filtered to be within the 10.0.0.0/8 subnet:

The equivalent statement mentioned above restricts both the source and destination IP addresses to the 10.x.x.x segment, equivalent to:

2.3.2 Inequality (!==)

As the name implies, taking the example of filtering port numbers again, if there is a “not equal to” condition in the filtering field, then the condition is met.

For example, the following filter condition:

When comparing equality (==), the condition of inequality (!=) excludes scenarios where both the source and destination ports are 80. At the frame level, either the source or destination port can be 80, but not both.

2.3.3 Contains

When you need to filter whether a field contains a specified string, you can use contains.

For example, in a TCP connection, to filter requests containing the string “image,” the filtering method could be:

Of course, you can replace tcp with any protocol or field you want, such as: udp contains, frame contains, http contains, provided the data type is a string, so tcp.port, ip.addr cannot use contains.

For example, to filter HTTP requests with the hostname host as youtube.com, you could use:

To filter DNS query requests containing cloud.tencent.com, you could use:

Or directly filter the Payload data, such as in a UDP protocol probe initiated by nping, sending a test string “test”:

The server listens on UDP port 2115 and echoes back whatever it receives:

Both of the following statements can successfully filter the payload containing test:

When you need to filter whether a field contains a specified string, you can use contains.

For example, in a TCP connection, the filtering method for requests containing the string “image” can be:

Of course, you can replace tcp with any protocol or field you like, such as udp contains, frame contains, or http contains, provided that the data type is a string. Therefore, tcp.port and ip.addr cannot be used with contains.

For example, a filter for HTTP requests where the host name is youtube.com can be:

To filter DNS query requests containing cloud.tencent.com:

Alternatively, you could directly filter the Payload data. For example, nping initiates a UDP protocol probe and sends a test string “test”:

The server listens on UDP port 2115 and echoes whatever it receives:

Both of the following statements can successfully filter payloads containing “test”:

2.3.4 Matches

Matching patterns with support for Perl Regular Expressions (PCRE) allows for flexibility in matching a protocol or text field, offering more versatility than using “contains”.

For instance, to filter request URIs that contain the string “msf” in .com websites, you would use:

To filter domain names in the Client Hello phase of a TLS handshake that start with the letter ‘v’ and end with “microsoft.com”, you would write:

To filter DNS protocol packets matching any of these three websites, you could use:

Additionally, you can bring up the search box using keyboard shortcuts, supporting regular expressions, hexadecimal, strings, and filters. You can also set case sensitivity. Note that searching will not filter packets; each time you click search, it will sequentially highlight a frame that meets the criteria from top to bottom.

Matching pattern, supports Perl regular expressions (PCRE) to match a protocol or text field, offering more flexibility than contains.

Filter .com websites with request URIs containing the msf string:

Filter the domain names in the client hello phase of the TLS handshake, where the message must start with the letter ‘v’ and end with ‘microsoft.com’:

, in the DNS protocol, filter packets that match three websites:

You can use shortcuts to bring up the search box, which supports regular expressions, hexadecimal, strings, and filters. You can also set whether the search is case-sensitive. The search will not filter messages for you. Each time you click find, it will locate a matching data frame from top to bottom in order.

2.4 Hierarchical Operators (Multi-level Filtering in Tunnel Encapsulation Scenarios)

The hierarchical operator () followed by a decimal number can restrict the field to a particular layer in the protocol stack.

2.4.1 VXLAN Scenario

For example, in a VXLAN encapsulated packet, an inner IP header is encapsulated within a UDP header, along with the packet’s own outer IP header, resulting in two levels:

To filter by the inner layer (second layer) IP, you can use the layering operator #2. For instance, to filter packets where the inner layer IP is 10.120.9.130 and the TCP destination port is 51801, you could write:

On the other hand, if you wish to filter by the first layer source IP, you can either use the default ip.src or add #1. Combining this with the strict equality operator we discussed above, requiring that the outer layer source and destination must both belong to the 10.x.x.x network, could look like this:

For example, consider this VXLAN packet. It encapsulates the inner IP header using UDP, in addition to the IP header that comes with the packet itself, resulting in two layers: inner and outer.

Currently, to filter the IP of the inner layer (second layer), you can add the layer operator #2. For instance, to filter packets with an inner layer IP of 10.120.9.130 and TCP destination port 51801, you can write it like this:

If you want to filter by the first layer source IP, the default is to use ip.src or you can add #1, and then combine with the aforementioned equality operator. To require that the outer layer source and destination are both within the 10 network segment, you can use:

2.4.2 GRE Scenario

The encapsulation of GRE is similar. For example, in the packet below, GRE has encapsulated an IP header, in addition to the IP header that the original packet carries, resulting in two layers in the private network:

Using the previously mentioned match operator (~) and identical operator (===), to filter the outer source and destination IP that starts with the 10 or 11 subnet, while both the outer source and destination IP are in the 10 subnet, the syntax can be:

Here, the data type of the outer ip.addr is converted to a string using the string() function, and then a match operator is used to match a regular expression.

IPIP Scenario

IPIP operates similarly, dividing into inner and outer IP headers, structured as follows:

To filter packets encapsulated in IPIP in Wireshark, use the following syntax:

The filtering syntax indicates that IPIP encapsulation (IP Encapsulation within IP) lies within protocol number 4. You can refer to the protocol’s numerical sequence for verification. After filtering the IPIP packets, you can proceed to filter packets according to the specific layers of the IP headers.

For instance, to filter packets where the inner IP header contains 10.0.0.2 and is a DNS A record query request, you can use:

IPIP is similar, with an inner and outer IP header, structured as follows:

First, to filter out IPIP encapsulated packets in Wireshark, you can use the following syntax:

From the filtering syntax, it is not difficult to see that IPIP encapsulation (IP Encapsulation within IP) corresponds to protocol number 4. You can refer to the numerical sequence corresponding to the protocol. Once IPIP packets are filtered, you can subsequently filter packets that meet your requirements based on different levels of IP headers.

To filter requests with an inner IP header containing 10.0.0.2 and querying for DNS A records, you can use:

2.5 Conversion Function Filters

Wireshark supports many types of conversion functions, refer to the table:

function	describe
upper	Convert string fields to uppercase
lower	Convert string fields to lowercase
len	Returns the length in bytes of a string or byte field
count	Returns the number of occurrences of a field in a frame
string	Convert non-string fields to strings
vals	Convert the field value to its value string (if any)
dec	Convert an unsigned integer field to a decimal string
hex	Convert an unsigned integer field to a hexadecimal string
max	Returns the maximum value of the parameter
min	Returns the minimum value of the parameters
abs	Returns the absolute value of the argument

The aforementioned functions will not be exemplified one by one, but we will discuss a few of the more commonly used functions.

The upper()/lower() functions can be used to convert a string to uppercase or lowercase, respectively, and then perform a regex match, enabling case-insensitive functionality.

For example, to filter HTTP response headers where the server field is “apache,” you can use:

To filter HTTP request methods such as POST or GET:

These two functions can be used to convert strings to uppercase or lowercase, allowing for case-insensitive regular expression matching.

For example, to filter HTTP response headers where the server field is Apache, you can use:

Filter HTTP requests by method POST or GET:

2.5.2 len() function

The len() function will return the byte size of a field, so it can be used with comparison operators to filter packets with a field that meets specified size requirements.

Filtering the URI field in the HTTP header, messages that are 10 bytes or more can be:

Filter HTTP messages with hostnames greater than or equal to 20 bytes:

2.5.3 string() function

When fields are non-string types and need to be converted to string fields for regex matching, the string() function comes in handy.

For example, to filter IPs starting with the 10 network segment or the 23 network segment, you can use:

Filter odd frames, i.e., frames ending in 1/3/5/7/9:

Similarly, packets with odd original sequence numbers and a SYN flag can be filtered as:

Match IP addresses that end with 255 in the destination IP (from 172.16 to 172.31):

2.5.4 max(), min() functions

The functions max() and min() accept an arbitrary number of parameters of the same type and return the largest/smallest parameter in the set, respectively.

Filter TCP source port, destination port, with a maximum packet size not exceeding 1024:

Filter packets where the sum of TCP source port and destination port is greater than or equal to 1024:

Field Referencing/Dynamic Filtering

2.6.1 Single Variable Reference

An expression in the form is called a field reference. Its value is read from the corresponding field in the currently selected frame with the mouse. This is a way to construct.

For example, in the case below, I first used a filter statement to filter out a large number of DNS packets, and at this point, I used my mouse to select the first frame:

The DNS response returned in the first frame is the resolution record: the IP address 10.85.15.101.

After completing the above action, Wireshark has actually assigned a reference to the above IP. Now let’s reference it to filter HTTP requests, with the destination IP being the field value we just selected with the mouse:

It can be seen that the HTTP requests meeting the criteria have been filtered.

At this point, let’s press Enter again:

You will find that this time it returns empty because the reference is cleared after one use. If you wish to continue referencing, you must use the statement and mouse to reselect the frame.

Multi-variable References

The above method of writing is similar to the way variables are written in bash. By extending it, you can also refer to multiple variables at once, such as using two filter fields simultaneously:

At this time, we click a frame with the mouse.

Proceed with variable referencing and only filter HTTP:

We successfully obtained the data we wanted.

Search Filter Protocols and Fields

Clicking on → allows you to enter the filter expression page, where you can search for any protocol or field you desire. Once you find the expression you need, Wireshark will automatically complete the full syntax for you.

For example, searching for will display all textual matches for the protocol or field dns.a:

Then, select the first option, dns.a, and in the upper right corner, you can choose a relational operator:

Next, input the IP value for the field you want to filter in the Value section:

After clicking OK and pressing Enter, this filter expression will be applied:

The method is the same for filtering any other protocol or field.

Click –> to access the filter expression page, where you can search for any protocol or field you want, and select the expression you need with your mouse. Wireshark will help you write the complete statement.

For example, in a search, all protocols or fields that fully match dns.a will be displayed:

At this point, we select the first one, i.e., dns.a, and at the top right, we can choose the relational operator:

Immediately after this, in the Value section, enter the IP address of the field value you want to filter:

After clicking OK and pressing Enter, this filter statement will be applied:

Other protocols or field filtering methods work similarly.

Add Filter Statements as Buttons

For example, if you want to filter the SYN packet of the first TCP handshake and you use this feature frequently, you can add this filter statement as a button. This makes it convenient to apply the statement with a single mouse click next time, without having to manually enter it each time. This is especially helpful for longer or more complex statements.

First, confirm that the filter expression for capturing the SYN packet corresponding to the first TCP handshake is:

Following this, add the custom filter button in the sequence shown in the diagram:

After clicking OK, you can see an additional custom label button on the right::

Every time you click it, Wireshark automatically applies the filter expression we defined.

2.9 Apply Any Field as a Column

For example, in an ICMP scenario, you’d like to clearly display the ping response time for each packet as soon as you open the packet.

First, you need to find the ICMP response time field. Expand the ICMP Reply packet and locate the Response time field:

Right-click on this field, then right-click it again –> Apply as Column:

Afterward, you can see an additional column on the far right of the packet: Response time. We drag it to a prominent position in the middle so that each ICMP Reply response packet shows its respective time delay:

Here, no further examples will be given. Any protocol’s field can be used as a column using this method, allowing Wireshark to present the key fields we want to focus on more intuitively.

2.10 Change relative seq to original seq

The original sequence number (field: tcp.seq_raw), also known as the absolute sequence number, is typically represented in Wireshark using relative sequence numbers for each TCP stream by default (for instance, the sequence number of the first handshake SYN starts at 0). However, during actual interactions, the seq sequence numbers are the original sequence numbers and do not start from 0. Therefore, using relative sequence numbers does not facilitate point-to-point, end-to-end, or full-link analysis for the same TCP stream.

At this point, you can go to Edit → Preferences → Protocols → TCP page, and uncheck the Relative sequence numbers box:

After clicking apply, you can see that the displayed sequences are all original sequences. Subsequent convection analysis can be filtered and matched through the original sequences.

2.11 Arrow Symbols in Wireshark

Wireshark uses arrow symbols on the far left of the frame to mark request frames (→) and response frames (←):

This is particularly useful for packets where the frame length is too large and gets truncated, making it difficult to see which is a request or response frame. For example, in the following illustration:

Without looking at the arrow symbols, it’s not easy to see at a glance which frame is the HTTP request. However, Wireshark marks it by default. The 4th frame is the request, and the 11th frame is the response, providing that the request and response frames are selected with the mouse; only then will Wireshark completely mark the request and response frames.

This is also true for DNS and ICMP. For example, if you select a DNS query with the mouse, Wireshark will simultaneously use arrow symbols to mark the response corresponding to the selected query.

Wireshark will mark request frames (→) and response frames (←) with arrow symbols on the far left of the frame.

对于帧长度太大导致被截断的报文，看不出哪个是请求或响应帧特别有用，比如下面的示例：

Without looking at the arrow symbols, it’s not easy to visually determine which frame is the HTTP request. However, Wireshark marks it by default: frame 4 is the request and frame 11 is the response. The prerequisite is that the mouse must select the request and response frames for Wireshark to completely mark out the request and response frames.

DNS and ICMP follow the same principle. For instance, when you select a DNS query with your mouse in Wireshark, it will simultaneously mark both the selected query and its corresponding response with arrow symbols.

3. Filtering Methods for Common Application Scenarios

3.1 Filtering HTTP/HTTPS/TLS Request Domain Names

Use the following filter statement to screen the request HOST of HTTP requests and the requested host name during the client hello phase of the TLS handshake:

The HTTP request domains are displayed in the http.host field, and the TLS/HTTPS request domains are shown in the SNI extension field during the client hello phase. Therefore, as shown in the diagram above, you can use these two fields as columns to more clearly see the request domains carried by the HTTP/HTTPS/TLS packets.

Filter HTTP Status Codes or Status Code Range

We are particularly interested in knowing about HTTP response 4xx and 5xx status codes, here’s how to do it:

First, use a function to convert the HTTP status code field to a string type, then use a PCRE regex to match 4xx and 5xx status codes.

If you only want to limit the search to a few specific status codes, it’s even simpler:

If you want to filter status codes from HTTPS/TLS encrypted messages, this method will not work because the data is already encrypted and no plain text fields can be seen after the tls handshake. Unless you decrypt it to filter the corresponding field, you can refer to the decryption method.

3.3 Filtering TCP SYN Packets with Handshake Failures

Filtering requests that failed the first handshake and did not receive a SYN-ACK response can be:

The explanation for whether the flag bit used for filtering covers syn-ack packets, similar for other flag bits, is as follows:

You can see the complete packet below, all connections were actually rejected with RST-ACK because the destination server port was not listening.

If we simply and crudely filter packets where syn is 1 and ack is 0:

This logic is solely frame-based: any packet with the SYN flag set to 1 and the ACK flag set to 0 will be displayed. There is no concept of a TCP stream or TCP session. Some scenarios may still filter correctly, but using a more precise expression is recommended for better accuracy in meeting the requirements.

3.4 Filtering Packets with Timeout/Loss Retransmissions

The packets filtered for TCP timeouts or packet retransmissions can be:

You can also add an additional condition to filter TCP retransmissions with a time difference of greater than or equal to 0.2 seconds:

3.5 Sorting Frames by Interval Time in the Same TCP Stream

First, select any TCP frame and locate the timestamp field. Right-click on the “Time since previous frame in this TCP stream” field (meaning the time relative to the previous frame in the TCP stream) and choose “Apply as Column”:

Drag this field to a visible location:

Clicking this field will arrange the packets in descending order from bottom to top, with the unit in seconds:

Click once more to sort the messages in ascending order.

Find the frame with abnormal duration and right-click to trace the stream. Don’t forget to reload the packets to restore the packet order.

Otherwise, it will still sort this field in order.

If you want to filter messages where this field is greater than a certain time interval, for example, frame intervals greater than 100 seconds, you can use:

3.6 Filtering/Sorting Long Ping Response Times or Timeout Requests

3.6.1 Sort by Time Taken

First, apply the ICMP response time field as a column. For instructions on how to do this, refer to the section above.

Afterwards, only filter ICMP reply requests:

You can see the Response time field clearly displaying the RTT duration of each ICMP response packet.

Double-click this field to sort it from large to small, making it easier to visually identify which packet took the longest.

Filter lengthy ICMP reply times

Following that, if you want to filter requests that took more than 8.5ms, you can use:

Taking the first ICMP reply with a duration of 9.139 milliseconds as an example, if you want to filter the corresponding ICMP request packet along with the reply response, you can use:

3.6.3 Filtering Ping Timeouts/Unresponsive Packets

Just one statement to get it done:

It can be observed that there is no response when pinging the domestic public DNS 114, and the possibility of the other end disabling ping cannot be ruled out.

3.7 Filtering/Sorting Requests with Long DNS Resolution Times or Timeouts

3.7.1 Sort by Time Taken

First, find a DNS response packet. Expand it and locate the field at the very bottom. Right-click to apply it as a column. You can also refer to the above section for guidance on how to perform this action.

After applying as a column, the filter rule can be directly written, and then double-click the column we just added:

The DNS response times can now be seen sorted from largest to smallest.

Filter DNS responses with long processing times

The unit of the field is seconds, and filtering DNS responses that exceed 50ms can be:

3.7.3 Filter Out Packets Without Resolved Addresses

One statement is all it takes:

None of these requests resolved to addresses, with the number of returned records being 0:

3.8 Tracking DNS Requests and Responses/Filtering DNS Resolution Domains

3.8.1 Tracking DNS Requests (dns.id)

You can track a DNS request and its corresponding response using the dns.id field, for example, by tracking the following two dns.id fields:

3.8.2 Filtering Domain Names in DNS Resolution (dns.qry.name)

Filtering DNS-resolved domain names, such as cloud.tencent.com, could be:

Because this field’s data type is of string type, when combined with the previously mentioned regular expression matching, it can match multiple domains that meet the requirements, such as:

3.9 Connection Reset (Reset)

Many people have likely encountered error messages such as “The connection was refused by the remote site,” “ERR_CONNECTION_REFUSED,” or “Connection was reset” when trying to access certain websites:

We might as well analyze the packets in this type of scenario:

The three-way handshake was successfully established. At this point, the client sends a GET request, and the other side responded with RST-ACK to disconnect the connection. Meanwhile, the TTL of the SYN-ACK sent by the other side is 112, with an ip.id of 99537, but the TTL of the RST-ACK suddenly changes to 253 and the ip.id changes to 256. Obviously, who could have sent this? There are a few possibilities:

If the registration is okay in this kind of scenario, and there are no security walls on either end, it is recommended to report the issue to the local operator for further investigation, or contact the service provider at the remote end to address the problem.

3.10 Filtering by Specified Time Range/Specified Frame Range

Having covered so many techniques above, I believe you can now follow the example and find the corresponding fields to perform range filtering.

3.10.1 Specifying Time Range (frame.time)

Typically, Beijing Time (frame.time) is used for time-based filtering, though you can also use UTC time (frame.time_utc). Beijing Time and UTC time correspond to the following two time fields:

Filter after a certain time:

Filter a specific time range:

3.10.2 Specifying Frame Number Range (frame.number)

Filtering frames 1024~10240 can be:

3.11 Filtering by IP Location/AS Number

This feature requires Wireshark to be configured with an IP address database. For instructions on configuration, please refer to the author’s guide, which also provides more detailed use cases for filtering by address database fields. Below are two commonly used examples.

3.11.1 Filtering by IP Location

To filter TCP packets belonging to a specific country, such as filtering TCP packets with an IP location of the United States, you can use:

Of course, it can also be filtered on a city level. For example, to filter requests with locations attributed to Los Angeles or Chicago, write:

3.11.2 Filtering by AS Number

Filtering by AS number is similar to the above method. You need to identify the corresponding field for filtering.

To filter SYN requests from a specific AS number:

To filter UDP packets from a range of AS numbers:

This feature requires configuring the IP address library in Wireshark to be effective. For configuration steps, you can refer to the author’s guide. Additionally, there is a more detailed usage explanation on filtering fields in the address library. Below are two commonly used examples.

Filtering by IP Geolocation

Filter TCP packets from a specified country, such as filtering TCP packets originating from the United States:

Certainly, you can also filter by city, such as only selecting requests with a location in Los Angeles or Chicago, like this:

Through AS Number Filtering

Filtering using AS numbers is similar to the filtering methods mentioned above; you just need to find the corresponding filtering field.

Filtering SYN requests for a specific AS number:

Filtering UDP packets from a certain AS number range:

Filtering Port Reuse Cases

Wireshark’s definition of TCP port reuse:

When a packet capture file contains SYN packets (excluding SYN-ACK) that use the same address and port as an existing session, but with an initial sequence number (seq) different from the existing session, these SYN packets will be marked as port reuse.

Based on this definition, even if in a packet, the SYN of TCP stream 1 uses a set of source and destination IPs and ports, and the SYN of TCP stream 100 in this packet also uses this set of source and destination IPs and ports, even if these two streams are worlds apart or separated by a year or ten years, as long as they appear in the same capture file, Wireshark can, according to the definition, mark the SYN of TCP stream 100 that appears later as port reuse.

For example, consider the following instance:

In frames 49 and 83, the SYN packet appears in different TCP streams using the same source IP, destination IP, source port, and destination port. Therefore, the subsequent SYN is flagged by Wireshark as port reuse.

Although Wireshark marks port reuse in red and black by default, it does not indicate an anomaly. Instead, it serves as a reminder to users of the port reuse situation. The key is to observe whether the opposite end will reject the request. If the request is not rejected and the SYN-ACK response can be processed normally, there’s no problem. However, if the request is rejected or not responded to, it’s necessary to verify whether the opposite end has disabled TCP quick recycling or has other possible configurations. Ultimately, it depends on the reaction of the opposite end.

To filter instances of port reuse, you can use the following filtering statement:

3.13 Definition and Filtering of TCP Keep-Alive

Wireshark’s definition of TCP Keep-Alive:

The conditions below must all be met simultaneously for it to be marked as TCP Keep-Alive:

The syntax for filtering such packets is:

The filtered keep-alive packets all meet the above three conditions simultaneously. When the segment length is 1, the padding data is 0, corresponding to hexadecimal 0x00, indicating this is an empty data segment. Why set it to 1? The TCP protocol requires each segment to contain at least 1 byte of payload. Setting the length to 1 byte ensures that the probe packet meets this requirement, thereby saving overhead and achieving the ability to refresh the session keep-alive time (here, it should be distinguished from the HTTP Keep-Alive’s persistent connection).