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.
Translations
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 https://secwiki.org/w/Npcap/WiFi_adapters. 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 https://nmap.org/npcap/. To compare Npcap to WinPcap, visit https://nmap.org/npcap/vs-winpcap.html.
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.
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 https://www.elastic.co/blog/analyzing-network-packets-with-wireshark-elasticsearch-and-kibana for an example of using Elasticsearch and Kibana (the visualizer element) with Wireshark trace files. See www.elastic.co 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 https://www.h21lab.com/tools/tshark-elasticsearch.
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 bugs.wireshark.org 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?
DHCP and TLS
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.