I did a presentation at SharkFest’24 EU in Vienna, the “Wireshark Developer and User Conference“, about the topic: “Unveiling Network Errors – A Deep Dive into ICMP ‘Destination Unreachable’ Messages“. It covers the following:
“Effective troubleshooting of network issues is a critical concern for network technicians. While many are familiar with basic ICMP tools like ping and traceroute, the breadth of ICMP capabilities often goes underutilised. This session delves into ICMP messages, specifically the ‘Destination Unreachable’ type, and the insights they provide into network errors.
We will explore methods for capturing and analysing network traffic, highlighting practical tips and tricks for using Wireshark to diagnose and resolve issues efficiently. Attendees will gain a deeper understanding of ICMP message functions and how to leverage them for improved network troubleshooting.”
You can watch the whole session and download the slides. And you can do the six challenges at the end of the session as well. (The answers are not in the PDF, but shown in the video.)
Here are the slides:
Appendix: Some Notes
Thanks to everyone who came to me later on. Hence, here are some notes about the talk:
- Using the proposed extended capture filter of or icmp6 or icmp indeed captures way more ICMP packets than belong to your (filtered) sessions. This is still far better than a capture that doesn’t contain any of the ICMP packets that are needed for troubleshooting. And: You can/should still use Wireshark’s display filter to look at your sessions.
- Comparing Wireshark’s “capture filter” with the tcpdump’s “display filter”: A capture filter of host <host-A> and host <host-B> will NOT capture any type of ICMP errors (unless they are sent exactly from/to these two involved hosts), while a display filter of ip.addr eq <host-A> and ip.addr eq <host-B> will also show the corresponding ICMP errors (thanks to Wireshark’s parsing of the second IP header). For the capture filter, this is because the eBPF only parses through the very first IP header. That’s why you have to use the “or icmp or icmp6” trick. <- This is also a good generic example for comparing those two filter types.
- Concerning the address unreachable slide: “link down” means “link from the client is down”; not the link from the firewall terminating the layer 3 network.
- Concerning my NTP study: the 87.51 % of the IPv6 dest unreach, address unreach problems might be related to OpenWRT routers that have an ongoing issue with their IPv6 routing table, which is not populated correctly by default.
- One killer argument for using/analysing ICMP errors, especially the “port unreachable”, is: If you’re within the network team, you can now prove that a closed port is the fault of the server team. :)
- Within the 2nd challenge, second ICMP error: The source address of the NTP client is not out of the multicast range (as I said during the presentation), but out of the Unique Local Address (ULA) space. Nevertheless, by definition, this IPv6 space is *not* routable in the Internet.
Me in action 😂:
Soli Deo Gloria!



<3