1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
|
<!-- EUG Chapter Advanced -->
<!-- $Id: -->
<chapter id="ChapterAdvanced">
<title>Advanced Features</title>
<section id="ChAdvIntroduction"><title>Introduction</title>
<para>
In this chapter some advanced features of Ethereal will be described.
</para>
</section>
<section id="ChAdvFollowTCPSection"><title>Following TCP streams</title>
<para>
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.
</para>
<para>
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
<xref linkend="ChAdvFollowStream"/>.
</para>
<section><title>The "Follow TCP stream" dialog box </title>
<figure id="ChAdvFollowStream">
<title>The "Follow TCP Stream" dialog box</title>
<graphic entityref="EtherealFollowStream" format="PNG"/>
</figure>
<para>
You can choose from the following actions:
<orderedlist>
<listitem>
<para>
<command>Save As</command> Save the stream data in the currently
selected format.
</para>
</listitem>
<listitem>
<para>
<command>Print</command> Print the stream data in the currently
selected format.
</para>
</listitem>
<listitem>
<para>
<command>Direction</command> Choose the stream direction to be
displayed ("Entire conversation", "data from A to B only" or "data
from B to A only").
</para>
</listitem>
<listitem>
<para>
<command>Filter out this stream</command> Apply a display filter
removing the current TCP stream data from the display.
</para>
</listitem>
<listitem>
<para>
<command>Close</command> Close this dialog box.
</para>
</listitem>
</orderedlist>
</para>
<para>
You can then choose to view the data in one of four formats:
<orderedlist>
<listitem>
<para>
<command>ASCII</command>. 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.
</para>
</listitem>
<listitem>
<para>
<command>EBCDIC</command>. For the big-iron freaks out there.
</para>
</listitem>
<listitem>
<para>
<command>HEX Dump</command>. This allows you to see all the
data, but you lose the ability to read it in ASCII.
</para>
</listitem>
<listitem>
<para>
<command>C Arrays</command>. This allows you to import the stream data
into your own C program.
</para>
</listitem>
</orderedlist>
</para>
<note>
<title>Note!</title>
<para>
It is worthwhile noting that Follow TCP Stream installs a filter
to select all the packets in the TCP stream you have selected.
</para>
</note>
</section>
</section>
<section id="ChAdvReassemblySection"><title>Packet Reassembling</title>
<section><title>What is it?</title>
<para>
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.
</para>
<para>
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.
</para>
<tip><title>Tip!</title>
<para>
Ethereal calls this mechanism reassembling, although a specific protocol
specification might use a different term for this.
</para>
</tip>
</section>
<section><title>How Ethereal handles it</title>
<para>
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 <xref linkend="ChUsePacketBytesPaneSection"/>.
</para>
<note><title>Note!</title>
<para>
Reassembling might take place in several protocol layers, so it's possible
that multiple tabs in the "Packet Bytes" pane appear.
</para>
</note>
<note><title>Note!</title>
<para>
You will find the reassembled data in the last packet of the chunk.
</para>
</note>
<para>
An example:
In a <command>HTTP</command> 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.
</para>
</section>
<section><title>Reassembling is disabled!</title>
<para>
Reassembling is usually disabled in the preferences by default, as it
slows down packet processing a bit.
</para>
<para>
Enabling reassembling of a protocol typically requires two things:
<orderedlist>
<listitem>
<para>
the lower level protocol (e.g., TCP) must support
reassembly. Often this reassembly can be enabled or disabled
via the protocol preferences.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</orderedlist>
</para>
<para>
The tooltip of the higher level protocol setting will note you if and
which lower level protocol setting has to be considered too.
</para>
</section>
</section>
<section id="ChAdvNameResolutionSection"><title>Name Resolution</title>
<para>
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 <xref linkend="AppFiles"/>.
</para>
<para>
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.
</para>
<note><title>Note!</title>
<para>
You might see packets to/from your machine in your capture file, which are
caused by name resolution network services (e.g. DNS packets).
</para>
</note>
<note><title>Note!</title>
<para>
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.
</para>
</note>
<para>
The name resolution feature can be en-/disabled separately for the
following protocol layers (in brackets):
</para>
<section><title>Ethernet name resolution (MAC layer)</title>
<para><command>ARP name resolution (system service)</command>
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).
</para>
<para><command>Ethernet codes (ethers file)</command>
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).
</para>
<para><command>Ethernet manufacturer codes (manuf file)</command>
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).
</para>
</section>
<section><title>IP name resolution (network layer)</title>
<para><command>DNS/ADNS name resolution (system/library service)</command>
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).
</para>
<warning>
<title>Warning!</title>
<para>
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.
</para>
</warning>
<para>
<command>DNS vs. ADNS</command>
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.
</para>
<para>
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?
</para>
<para><command>hosts name resolution (hosts file)</command>
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).
</para>
</section>
<section><title>IPX name resolution (network layer)</title>
<para><command>ipxnet name resolution (ipxnets file)</command>
XXX - add ipxnets name resolution explanation.
</para>
</section>
<section><title>TCP/UDP port name resolution (transport layer)</title>
<para><command>TCP/UDP port conversion (system service)</command>
Ethereal will ask the operating system to convert a TCP or UDP port to
its well known name (e.g. 80 -> http).
</para>
</section>
</section>
</chapter>
<!-- End of EUG Chapter Advanced -->
|
