How To Set A Filter In Wireshark

6.four. Building Display Filter Expressions

Wireshark provides a display filter language that enables you to precisely control which packets are displayed. They can be used to cheque for the presence of a protocol or field, the value of a field, or even compare ii fields to each other. These comparisons can exist combined with logical operators, like "and" and "or", and parentheses into complex expressions.

The following sections will become into the brandish filter functionality in more than detail.

half-dozen.4.1. Display Filter Fields

The simplest display filter is ane that displays a unmarried protocol. To but display packets containing a detail protocol, blazon the protocol into Wireshark'due south display filter toolbar. For example, to only display TCP packets, blazon tcp into Wireshark's display filter toolbar. Similarly, to but display packets containing a particular field, type the field into Wireshark's display filter toolbar. For example, to simply display HTTP requests, type http.request into Wireshark'south brandish filter toolbar.

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

half dozen.iv.two. Comparing Values

You can build display filters that compare values using a number of dissimilar comparison operators. For example, to only display packets to or from the IP accost 192.168.0.one, employ ip.addr==192.168.0.i.

A complete list of bachelor comparing operators is shown in Table 6.6, "Brandish Filter comparison operators".

	Tip
	English and C-similar operators are interchangeable and tin can be mixed within a filter cord.

Tabular array vi.6. Brandish Filter comparison operators

English	Allonym	C-like	Description	Example
eq	any_eq	==	Equal (any if more than ane)	`ip.src == 10.0.0.5`
ne	all_ne	!=	Non equal (all if more i)	`ip.src != 10.0.0.5`
	all_eq	===	Equal (all if more one)	`ip.src === 10.0.0.v`
	any_ne	!==	Not equal (any if more than one)	`ip.src !== 10.0.0.5`
gt		>	Greater than	`frame.len > x`
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			Protocol, field or slice contains a value	`sip.To contains "a1762"`
matches		~	Protocol or text field matches a Perl-compatible regular expression	`http.host matches "pinnacle\\.(org\|com\|net)"`
bitwise_and		&	Bitwise AND is non-aught	`tcp.flags & 0x02`

All protocol fields have a type. Section 6.four.2.1, "Display Filter Field Types" provides a listing of the types with examples of how to employ them in display filters.

6.4.ii.1. Brandish Filter Field Types

Unsigned integer

Can exist 8, 16, 24, 32, or 64 $.25. You can express integers in decimal, octal, hexadecimal or binary. The following display filters are equivalent:

ip.len le 1500

ip.len le 02734

ip.len le 0x5dc

ip.len le 0b10111011100

Signed integer

Can be 8, 16, 24, 32, or 64 bits. As with unsigned integers you lot can use decimal, octal, hexadecimal or binary.

Boolean

Can be 1 or "true", 0 or "simulated" (without quotes).

A Boolean field is present whether its value is true or false. For example, tcp.flags.syn is present in all TCP packets containing the flag, whether the SYN flag is 0 or i. To but lucifer TCP packets with the SYN flag set, you need to use tcp.flags.syn == 1 or tcp.flags.syn == true.

Ethernet address

6 bytes separated by a colon (:), dot (.), or dash (-) with ane or two bytes between separators:

eth.dst == ff:ff:ff:ff:ff:ff

eth.dst == ff-ff-ff-ff-ff-ff

eth.dst == ffff.ffff.ffff

IPv4 address

ip.addr == 192.168.0.i

Classless InterDomain Routing (CIDR) annotation tin exist used to test if an IPv4 address is in a certain subnet. For example, this display filter will find all packets in the 129.111 Class-B network:

ip.addr == 129.111.0.0/16

IPv6 accost

ipv6.addr == ::i

As with IPv4 addresses, IPv6 addresses tin can match a subnet.

Text string

http.request.uri == "https://www.wireshark.org/"

Strings are a sequence of bytes. Functions similar lower() utilize ASCII, otherwise no item encoding is assumed. String literals are specified with double quotes. Characters tin besides exist specified using a byte escape sequence using hex \x hh or octal \ ddd , where h and d are hex and octal numerical digits respectively:

