Advanced FeaturesIntroduction
In this chapter some advanced features of Ethereal will be described.
Following TCP streams
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
.
The "Follow TCP stream" dialog box
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.
Note!
It is worthwhile noting that Follow TCP Stream installs a filter
to select all the packets in the TCP stream you have selected.
Packet ReassemblingWhat is it?
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.
Tip!
Ethereal calls this mechanism reassembling, although a specific protocol
specification might use a different term for this.
How Ethereal handles it
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 .
Note!
Reassembling might take place in several protocol layers, so it's possible
that multiple tabs in the "Packet Bytes" pane appear.
Note!
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 disabled!
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
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.
Note!
You might see packets to/from your machine in your capture file, which are
caused by name resolution network services (e.g. DNS packets).
Note!
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):
Ethernet name resolution (MAC layer)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).
IP name resolution (network layer)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!
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).
IPX name resolution (network layer)ipxnet name resolution (ipxnets file)
XXX - add ipxnets name resolution explanation.
TCP/UDP port name resolution (transport layer)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).