#Wireshark capture filter for ping code#

For example in an IP-over-IP packet ip.addr#1 = 1.1.1.1 matches the outer layer addresses and ip.addr#2 = 1.1.1.2 matches the inner layer addresses. The Wireshark developers give other examples in the release notes, like IP-over-IP tunneling.Ī syntax to match a specific layer in the protocol stack has been added.

The #1 means that we want to match the first occurrence of the protocol in the packet, not on the quoted messages**.

In Wireshark 4.0, this filter becomes straightforward: icmp.type#1 != 8 and icmp.type#1 != 0 While the filter above works fine, it is not intuitive.

#Wireshark capture filter for ping code#

This filter will include all packets with an error code instead of removing the pings. icmp and ((icmp.type > 0 and icmp.type 8)) To get around this limitation, we can rewrite the filter not to use any negation like this. Using the naive filter above, we would remove the packet from the packet list, as it contains not that applies to all ICMP layers.

The one of the original packet the network engineer sent and one of the ICMP error message. So, in this case, the packet sent by the router contains two ICMP headers. The router doesn't quote the whole packet, usually just the IPv4 and TCP/UDP/ICMP header. In that case, the router with the missing path sends an ICMP Destination Unreachable, Network Unreachable message quoting the original packet. Suppose a network engineer sends an ICMP Echo Request to a network that can not be routed. The highlighted packets are destination unreachable packets ( icmp.type =35) that should not be removed from the packet list in this case. But unfortunately, some other ICMP messages that indicate errors are filtered, too. You will notice that this naive filter does not quite work. So the filter should be icmp and not (icmp.type = 0 or icmp.type = 8) Echo Request has the type field in the ICMP header set to 8, whereas an Echo Reply sets it to 0. The ICMP Echo Request / Reply messages, better known as Ping, don't indicate a problem and are common background noise in networks network engineers use them for troubleshooting or monitoring. In practice, you will notice that we get way too many packets, and you will quickly find yourself narrowing down the filter a bit more. So we might use a display filter like icmp. ICMP is an excellent protocol for network analysts because, correctly interpreted, we can diagnose a problem right away. This means that the original packet was encapsulated in a new packet, with a new IP header added on top. If you see a packet that has two IP headers, it's likely that the packet has been tunneled or quoted. When troubleshooting network issues, it's important to be able to read a PCAP and understand what's going on. This can be confusing for people who are trying to read a PCAP, because they might not expect to see a header twice in the same packet. Packets can get a lot more complex, including repeating the same protocol twice (tunneling) or repeating the same protocol field twice within the same packet layer. Not every packet in a PCAP is just a simple Ethernet / IPv4 / TCP packet. Matching a specific layer in the protocol stack That's where these enhancements make your filtering job easier.

Appear more than once in a single packet.

Quote other protocols in a reply (ICMP).

Tunnel the same protocols multiple times (IP-in-IP).

Why does this matter? Well, maybe you deal with protocols that: The filter expression limitation has been an issue on the Wireshark bug tracker for a long time - 13 years: Filter expression syntax needs to handle tunneling better. In packets that contain the same protocol more than once, it was previously impossible to distinguish between these protocols using a display filter. If you analyze network protocols like IPv4, ICMP, IPv6, ICMPv6, TLS, and GRE, this article is for you.