In this chapter some advanced features of Ethereal will be described.

There will be occasions when you would like to see the data from a TCP session in the order that the application layer sees it. Perhaps you are looking for passwords in a Telnet stream, or you are trying to make sense of a data stream. If so, Ethereal's ability to follow a TCP stream will be useful to you. Simply select a TCP packet in the stream/connection you are interested in and then select the Follow TCP Stream menu item from the Ethereal Tools menu. Ethereal will pop up a separate window with all the data from the TCP stream laid out in order, as shown in .

You can choose from the following actions: Save As Save the stream data in the currently selected format. Print Print the stream data in the currently selected format. Direction Choose the stream direction to be displayed ("Entire conversation", "data from A to B only" or "data from B to A only"). Filter out this stream Apply a display filter removing the current TCP stream data from the display. Close Close this dialog box. You can then choose to view the data in one of four formats: ASCII. In this view you see the data from each end in ASCII, but alternating according to when each end sent data. Unfortunately, non-printing characters do not print. EBCDIC. For the big-iron freaks out there. HEX Dump. This allows you to see all the data, but you lose the ability to read it in ASCII. C Arrays. This allows you to import the stream data into your own C program. It is worthwhile noting that Follow TCP Stream installs a filter to select all the packets in the TCP stream you have selected.

Often network protocols needs to transport large chunks of data, which are complete in itself, e.g. when transferring a file. The underlying protocol might not be able to handle that chunk size (e.g. limitation of the network packet size), or is stream-based like TCP, which doesn't know data chunks at all. In that case the network protocol has to handle that chunks itself and (if required) spreading the data over multiple packets. It also needs a mechanism to find back the chunk boundaries on the receiving side. Ethereal calls this mechanism reassembling, although a specific protocol specification might use a different term for this.

For some of the network protocols Ethereal knows of, a mechanism is implemented to find, decode and display this chunks of data. Ethereal will try to find the corresponding packets of this chunk, and will show the combined data as additional pages in the "Packet Bytes" pane, see . Reassembling might take place in several protocol layers, so it's possible that multiple tabs in the "Packet Bytes" pane appear. You will find the reassembled data in the last packet of the chunk. An example: In a HTTP GET response, the requested data (e.g. a HTML page) is returned. Ethereal will show the hex dump of the data in a new tab "Uncompressed entity body" in the "Packet Bytes" pane.

Reassembling is usually disabled in the preferences by default, as it slows down packet processing a bit. Enabling reassembling of a protocol typically requires two things: the lower level protocol (e.g., TCP) must support reassembly. Often this reassembly can be enabled or disabled via the protocol preferences. the higher level protocol (e.g., HTTP) must use the reassembly mechanism to reassemble fragmented protocol data. This too can often be enabled or disabled via the protocol preferences. The tooltip of the higher level protocol setting will note you if and which lower level protocol setting has to be considered too.

Name resolution tries to resolve some of the numerical address values to human readable names. 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. If there are both features available, Ethereal will first try the system services and then fall back to it's own configuration files. XXX - is this really true? For details about the configuration files Ethereal uses for name resolution and alike, see . However, be prepared that this conversion often will fail, e.g. the name to be resolved might simply be unknown by the servers asked and the configuration files. You might see packets to/from your machine in your capture file, which are caused by name resolution network services (e.g. DNS packets). 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 another machine. The name resolution feature can be en-/disabled separately for the following protocol layers (in brackets):

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 IETF (e.g. 00:09:5b:01:02:03 -> Netgear_01:02:03).

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). 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. XXX - what does happen with the actual address field at that run? Will the response be ignored for that field? 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.

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).