["harshas" <harshas@xxxxxxxxxxxxxxxxxxx>]

Thank you,
      In my case of reading the packets.Packet reassembly is done.
      What I am doing is I am reading the packet in the form:
The file is a ready captured file.
/*   One line of message header     */
/* 'N' number of raw bytes of that  message */
Like this  'N' number of packets.
I am displaying the first line message (header info) in the first window of
the
ethereal and the corresponding raw bytes in the form of  charecter (say 'FF'
or 'FE' .'01' ) in the third window. I could do soo.
For displaying the message in first window I am calling the dissector once
while
 reading and ethereal displays the information as i want on both the first
and
the third window.
Next I  am accessing the byte value of message from the tvbuff and trying to
 decode it.I could able to do up to this.

For doing so ethereal takes few seconds to load the file into ethereal by
displaying the window of "loading the file".
If the number of messages in the file is more(say more than 1000) than
ethereal
 exits with seg fault.(I am using LINUX machine).
1. I feel LINUX machine somewhere fails to allocate such an ammount of
memory to the process in which ethereal is runing? is it so?
2. Do you feel it is the problem with my code?(It works upto 500 messages).
3. Sir I want to know why reassembly is done and what happens during
reassembling.?


regards
   Harsha


and so on
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxx>
To: "Ethereal development" <ethereal-dev@xxxxxxxxxxxx>
Sent: Friday, January 28, 2005 12:53 PM
Subject: Re: [Ethereal-dev] Regarding Memory allocation


> 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.h
tml
>
> 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.)
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>