User Guide

Advanced Topics
127
Tip!
The name resolution in the packet list is done while the list is filled. If a name could be
resolved after a packet was added to the list, that former entry won't be changed. As the name
resolution results are cached, you can use "View/Reload" to rebuild the packet list, this time
with the correctly resolved names. However, this isn't possible while a capture is in progress.
7.7.2. Ethernet name resolution (MAC layer)
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).
7.7.3. IP name resolution (network layer)
Try to resolve an IP address (e.g. 216.239.37.99) to something more "human readable".
DNS/concurrent DNS name resolution (system/library service): Wireshark will ask the operating
system (or the concurrent DNS library), to convert an IP address to the hostname associated with it (e.g.
216.239.37.99
→
www.1.google.com). The DNS service is using synchronous calls to the DNS server.
So Wireshark will stop responding until a response to a DNS request is returned. If possible, you might
consider using the concurrent DNS library (which won't wait for a name server response).
Warning!
Enabling network name resolution when your name server is unavailable may significantly
slow down Wireshark while it waits for all of the name server requests to time out. Use
concurrent DNS in that case.
DNS vs. concurrent DNS: here's a short comparison: Both mechanisms are used to convert an IP address
to some human readable (domain) name. The usual DNS call 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 DNS and concurrent 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).
The concurrent 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 View/Reload 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. 216.239.37.99
→
www.google.com).