harshas wrote:
Using ethereal I could read a captureed file with 'n' number
of packets (header and rawbytes).
1. My question is Ethereal dissection routine is called only when a
packet is selected randomly through seek_read routine.
No. When the file is first read in, the dissection routine is called
for *every* packet in the file. It's also called when:
a packet is selected randomly;
a packet is processed if you run a display filter;
a packet is processed when the display is being changed;
a packet is processed when the dissection is redone because a protocol
preference is changed;
etc.
The raw bytes present in the tvbuff will
be accessed and decoded. is it right?
Every time the dissectors are called for a packet, tvbuffs are
constructed for packet data, and they are accessed and decoded.
2. If so Every time a packet is selected randomly ethereal
dissector will get the corresponding raw bytes of the packet from tvbuff
. Whether the bytes are read from the captured file each time when seek
read is called or all the bytes of all the packets are read once during
the file read?.
During the file read, all the bytes of all the packets are read, and a
tvbuff is constructed from the packet data.
After the file has been read, for each packet that's processed by
whatever processing is done, the bytes of the packet are read, and a
tvbuff is constructed from the packet data. (If, for example, the data
in all the packets is being printed, all the bytes of all the packets
are read; that's done with the seek_read routine, but, in effect, it's
sequential, not random, in that particular case.)
3. If read once during the file read How the raw bytes of the
individual packets are stored?
They're stored only in the file. They are not stored in memory.
When packet reassembly is done, the reassembled bytes are *currently*
stored in memory. However, there is no guarantee that this will
continue to be the case.
Dissectors should make no assumptions about the persistence of the data
in the packets. They should assume that any data in the tvbuff they are
supplied might not be in memory after the dissector returns.
(See
http://www.moma.org/collection/depts/paint_sculpt/blowups/paint_sculpt_016.html
for information on The Persistence of Memory. :-))
If the number of packets and the
corresponding bytes are more will ethereal gives any overflow message?
As the raw packet data from the file isn't stored in memory, there won't
be an overflow for that data. There might be an overflow for packet
data if reassembly is done; unfortunately, as the memory allocation is
done with GLib's "g_malloc()", the "overflow message" is an abort
message when the program crashes. (We should probably figure out a
general way of handling out-of-memory conditions, and not use
"g_malloc()". Unfortunately, many of the GLib data structures, such as
hash tables, used by dissectors *also* use "g_malloc()", so changing the
dissectors not to use "g_malloc()" won't completely protect us from
those aborts - and, as GTK+ also uses "g_malloc()", even ceasing to use
any of the GLib data structures and routines that use "g_malloc()" won't
completely protect Ethereal from those aborts.)
