CloudShark 3.10 updates the display filter language, and users may need to update certain filters in their existing profiles. Here are the major changes users should know about and how to best use them!
There is finally a dhcp protocol filter that can be used to filter on Dynamic Host Configuration Protocol (DHCP) packets. In previous versions filtering for DHCP packets used the bootp protocol filter because DHCP is based on the Bootstrap Protocol (BOOTP). Both even use the same UDP ports. This rename is a welcome change for many who remember their first time troubleshooting DHCP with a packet capture only to find no filter exists for the packets!
The ssl protocol filter has also been renamed and is now tls. This is a similar case where the Transport Layer Security (TLS) builds on the older, now deprecated, Secure Sockets Layer (SSL) protocol.
These renamed protocol filters will make it easier for new users to filter using names they will expect! Existing users with profiles containing filters with bootp or ssl must update them to use the new protocol filter names.
From the Wireshark 3.6.0 Release Notes:
"The expression “a != b” now always has the same meaning as “!(a == b)”. In particular this means filter expressions with multi-value fields like “ip.addr != 1.1.1.1” will work as expected (the result is the same as typing “ip.src != 1.1.1.1 and ip.dst != 1.1.1.1”). This avoids the contradiction (a == b and a != b) being true.
It is possible to use the syntax “a ~= b” or “a any_ne b” to recover the previous (inconsistent with "==") logic for not equal."
To understand why this change was made we'll use an example capture containing a DNS lookup for www.qacafe.com using Google Public DNS running on 8.8.8.8, and a request for https://www.qacafe.com.
While analyzing a capture, looking at DNS traffic can be a good place to start. Since we know the user is using Google Public DNS running on IP address 8.8.8.8 we can filter for these DNS packets with ip.addr == 8.8.8.8.
Since DNS looks OK, we can filter those packets out. A naive approach would be to change the == to != and expect to see everything except these packets.
However, previous versions of CloudShark would not allow a filter expression like this because these packets would still be displayed! This is because the field ip.addr will match both the ip.src and ip.dst fields! Saying ip.addr != 8.8.8.8 could be true for ip.src and false for ip.dst at the same time.
Starting in CloudShark 3.10 this expression is interpreted differently and the packets are not displayed as expected!
Set elements in a display filter must be separated using the comma character now. In previous versions, they could be separated by a space. Using sets in your display filters is a great way to simplify and make them easier to understand. Take, for example, the following filter to search for packets with private IPv4 address:
ip.addr == 10.0.0.0/8 || ip.addr == 172.16.0.0/12 || ip.addr == 192.168.0.0/16
A set of IP addresses can be used to write this as:
ip.addr in { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
Users with saved filters should make sure they are using the comma character as a separator when using sets.
From the Wireshark 3.6.0 Release Notes:
"Literal strings can now be specified using raw string syntax, identical to raw strings in the Python programming language. This can be used to avoid the complexity of using two levels of character escapes with regular expressions."
Without using raw strings each backslash character in a string has to be escaped with an additional backslash. It can become especially cumbersome when specifying a Windows shared directory such as \\10.3.1.1\public, which requires a filter with each \escaped:
smb2.tree == "\\\\10.3.1.1\\public"
With raw string syntax the same filter expression can be written as smb2.tree == r"\\10.3.1.1\public. An example capture shows the same filter expression with and without raw strings.
CloudShark presents several great tools for teams to save time and share knowledge. In particular, the ability to save pre-built filters and apply them to a profile means everyone can benefit from good filters that are made to look for specific problems. When a new way to build filters is released into the wild, it’s important to update these profiles too! That way everyone can continue to work together on the same data in the same way.
