Wireshark 4.0 was released today, and as you might have guessed from the version number, quite a few things have changed since 3.6. If you are a regular Wireshark user we recommend that you pay close attention to the release notes this time around, since it includes quite a few changes. I’ll cover some highlights here, but the release notes go into much greater detail.
Display Filter Changes 🔗
Display filters are one of Wireshark’s defining features and 4.0 makes them more powerful and more consistent. These improvements give you more control over the way that multiple occurrences of the same field are handled, let you do arithmetic, and many other things.
First, let’s look at the way multiple field occurrences are handled. Suppose you want to filter on an IPv4 source address. Within Wireshark that means using the “ip.src” filter field. You might assume that the packets on your network have one IPv4 header and therefore one source address, but that’s not necessarily the case. You might be in an environment that uses some form of tunneling like GRE or one of the many VPN protocols, and even on simple networks ICMP errors carry the IPv4 header of the offending packet. Maybe you live on the edge and used scapy to create a packet with a hundred or a thousand layers of IP in IP nesting.
In any case a filter like “ip.src == 10.1.2.3” can be ambiguous. Even worse, Wireshark has a completely made up “ip.addr” field, which is an alias for both “ip.src” and “ip.dst”. It’s convenient, but it also means you’re guaranteed to have two “ip.addr” fields for each IPv4 header which means guaranteed ambiguity.
In order to reduce this ambiguity Wireshark 4.0 adds a layer operator, which lets you select a specific occurrence of a field. To use the layer operator, just put a number sign and a layer number after a field. For example, if we have a GRE packet with both outer and inner IPv4 layers,
ip.src#1 == 10.1.2.3
will match the outer address,
ip.src#2 == 10.1.2.3
will match the inner address, and
ip.src == 10.1.2.3
will match either address.
Along with layers, you can be much more specific about matching zero, one or more, or all fields in a particular packet. You have been able to do the following comparison operators since Wireshark’s inception:
ip.addr == 10.100.100.1
If any of these match, we have a winner.
not ip.addr == 10.100.100.1
If none of these match we have a winner.
Wireshark also has “!=” (not equal), which was a bit confusing in past versions. This was fixed in Wireshark 3.6:
ip.addr != 10.100.100.1
In Wireshark 3.4 and earlier, if any of these don’t match, we have a winner. In Wireshark 3.6 and later, if none of these match, we have a winner.
Wireshark 4.0 adds the following:
ip.addr any_eq 10.100.100.1
If any of these match, we have a winner, similar to “==”.
ip.addr all_ne 10.100.100.1
If none of these match, we have a winner, similar to “!=” in version 3.6 and later.
ip.addr === 10.100.100.1
ip.addr all_eq 10.100.100.1
If all addresses match, we have a winner.
ip.addr !== 10.100.100.1
ip.addr any_ne 10.100.100.1
If any addresses don’t match, we have a winner, similar to “!=” in version 3.4 and earlier.
You can also do arithmetic – you can add, subtract, multiply, and divide. You can use the modulo (%) operator, which gives you the remainder of integer division. Suppose your company has all of its web servers running on a port that ends in 443: 443, 1443, 5443, 21443, etc. You can use the modulo operator to match them like so:
{tcp.port % 1000} == 443
There are a bunch of other changes as well. You can now match bytes starting from the end of a PDU, dates and times can be specified as UTC, Unicode can be matched using code points,
Default main window layout 🔗
In past releases Wireshark followed a standard set by its predecessors and placed the packet list, packet detail, and byte view on top of each other, like so:
That standard was set a long time ago when most monitors had a 4:3 aspect ratio and lower resolutions than they do these days. As of Wireshark 4.0, the default is for the detail and byte view to be next to each other, which makes it easier to take advantage of the real estate available on modern displays:
Conversations and Endpoints 🔗
The Conversations and Endpoints dialogs have been a popular feature for a long time and are often the first place people look when investigating a problem. Wireshark 4.0 makes them more powerful and easier to use. For example, you can tear off tabs — you can now see TCP and UDP conversations side by side in separate windows. Sorting has been improved, you can now hide columns, filter on stream IDs, and export data as JSON.
Hex import 🔗
Sometimes the packets you’re interested in aren’t in a nice pcap or pcapng file that you can just open with Wireshark, and are instead buried in a hex dump. Wireshark provides two ways to convert hex dumps to pcaps: “Import From Hex Dump” in the main application and the text2pcap utility. They had different feature sets and behaved differently in past versions, but they are much more consistent in Wireshark 4.0.
What’s Going Away 🔗
We no longer ship official 32-bit Windows packages for Wireshark 4.0 and later. If you’re still using a 32-bit Windows system, we’ll keep shipping Wireshark 3.6 updates until 2024. You won’t be able to take advantage of the cool new features in 4.0 and later, unfortunately.
What’s Not Here Yet 🔗
There are two features for Windows that we’d really like to add, but didn’t make the cut for 4.0: Dark mode and Arm64 support. Dark mode requires support from Qt, our user interface library. It’s still a work in progress, but we’re hoping it will make its way into Wireshark 4.2.
Building packages for Arm64 requires build hardware and software library support. We hope to have both of those in place for Wireshark 4.2 as well.
If You’re A Developer 🔗
We now require a C11 compiler, the PCRE2 library, and updated versions of many of the third party libraries that we use. We no longer require Perl to build Wireshark.
Summary 🔗
There are a bunch of other new features and improvements coming your way in Wireshark 4.0. Thanks to all of the developers that helped make this happen!
Comments 🔗
Comment by Guy Harris on 2022-10-05 06:35:19 +0000 🔗
Note that “Arm64 support” here specifically refers to Windows binary packages distributed from wireshark.org.
If, for example, a Linux distribution supports Arm64, they may provide Arm64 packages, whether source or binary, for current or past Wireshark versions. The issue is, as Gerald noted, an issue of wireshark.org building binary packages.
Furthermore, we already provide Arm64 binary packages of Wireshark 3.6.8 and, now, 4.0 for macOS.
Comment by Kara on 2022-10-05 14:52:09 +0000 🔗
Good
Comment by Totzi on 2022-10-26 08:14:58 +0000 🔗
YEAY!