dns.qry.proper noun contains "www.\x77\x69\x72\x65\x73\x68\x61\x72\x6b.org"

Alternatively, a raw cord syntax can exist used. Such strings are prefixed with r or R and treat backslash equally a literal grapheme.

http.user_agent matches r"\(X11;"

Appointment and time

frame.time == "Sep 26, 2004 23:18:04.954975"

ntp.xmt ge "2020-07-04 12:34:56"

The value of an absolute fourth dimension field is expressed every bit a string, using one of the ii formats to a higher place. Fractional seconds can be omitted or specified up to nanosecond precision; actress trailing zeros are allowed just not other digits. The string cannot take a fourth dimension zone suffix, and is always parsed every bit in the local fourth dimension zone, even for fields that are displayed in UTC.

In the first format, the abbreviated month names must be in English language regardless of locale. In the second format, whatever number of fourth dimension fields may exist omitted, in the society from least pregnant (seconds) to most, but at least the entire date must be specified:

frame.fourth dimension < "2022-01-01"

In the 2nd format, a T may appear between the date and time as in ISO 8601, but non when less pregnant times are dropped.

6.four.two.2. Some Examples

udp contains 81:60:03

The display filter above matches packets that contains the 3-byte sequence 0x81, 0x60, 0x03 anywhere in the UDP header or payload.

sip.To contains "a1762"

The display filter above matches packets where the SIP To-header contains the string "a1762" anywhere in the header.

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

The brandish filter above matches HTTP packets where the HOST header contains height.org, pinnacle.com, or acme.net. Comparisons are case-insensitive.

tcp.flags & 0x02

That display filter will match all packets that contain the "tcp.flags" field with the 0x02 bit, i.e., the SYN bit, gear up.

half-dozen.4.3. Possible Pitfalls Using Regular Expressions

String literals containing regular expressions are parsed twice. Once by Wireshark'south display filter engine and once again by the PCRE2 library. It's important to keep this in mind when using the "matches" operator with regex escape sequences and special characters.

For example, the filter expression frame matches "AB\x43" uses the cord "ABC" as input pattern to PCRE. Still, the expression frame matches "AB\\x43" uses the string "AB\x43" equally the pattern. In this instance both expressions give the same consequence because Wireshark and PCRE both back up the same byte escape sequence (0x43 is the ASCII hex code for C).

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

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

6.4.4. Combining Expressions

You tin combine filter expressions in Wireshark using the logical operators shown in Table vi.7, "Display Filter Logical Operations"

Table 6.vii. Brandish Filter Logical Operations

English	C-like	Clarification	Case
and	&&	Logical AND	`ip.src==10.0.0.5 and tcp.flags.fin`
or	\|\|	Logical OR	`ip.src==10.0.0.v or ip.src==192.ane.1.1`
xor	^^	Logical XOR	`tr.dst[0:three] == 0.vi.29 xor tr.src[0:3] == 0.6.29`
not	!	Logical NOT	`non llc`
[…]		Subsequence	Run into "Slice Operator" below.
in		Prepare Membership	http.asking.method in {"HEAD", "Become"}. Run across "Membership Operator" below.

half-dozen.4.5. Slice Operator

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

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

The case in a higher place uses the due north:g format to specify a single range. In this case n is the beginning offset and m is the length of the range being specified.

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

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

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

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

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

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

eth.src[ii] == 83

The instance higher up uses the n format to specify a single range. In this example the chemical element in the sequence at start northward is selected. This is equivalent to n:i.

eth.src[0:iii,1-two,:4,four:,ii] == 00:00:83:00:83:00:00:83:00:xx:20:83

Wireshark allows y'all to string together single ranges in a comma separated list to grade compound ranges equally shown to a higher place.

6.4.6. Membership Operator

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

Note

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

The display filter

tcp.port in {80, 443, 8080}

is equivalent to

tcp.port == 80 || tcp.port == 443 || tcp.port == 8080

However, the display filter

tcp.port in {443, 4430..4434}

