Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] cvs commit: ethereal packet-smb.c smb.h

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
Date: Sun, 13 Apr 2003 14:49:23 +1000
----- Original Message -----
From: "Tim Potter"

> >   The DCERPC fragment reassembly in the dcerpc layer is still broken
> >   though, and i think it has been broken for quite some time.   That
> >   will be addressed shortly.
>
> Yes it has been broken for a while.  The last time I looked at it there
> were some serious issues with "middle" fragments among other things.
> The fragments were making it to the DCERPC dissector but no information
> was appearing in the protocol tree.

The problem is that the dcerpc fragment reassembly is using the frame id of
the
first frame for the fragment as a key/identifier for reassembly.
Since all fragments of a pdu start in different frames, reassembly can not
see they belong
to the same pdu.
It needs something that keeps track of conversations (+smb FID if
transported over SMB)
and keeps track of a suitable reassembley key that is unique between
different pdus but the same
for all fragments of the same pdu.
Ill probably implement it as using the frame where the FirstFragment was
first seen as the
reassembley key.
It should be pretty unlikely that we have multiple fragmented DCERPC pdu's
all starting in the same frame. But if this is seen as a problem further on
we can just enhance it to also look at context id, call id etc.


Though I have a clear memory of it working some time ago? so it might be
easy to fix it. we will see.

I know why it doesnt reassemble the pdu's but need to check the various
hashtables that are used first.
Since i belive it has worked previously it might already have the proper
hashtable implemented.



>
> Interestingly enough, I have developed a DCERPC testing tool for Samba
> that generates arbitrarily large request and response fragments.  There
> is client and server side code for Windows and Samba as well as an
> Ethereal dissector which I haven't checked in yet.  Interested?  I was
> using it to test Samba but it can just as easily be used to test
> Ethereal.

after i checkin the fix above in a few days, i would be interested in all
captures where
reassembly to fails.


>
>
> Tim.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev