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.

XXX - rework this chapter, as it's still a bit confusing.

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. Desegmenting is a slightly different mechanism compared to reassembling, but doing the same thing. Both mechanisms combine traffic back together, in this chapter only the term reassembling will be used.

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. Some examples: 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. A DCE-RPC (Remote Procedure Call) client send a request to the server and expects a response back from it. Both the request and the response is a complete chunk of data and will be shown as a new tab "Reassembled DCE/RPC" 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 at will 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. As a result, if reassembly of protocol Y on top of protocol X must be enabled, it is wise to take a look at the protocol preferences for both protocols. Check whether protocol X allows subdissectors to reassemble, and check whether protocol Y supports reassembly and has it enabled. For example: if you have HTTP on top of TCP, you have to enable the TCP preference "Allow subdissectors to reassemble" and enable the HTTP preference "Reassemble".

Name resolution tries to resolve some of the address values to human readable names. This conversion might fail, e.g. if the specific name is just unknown. Some of the lookups are done with data from your local machine, while others asking network services like DNS. XXX - add ipxnets name resolution explanation. 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:

ARP name resolution Convert an ethernet address to the corresponding IP address (e.g. 00:09:5b:01:02:03 -> 192.168.0.1). Ethernet manufacturer codes If the ARP name resolution failed, 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 name resolution Convert an IP address to the hostname associated with it (e.g. 65.208.228.223 -> www.ethereal.com). Enabling network name resolution when your name server is unavailable may significantly slow Ethereal while it waits for all of the name server requests to time out. Use ADNS in that case.

TCP/UDP port conversion Convert a TCP or UDP port to its well known name (e.g. 80 -> http).

As noted, DNS lookups can significantly slow down Ethereal and make it appear frozen, which can be very annoying. To solve this, Ethereal can use the ADNS library, which handles DNS calls asynchronously.