Ulf Lamping <ulf.lamping@xxxxxx> writes:
> 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.
You shouldn't rely on the alloc hint, at all. Not only can it be
zero, it can be a completely bogus value, as well. It is, as the name
says, just a hint. Hints can be wrong, and ethereal shouldn't fail if
they are.
I'm not that familiar with the defragmentation stuff in ethereal, but
the 'simple' approach you describe sounds right to me. I don't think
the DCE/RPC layer is the place to worry about packets being out of
order or retransmitted. If you want to work correctly in those cases,
the TCP dissector should handle them, no?
Todd
--
Todd Sabin <tsabin@xxxxxxxxxxxxx>