top of page
  • Writer's pictureLaura Chappell

Wireshark v3 (Part 1 of 2)

Updated: Feb 23, 2019

Typically, when a major release number changes (such as Wireshark v1 to v2), there is a grand and significant set of changes that make many stumble through tasks that they’d previously breezed through while checking email, the local weather, and their coffee temperature.

This major release number change is a bit different. You will work just as effectively with Wireshark version 3 as you have worked with Wireshark version 2.

The primary reason the major version number has changed is the removal of the GTK+ user interface. Good riddance, I say. It’s time to move on if you’ve been hanging on to the old Wireshark interface! In addition, the WinPcap driver for Windows has been replaced with the Npcap driver. We will look at that change in this two-part blog post set.

Don’t get me wrong -- Wireshark v3 does offer some significant and exciting changes that I think the community will appreciate.

In these next two blogs, I will examine most of the changes that will be released with Wireshark v3. In some cases, I will link to videos to demonstrate how to configure/use the new features.

If you aren’t one of my “In Laura’s Lab” Newsletter subscribers, please visit sign up so I can let you know when new blogs, videos, training classes, books, and challenges are released. Many things are changing in 2019 and I am thrilled to be able to return to projects that allow me to share my passion of analysis with all of you!

Hold on… here we go with the updated/new features in Wireshark v3! In this blog post, I will cover the following changes:

  • Translations

  • Npcap (No More WinPcap)

  • UDP Conversation Timestamping

  • Tshark and ElasticSearch

  • Capture Information is Back

  • Checksum Validation Disabling

  • String() Display Filter Function

  • DHCP and TLS

Remember, sign up for the Newsletter to be alerted when Introducing Wireshark v3

(Part 2 of 2) is posted.


Wireshark now supports Swedish, Ukrainian, and Russian. To change the language in which Wireshark displays the menu items, select Edit | Preferences. English, French, German, Italian, Japanese, and Polish are also supported.

Npcap (No More WinPcap)

The Windows .exe installer now ships with Npcap instead of WinPcap. As many of you may know, WinPcap hasn’t been updated in many moons (since March 8, 2013). Npcap, created by Gordon Lyon, the Nmap project founder, offers improved speed, portability, security, and efficiency. During the installation of the Windows .exe installer, you will now be prompted to install Npcap.

One of the biggest advantages of moving to Npcap is the ability to capture raw 802.11 WiFi frames from adapters that can be placed in monitor mode. Gordon has provided a great list of capable adapters at This heralds the end-of-life for Riverbed’s AirPcap adapters.

Another advantage of using the Npcap driver is the ability to capture loopback traffic, but I’m unsure how many times people think, “hmmm…. I’d like to catch my loopback traffic.”

For more information on Npcap, see To compare Npcap to WinPcap, visit

UDP Conversation Timestamps

This always seemed like a no brainer to me. The TCP conversation timestamps are tremendously helpful in finding delays within a single TCP conversation. Since those conversations are based on a combination of IP addresses and port numbers, why couldn’t UDP offer the same type of timestamping? Now, when you expand a UDP header, you will notice the new UDP header [Timestamps] section which contains two fields: Time since first frame and Time since previous frame.

If your application runs over UDP and doesn’t have an app.time field to measure response times for you, you can now look at the udp.time_delta field.

UDP Timestamps

Tshark and ElasticSearch

Tshark now supports a -G elastic-mapping option which creates an Elasticsearch mapping file. Elasticsearch is an open source search and analytics engine.

Elasticsearch uses a mapping file to interpret packet fields properly. For example, timestamp fields need to be interpreted as time fields and the index fields need to be interpreted as decimal fields.

Visit for an example of using Elasticsearch and Kibana (the visualizer element) with Wireshark trace files. See for more information on Elasticsearch and Kibana. You can also find a great write-up about using Tshark with Elasticsearch by Martin Kacer (H21 lab) at

Type tshark -G help to view all the reporting options for Tshark.

Capture Information is Back

Ok, this one doesn’t seem very useful to me and you can check out Bug 15477 on to follow the discussion on this “feature.” Someone must have felt this was useful at some point to bring it back to Wireshark.

