Name resolution tries to resolve some of the numerical address values into a human readable format. There are two possible ways to do this conversations, depending on the resolution to be done: calling system/network services (like the gethostname function) and/or evaluate from Ethereal specific configuration files. For details about the configuration files Ethereal uses for name resolution and alike, see Appendix A, Configuration (and other) Files and Folders.
The name resolution feature can be en-/disabled separately for the protocol layers of the following sections.
Name resolution can be invaluable while working with Ethereal and may save you even hours of work. Unfortunately, it also has it's drawbacks.
Name resolution will often fail. The name to be resolved might simply be unknown by the name servers asked or the servers are just not available and the name is also not found in Ethereal's configuration files.
The resolved names are not stored in the capture file or somewhere else. So the resolved names might not be available if you open the capture file later or on a different machine. Each time you open a capture file it may look "slightly different", maybe simply because you can't connect a name server (which you could connect before).
DNS may add additional packets to your capture file. You may see packets to/from your machine in your capture file, which are caused by name resolution network services of the machine Ethereal captures from. XXX - are there any other such packets than DNS ones?
Resolved DNS names are cached by Ethereal. This is required for acceptable performance. However, if the name resolution information should change while Ethereal is running, Ethereal won't notice a change to the name resolution information once it's get cached. If this information changes while Ethereal is running, e.g. a new DHCP lease takes effect, Ethereal won't notice it. XXX - is this true for all or only for DNS info?
![[Tip]](graphics/tip.png) | 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. |
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) Ethereal 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, Ethereal 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 both ARP and ethers didn't returned a result, Ethereal tries to convert the first 3 bytes of an ethernet address to an abbreviated manufacturer name, which has been assigned by the IEC (e.g. 00:09:5b:01:02:03 -> Netgear_01:02:03).
Try to resolve an IP address (e.g. 65.208.228.223) to something more "human readable".
DNS/ADNS name resolution (system/library service) Ethereal will ask the operating system (or the ADNS library), to convert an IP address to the hostname associated with it (e.g. 65.208.228.223 -> www.ethereal.com). The DNS service is using synchronous calls to the DNS server. So Ethereal will stop responding until a response to a DNS request is returned. If possible, you might consider using the ADNS library (which won't wait for a network response).
![[Warning]](graphics/warning.png) | Warning! |
|---|---|
Enabling network name resolution when your name server is unavailable may significantly slow down Ethereal while it waits for all of the name server requests to time out. Use ADNS in that case. |
DNS vs. ADNS 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 ADNS 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 ADNS service will work a bit differently. It will also ask the DNS server, but it won't wait for the answer. It will just return to Ethereal in a very short amount of time. The actual (and the following) address fields won't show the resolved name until the ADNS call returned. 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, Ethereal will try to convert an IP address to the hostname associated with it, using an hosts file provided by the user (e.g. 65.208.228.223 -> www.ethereal.com).
ipxnet name resolution (ipxnets file) XXX - add ipxnets name resolution explanation.
Try to resolve a TCP/UDP port (e.g. 80) to something more "human readable".
TCP/UDP port conversion (system service) Ethereal will ask the operating system to convert a TCP or UDP port to its well known name (e.g. 80 -> http).
XXX - mention the role of the /etc/services file (but don't forget the files and folders section)!