For many years I was afraid to open new issues for open-source tools since I am not a coder at all and won’t ever be able to fix some of the problems. Many times I got answers like “The source is open, go ahead and fix it yourself”. This brought me to a point where I simply stopped proposing new ideas and features.

This has changed since I was at SharkFest’22 EUROPE (the Wireshark Developer and User Conference), especially at a session from Uli Heilmeier called “Contribute to Wireshark – the low hanging fruits” [PDF].

And that is exactly what I would like to recommend to you. This post is about giving examples, that even minor errors and thoughts are appreciated by the Wireshark team. But, of course, if you actually have coding skills, please go ahead and fix some of the issues. ;)

Here are some feature requests I opened during the last year which actually got resolved. Most of them with Wireshark version 4.2.0 (November 15, 2023).

Kudos to the Wireshark developers who almost instantly answered and added the feature requests: Uli Heilmeier, John Tacker, Alexis La Goutte, Martin Mayer, Guy Harris, Chuck Craft, Jim Young.

Default Coloring Rule “TTL low or unexpected” not optimal

I had some issues with the default colouring rule for “TTL low…”. At first, it was only used for legacy IP (with its ip.ttl field) and not for IPv6 (with its equivalent ipv6.hlim field). Furthermore, some routing protocols such as EIGRP or GLBP were coloured in red though they were working correctly. We had a little discussion about that and changed the legacy IP TTL rule to:

IPv4 TTL low or unexpected: (ip.dst != 224.0.0.0/4 && ip.ttl < 5 && !(pim || ospf || eigrp || bgp || tcp.port==179)) || (ip.dst == 224.0.0.0/24 && ip.dst != 224.0.0.251 && ip.ttl != 1 && !(vrrp || carp || eigrp || rip || glbp))

while we added an IPv6 rule (with correct naming):

IPv6 hop limit low or unexpected: (ipv6.dst != ff00::/8 && ipv6.hlim < 5 && !( ospf|| bgp || tcp.port==179)) || (ipv6.dst==ff00::/8 && ipv6.hlim not in {1, 64, 255})

The first screenshot shows the colouring rules pre-4.2.0 and the second screenshot the most current ones. Have a look at the new “IPv6 hop limit …” rule:

Note that your traceroutes (especially for IPv6) will look differently now, since the first packets, where the hop limit is set to low values intentionally, are now marked red. Furthermore, all Wireshark screenshots from the past years, where the old rules kicked in, are outdated now. 😂

“Discard” Protocol (TCP/UDP port 9) not yet there

While adding some more protocols to the Ultimate PCAP, I came along with this fairly old network protocol called “Discard”, RFC 863, which was not recognized by Wireshark yet. Less than 24 hours later, it was done. Wow.

Display Filter dns.qry.type with types rather than values

This one is much more relevant. You can now use the Display Filter for filtering DNS queries based on their type, such as “aaaa”, “txt”, “ptr”, and so on. Here’s an example of filtering out any DNS packets belonging to DNSSEC’s “dnskey”:

Source port column shows odd values

A classical bug – a really small one. ;) For whatever reason some GUI fields showed wrong values for source ports. Though I mentioned it and it got fixed, of course. Screenshot before the fix:

ICMPv6 RA flag: Proxy?!?

“What’s that Proxy bit in an RA?” I got this question during one of my IPv6 trainings. Uh, I don’t know to be honest. ;) I’m not aware of any proxy at this stage. Turned out it was just an experimental RFC talking about Neighbour Discovery Proxies (ND Proxy). The solution was to rename it to “ND Proxy” and to add that experimental RFC in the info line at the bottom of Wireshark. Screenshots before and after the fix:

Resolve Phyiscal Addresses within DHCP and DHCPv6 “Client Identifier”

Can’t Wireshark resolve the physical addresses (MAC addresses) within DHCPv6/DHCP packets? Yes, it can. Screenshots before and after 4.2.0:

Dissector needed: WS-Discovery, UDP port 3702

Something weird again: What’s that UDP-based discovery protocol my Windows 11 sends out? And why isn’t there any information about it in Wireshark? A little googling brought me to Wikipedia: WS-Discovery. Since we don’t have any XML schema for this WS-Discovery thing currently, it is a least dissected as XML in the meantime:

[not yet solved] Connecting line for ICMP errors not working in both directions

One problem remains, since this seems to be a harder one, or at least requires more work: Wireshark draws a connecting line between a packet and its corresponding ICMP error (if any). However, this process does not work in the opposite direction, that is: If you click the ICMP error, there’s no line back to the originating packet.

Is anyone accepting a challenge? 😂

Soli Deo Gloria.

Photo by Austin Kehmeier on Unsplash.