Ethereal-dev: Re: [Ethereal-dev] Found a defragmentation "bug" in the DCE RPC dissector
That sounds like a good approach.
Something similar will be required for HTTP as well since many/several
protocols/implementations atop HTTP never add a content-length field
(which will require us to reassemble until we see a FIN or RST tcp
segment).
May i ask what implementation of dce/rpc never provides an alloc-hint?
afaik ms implementation always provide it and other implementations
are very rare today.
On Tue, 18 Jan 2005 21:37:25 +0100, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> Hi List!
>
> I think I've found a bug in the DCE-RPC dissector, and I already have a
> possible bugfix for it.
>
> The problems is caused, as the logic of connection oriented
> defragmentation is based on the "alloc hint" field. Unfortunately, the
> spec says this field can simply contain a 0 indicating that the
> transmitting side doesn't want to give a hint.
>
> This causes the current defragmentation logic (epan/packet-dcerpc.c
> starting at line 2821) to think that not all fragments are received, and
> will not defragment it.
>
> A bugfix might be: if the "alloc hint" field is zero, simply append the
> fragments one by one to the "fragment list" until a last fragment is
> found. This simple approach is depeding on the right order of the
> fragments and might fail, if the underlying TCP get's confused about
> retransmissions or the DCE RPC implementation itself is buggy.
>
> Someone got a better idea to handle this?
>
> Regards, ULFL
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