A long time ago (years, really), a Capture Information dialog box would pop up when you were capturing traffic. This dialog box is back, but disabled by default. To enable the Capture Information dialog box, click the Capture Interfaces icon on the main toolbar and then click the Options tab. In the Display Options area, check Show capture information during live capture.

Now go ahead and start a capture.

This Capture Information dialog box is a bit underwhelming. It simply displays a very basic summary of traffic captured with sparklines to spice it up a bit. You won’t get details on the application activity as this dialog box only lists the base TCP/IP protocols seen, such as ARP/RARP, IP, UDP, TCP, ICMP, etc. (RARP? Do people still use that?)

I can’t believe I dedicated this many words to this dialog box. It’s really not worth it. Sorry.

Checksum Validation Disabling

Finally, the Ethernet and IEEE 802.11 dissectors do not validate the frame check sequences (checksums) by default. This is a great change to Wireshark. Most systems offload checksum calculations to the network interface cards. If you enable these checksum validations and you are capturing directly on one of these systems, all outbound packets would be captured before the checksum was applied and appear to have invalid checksums. Wireshark already had checksum validation disabled for IP, UDP, and TCP. These are just a few last stragglers.

String() Display Filter Function

A new display filter function string() can be used to convert non-string fields to strings for use with functions such as contains and matches. For example, the ip.dst (IP Destination Address) field only expects an IP address in this field. Until this function came along, you couldn’t use contains or matches when filtering on this field.

Section 6.4.6. Functions of the Wireshark User Guide provides an interesting example of this new display filter function:

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

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

Let’s break down this filter:

string(ip.dst) treat this field as a string

matches apply regular expressions what follows this

^172 match the starting string “172”

\. match the character “.”

(1[6-9] match the character “1” followed by a single character between 6 and 9

|2[0-9] or match the character “2” followed by a single character between 0 and 9

|3[0-1]) or match the character “3” followed by a single character between 0 and 1

\. match the character “.”

.{1,3} match any character (no line break/line feed) between 1 and 3 times

\. match the character “.”

255 match the string “255”

Nice, eh?


The BOOTP dissector has been renamed to DHCP. Finally you can use the display filter dhcp to see DHCP traffic! This makes perfect sense and there are many folks in the IT industry who never worked with or are familiar with BOOTP. Although DHCP traffic does have a BOOTP header (except for DHCPv6), we most often configure DHCP servers these days, not BOOTP servers. The old bootp.* filters will still be supported for a while, but it’s time to get accustomed to using the new dhcp.* filters.

In addition, the SSL dissector has been renamed to TLS. This is another improvement for which we’ve been eagerly waiting. Although the old ssl.* display filters will be supported for a while, it’s time to start using the new tls.* display filters.

That’s it for the first set of Wireshark v3 feature updates and enhancements.

If you aren’t one of my “In Laura’s Lab” Newsletter subscribers, please visit sign up so I can let you know when new blogs, videos, training classes, books, and challenges are released.

3 commentaires

Membre inconnu
06 mai 2019

I wanted to give you one more bit o'feedback regarding NPCAP: I recently started having problems with my VMWare Workstation installation, where none of the VM's could access the network (via bridge mode) any more. I had to change them all to use NAT instead. After FINALLY having the time to track this down, I ran across this article:

When I followed these steps, I indeed found TWO network adapters that had confused VMWare Workstation -- the second one being the NPCAP Loopback Adapter! Since I have to imagine other network-heads have VMWare Workstation running, I thought I'd share this, as it had aggravated me for the better part of a few weeks.


Laura Chappell
Laura Chappell
17 avr. 2019

Unfortunately, the Capture Info Dialog box only lists the number of ARP/RARP, ICMP, IP, TCP, and UDP packets that have been captured. See the image in the blog. Boring! For what you are doing, Bill, I'd recommend setting up a display filter to show only the database query/response packets. Another option would be a custom IO graph.


Membre inconnu
16 avr. 2019

As a old LANalyzer user, I can give you a great reason for the capture info dialog box: when you are monitoring a system for a specific change! Case in point: You are trying to capture a database query and you want the query submission and the return code, but you don't need all the data. You watch the graph during the idle time, and as soon as you see traffic spike, you end the trace. Or, vice versa: You are monitoring a user-centric process, and as soon as you see the network utilization drop off, you know it is done and you can stop the trace. Finally, it is slightly easier to teach an end user to click "…

bottom of page