On Mon, Apr 09, 2001 at 06:49:12AM +1000, Ronnie Sahlberg wrote:
> Other potential applications might be
> IPComp : show uncompressed packets as virtual ones.
> IPSec : If user has specified encryption keys, show decrypted packet as
> virtual.
At least in those two cases, there's an alternative - the stuff Jeff
Foster added to allow multiple "data sources" for a given packet.
You allocate a chunk of memory for the uncompressed/decrypted data and
create a new top-level tvbuff for it; in Ethereal, if the
currently-selected packet has multiple data sources, the hex dump pane
has multiple tabs, to select the different data sources - "Frame" is the
raw frame data, and the names of the other tabs are the names of the
other data sources, as assigned by the creator of the data sources.
See, for example, the Wellfleet compression protocol code (packet-wcp.c)
and the ICQ code (packet-icq.c) - the former shows the decompressed data
as another data source, and the latter shows the decrypted data as
another data source.
The protocol tree, in both cases, for the frame containing compressed or
encrypted data shows not only the part of the raw frame data that is
neither compressed nor encrypted, but also shows the contents of the
compressed or encrypted part, after decompression and decryption.
Selecting a field selects the notebook page for the data source whence
the data in that field came.
So, as long as there's no reassembly of any sort, you don't need virtual
frames to handle compressed or encrypted data - the regular non-virtual
frame can show the uncompressed or decrypted version of the data just fine.
