["Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>]

I just grepped the Ethereal source tree for COMPOSITE and it seems none of
the
dissectors in standard ethereal even use COMPOSITE tvbuffs.
So holes would not be an issue if they were introduced in standard ethereal
since only COMPOSITE would
be affected and none uses COMPOSITE.

Does your h323-ethereal dissectors create and use COMPOSITE tvbuffs?
Do you know of any other forked/related projects which use COMPOSITE
tvbuffs?
If not, perhaps it would be safe to change COMPOSITE in this way.

A greater worry is perhaps tvb_get_ptr() lots of dissectors use this one,
what if there are holes and tvb_get_ptr() unexpectedly returns NULL?
I bet that about zero number dissectors check the return value from that
function.

But perhaps, if COMPOSITE tvbuffs isnt used at all at the moment, there
would be no breakage
and everything would be fine.
It would though need a README.tvbuff.important file which described how the
new COMPOSITE tvbuff type
worked and why one would have to be careful in using it, else bad things
happens...


Regardless of what implementation to use, I think I understand how this
entity would access the underlying sub-tvbuff's
regarding order of access and what required types of operations. Right now I
will focus on an efficient implementation of a tree to store the
sub-tvbuffs and perhaps, when I finish this in a week or five or whatever,
perhaps the usage of the higher layers as tvbuff types and
usage has cleared. (The subconsious is a great thing, think of something,
forget it, and pling!, suddenly the correct solution to your
problem appears as out of nowhere).


Another required function, which probably all users of new-composite would
need is :
tvb_memcmp(tvb1,offset1,tvb2,offset2,len)
This would be required to maintain the current functionality of IP
Reassembly, and would probably also be required for TCP stream tracing
since we would need to know if overlapping tcp-segment contained
different/conflicting data.
Now, with both searchable warning flags when overlapping IP fragments data
conflicts, and also searchable warning flags when overlapping
tcp-segments have data conflicts, this would realle be k-a functionality,
close to what IDS systems offers.
Well honestly, the only thing I care of is what got me toying with ethereal
in the first place, rightclick on a nfs-packet, select from menu
:"SaveNFSFileAs..."
IP reassembly was the first step, now the same for TCP (so TCP: NFS
read/write commands split over several tcp-segments can be combined
into a bigger tvbuff for the entire (16/32k) tcp-rpc-nfs-read/write call.
These tvbuffs defragments/desegments into a single rpc read/write tvbuff.
These new tvbuffs can then once again be combined, this time to form a
nfs-file-content tvbuff. This is my vision. This is what I would think would
be cool, the
rest are just side-effects.

Best regards
    ronnie sahlberg

----- Original Message -----
From: <andreas.sikkema@xxxxxxxxxxx>
To: <ethereal-dev@xxxxxxxxxxxx>
Sent: Wednesday, May 23, 2001 5:35 PM
Subject: Re: [Ethereal-dev] RFC: new TVBUFF type


> Would something break?

Certainly ;-)

I think all ASN.1 based protocols will be almost impossible to
dissect if there are holes.

--
Andreas Sikkema
andreas.sikkema@xxxxxxxxxxx
"While you're waiting, read the free novel we sent you.
 It's a Spanish story about a guy named `Manual'" - Dilbert


_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev