On Wed, May 23, 2001 at 09:10:28PM +1000, Ronnie Sahlberg wrote:
> I just grepped the Ethereal source tree for COMPOSITE and it seems none of
> the
> dissectors in standard ethereal even use COMPOSITE tvbuffs.
It's not a question of whether they *use* COMPOSITE tvbuffs, it's a
question of whether they *would be handed* a COMPOSITE tvbuff. Any
dissector for a protocol that runs atop IP, for example, could be handed
a COMPOSITE tvbuff, as you might have a reassembled fragmented IP
datagram.
> So holes would not be an issue if they were introduced in standard ethereal
> since only COMPOSITE would be affected and none uses COMPOSITE.
But they all might be handed it.
However, if the rule is
accessors throw an exception if *any* of the data they need is
missing, for *any* reason
then if a dissector tries to fetch stuff from a region that includes the
hole, an exception will be thrown - and any dissector that misbehaves if
an exception is thrown at any place where it calls an accessor is
*already* broken.
> 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?
It currently doesn't return NULL if there's missing data, it throws an
exception. That would not change if the data is missing because of a
hole rather than because, for example, not all of the data in a
link-layer frame was captured.
> Another required function, which probably all users of new-composite would
> need is :
> tvb_memcmp(tvb1,offset1,tvb2,offset2,len)
I.e. a wrapper that does
return memcmp(tvb_get_ptr(tvb1, offset1, len),
tvb_get_ptr(tvb2, offset2, len), len);
?
> 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.
Careful - nothing in NFS V3 specifies that 32K is a hard upper limit.
Sun have done some experiments with, as I remember, megabyte reads and
writes - and consider that somebody might try to screw up clients and
servers for ONC RPC-over-TCP based services by sending them a stream of
2-gigabyte fragments. Ethereal will probably have to set some sort of
upper limit (as I suspect most RPC-over-TCP implementations do; as I
remember, there's one in the NetApp implementation).
