Wireshark · Ethereal-dev: Re: [Ethereal-dev] Regarding Memory allocation

["harshas" <harshas@xxxxxxxxxxxxxxxxxxx>]

Hello sir,
  I want to display the contents of the hex byte in form of protocol tree.I
could able to print it in the form of hex  and decimal.But I want to print
the value of hex byte
  getting from the tvbuff in the form of bits.(FF = 1111 1111 ) and so on.
    Is there ant method to print in the protocol tree the binary values of
the hex byte.?If so please tell me which routne to use ?
    Regards
         harsha

----- 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
>