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
>
