On Tue, Feb 27, 2001 at 10:49:55AM +0600, Diwakar Shetty wrote:
> Ethereal has a dissector for PPP which is dissect_ppp( ).
> However, this dissector does not handle VJ (i.e Van Jacobson)
> compressed packets as of now.
>
> So we are in the stage of adding this capability.
>
> Our algorithm for uncompressing expands the data pointer passed to it.
> (uses memove( ) on "data_ptr" for that)
> e.g: vj_uncompress(char *data_ptr);
>
> However ethereal's function pointer for dissector requires a const
> char*. Not only that but another issue is frame_data.
> e.g: dissect_vjuc(const u_char *pd, int offset, frame_data *fd,
> proto_tree *tree)
New dissectors added to Ethereal should not have a calling sequence like
that; instead, they should be
dissect_vjuc(tvbuff_t *tvb, int offset, packet_info *pinfo,
proto_tree *tree)
See the "README.developer" and "README.tvbuff" documents in the "doc"
subdirectory.
> Of course, ultimately, dissect_vjuc( ) will call vj_uncompress( ) to do
> the actual decompression.
>
> The following are the main doubths:
> 1) Can I ignore the "const char*" declrn. and force the data pointed to
> by "pd" to change.
No. You must not change the data handed to the dissector.
In fact, as noted, in Ethereal, only dissectors that have not yet been
converted to use tvbuffs get data directly handed to them; all other
dissectors - including the PPP dissector - get handed a "tvbuff", which
they should access indirectly, through routines that do bounds checking.
> 2) Do I have to take in account "frame_data *fd". Anyway what is the
> significance of this "frame_data *fd"
It's information made available to the dissector; it would not be used
when uncompressing data.
> 3) Is there any other elegant solution?
No.
Ethereal currently doesn't have a good infrastructure for handling the
case where the data being dissected is different from the raw data in
the packet (whether because the data in the packet is compressed or
whether it's encrypted).
This means, for example, that you could not conveniently specify offsets
in "proto_tree_add()" calls that refer to offsets in the *uncompressed*
data (or decrypted data, unless the encryption is byte-for-byte),
because offsets refer to the raw packet data. (No, changing the raw
packet data, as you note above, won't help.)
This may be fixed in the future, by having the bottommost pane, showing
the hex data, be a "notebook" widget, with one or more pages - the
default page would contain the raw packet data, but other pages would
contain uncompressed or decrypted data. The uncompressing or decrypting
code would have to construct a new tvbuff, containing the uncompressed
or decrypted data, and pass that to routines that would dissect it.
However, none of the infrastructure to do that currently exists. Thus,
you may find it prohibitively difficult to implement dissection of VJC
packets at present.