is not equivalent to

tcp.port == 443 || (tcp.port >= 4430 && tcp.port <= 4434)

This is because comparison operators are satisfied when any field matches the filter, then a packet with a source port of 56789 and destination port of port 80 would besides match the second filter since 56789 >= 4430 && fourscore <= 4434 is true. In dissimilarity, the membership operator tests a single field against the range condition.

Sets are not merely limited to numbers, other types tin be used as well:

http.request.method in {"HEAD", "Go"} ip.addr in {x.0.0.v .. 10.0.0.ix, 192.168.1.ane..192.168.one.nine} frame.time_delta in {ten .. 10.five}

6.4.7. Functions

The brandish filter language has a number of functions to convert fields, see Table 6.8, "Display Filter Functions".

Table 6.8. Brandish Filter Functions

Office	Description
upper	Converts a string field to upper-case letter.
lower	Converts a cord field to lowercase.
len	Returns the byte length of a string or bytes field.
count	Returns the number of field occurrences in a frame.
string	Converts a non-string field to a string.
max	Return the maximum value for the arguments.
min	Render the minimum value for the arguments.
abs	Return the absolute value for the argument.

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

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

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

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

For instance, to match odd frame numbers:

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

To lucifer IP addresses ending in 255 in a cake of subnets (172.16 to 172.31):

cord(ip.dst) matches r"^172\.(i[vi-nine]|2[0-nine]|three[0-1])\.[0-9]{one,iii}\.255"

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

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

6.4.8. Sometimes Fields Alter Names

As protocols evolve they sometimes change names or are superseded by newer standards. For case, DHCP extends and has largely replaced BOOTP and TLS has replaced SSL. If a protocol dissector originally used the older names and fields for a protocol the Wireshark evolution team might update it to use the newer names and fields. In such cases they will add an alias from the old protocol name to the new one in society to make the transition easier.

For example, the DHCP dissector was originally developed for the BOOTP protocol only as of Wireshark iii.0 all of the "bootp" display filter fields accept been renamed to their "dhcp" equivalents. You tin nevertheless utilize the one-time filter names for the time being, eastward.chiliad., "bootp.blazon" is equivalent to "dhcp.type" but Wireshark volition show the warning ""bootp" is deprecated" when you lot use it. Support for the deprecated fields may exist removed in the future.

6.four.ix. Some protocol names can exist ambiguous

In some uncommon cases relational display filter expressions (equal, less than, etc.) can be ambiguous. The filter name of a protocol or protocol field tin contain any letter and digit in any order, possibly separated by dots. That tin can be indistinguishable from a literal value (ordinarily numerical values in hexadecimal). For example the semantic value of fc can be the protocol Fibre Aqueduct or the number 0xfc in hexadecimal. The 0x prefix is optional for literal values and furthermore "0xfc" would be a syntactically valid filter name for a protocol.

Wireshark will apply a heuristic for parsing those expressions. A value on the right hand side of the expression is treated every bit literal value first. If that fails it is treated as a protocol or protocol field (if one exists with that proper name). If that fails it is a syntactical error. On the left hand side values are ever treated equally protocol fields. Literal values are not considered on the LHS. So the expression fc == fc is parsed equally "Byte array of protocol with proper noun 'fc' equals byte array { 0xfc } of length 1".

Sometimes this may not exist the intended meaning and there is additional syntax to resolve the ambiguity. Lexical tokens in-between angle brackets are e'er and simply treated every bit literal values. Bytes arrays tin likewise be prefixed with a colon. Tokens prefixed with a dot are e'er treated as a protocol name (the dot stands for the root of the protocol namespace and is optional).

frame[ten:] contains .fc or frame[10] == :fc and not frame contains <cafe.face up>

The about common use case for a display filter relational expression is to compare a field with a constant value on the right hand side and in that case the heuristic method used will parse the expression correctly. In the not-so-common example, or if you are writing a script, or you think your expression may not be giving the expected results it is advisable to use the explicit syntax to resolve any possible ambiguity in the meaning of filter expression.