----- Original Message -----
From: "Guy Harris"
>
> 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.
Correct, but since IP reassembly will be a new application, IP reassembly
will have
to make sure that the entire IP packet has been received before passing it
to higher layer protocols. Same as toda, TCP/UDP dissectors are not called
until the entire packet is reassembled, i.e. no holes.
So, ip_add_fragment() would need to add the new tvbuff to the COMPOSITE,
then
also check if the entire range from 0 to ip.totlen has been mapped without
any holes.
The new rule for COMPOSITE : Anyone createing COMPOSITES which might
potentially
have holes in them must make sure that higher layer dissectors are not
called for this COMPOSITE
until sufficient data has been received.
>
> > 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.
See above.
> > 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);
>
> ?
tvb_get_ptr() will alloc() a lot of memory if tvb1 is a COMPOSITE.
I meant a special memcmp which can compare two tvbuffs one of
which might be COMPOSITE without doing tvb_get_ptr().
Well it has to do tvb_get_ptr() sooner or later, but it should never do
tvb_get_ptr() on COMPOSITE tvbuffs. In that case it needs to divide
the COMPOSITE into its underlying components (REAL/SUBSETs)
>
> > 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).
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev