Name resolution tries to convert some of the numerical address values into a human readable format. There are two possible ways to do these conversions, depending on the resolution to be done: calling system/network services (like the gethostname() function) and/or resolve from Wireshark specific configuration files. For details about the configuration files Wireshark uses for name resolution and alike, see Appendix B, Files and Folders.
The name resolution feature can be enabled individually for the protocol layers listed in the following sections.
Name resolution can be invaluable while working with Wireshark and may even save you hours of work. Unfortunately, it also has its drawbacks.
Name resolution in the packet list is done while the list is filled. If a name can be resolved after a packet is added to the list, its former entry won’t be changed. As the name resolution results are cached, you can use→ to rebuild the packet list with the correctly resolved names. However, this isn’t possible while a capture is in progress.
Try to resolve an Ethernet MAC address (e.g. 00:09:5b:01:02:03) to something more “human readable”.
ARP name resolution (system service): Wireshark will ask the operating system to convert an Ethernet address to the corresponding IP address (e.g. 00:09:5b:01:02:03 → 192.168.0.1).
Ethernet codes (ethers file): If the ARP name resolution failed, Wireshark tries to convert the Ethernet address to a known device name, which has been assigned by the user using an ethers file (e.g. 00:09:5b:01:02:03 → homerouter).
Ethernet manufacturer codes (manuf file): If neither ARP or ethers returns a result, Wireshark tries to convert the first 3 bytes of an ethernet address to an abbreviated manufacturer name, which has been assigned by the IEEE (e.g. 00:09:5b:01:02:03 → Netgear_01:02:03).
Try to resolve an IP address (e.g. 188.8.131.52) to something more “human readable”.
DNS name resolution (system/library service): Wireshark will use a name resolver to convert an IP address to the hostname associated with it (e.g. 184.108.40.206 → www.1.google.com).
DNS name resolution can generally be performed synchronously or asynchronously. Both mechanisms can be used to convert an IP address to some human readable (domain) name. A system call like gethostname() will try to convert the address to a name. To do this, it will first ask the systems hosts file (e.g. /etc/hosts) if it finds a matching entry. If that fails, it will ask the configured DNS server(s) about the name.
So the real difference between synchronous DNS and asynchronous DNS comes when the system has to wait for the DNS server about a name resolution. The system call gethostname() will wait until a name is resolved or an error occurs. If the DNS server is unavailable, this might take quite a while (several seconds).
To provide acceptable performance Wireshark depends on an asynchronous DNS library to do name resolution. If one isn’t available during compilation the feature will be unavailable.
The asynchronous DNS service works a bit differently. It will also ask the DNS server, but it won’t wait for the answer. It will just return to Wireshark in a very short amount of time. The actual (and the following) address fields won’t show the resolved name until the DNS server returns an answer. As mentioned above, the values get cached, so you can use→ to “update” these fields to show the resolved values.
hosts name resolution (hosts file): If DNS name resolution failed, Wireshark will try to convert an IP address to the hostname associated with it, using a hosts file provided by the user (e.g. 220.127.116.11 → www.google.com).
Try to resolve a TCP/UDP port (e.g. 80) to something more “human readable”.
TCP/UDP port conversion (system service): Wireshark will ask the operating system to convert a TCP or UDP port to its well known name (e.g. 80 → http).