Wireshark · Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 15744: /trunk/epan/dissectors/: packet-dcerpc.c /trunk/epa

[Ulf Lamping <ulf.lamping@xxxxxx>]

Guy Harris wrote:

> > What I've tried is to use the fragment total length as a way to keep 
> > the current offset in the fragment data. The end of the last fragment 
> > must be the offset of the next one. Assuming that the TCP dissector 
> > is working correct, this would be a simple model and should work 
> > well. Unfortunately, this doesn't work well with the reassemble code.
> >
> > Any ideas how to solve this in a better way? Do we have other 
> > dissectors doing a similar thing where I could have a look how I 
> > could solve this?
>
>
> If a (current) inability to handle out-of-order packets is OK for the 
> connection-oriented DCE RPC dissector, using fragment_add_seq_next() 
> would probably be the right way to do reassembly.
Regarding the TCP out-of-order problem: It won't be worse than before ...

I've implemented the DCE/RPC co defragmentation using 
fragment_add_seq_next(), both for request/response and fault PDUs.

Seems to be working well with req/resp, but I don't have a fragmented 
fault PDU, so can test that path :-(

Regards, ULFL