Hi,
Ok I have thought some on this and this is what I came up with
(there are tricky areas so dont expect a patch today or tomorrow, more brain
needs to be applied first)
SMB Transaction (Transaction, Transaction2, NT Transaction (will ignore NT
transaction for now))
basically has two different modes of fragmentation
For non-DCERPC usage fragmentation is a follows:
requests:
First packet: Transaction
Remaining packets: Transaction Secondary (easy to add to ethereal,
looks a lot like Transaction)
First observation is that Transaction Secondary is really just a
continuation of the Transaction request
and will use the same MID. Similar to how NT-Cancel works we need to
make this an exception in when we match
requests to responses. A reasonably clean way is to break out
NT-Cancel from the main if-statement and
handle it separately and then extend it to also match
Transaction{2|NT} secondary.
These packets are matched based on the MID value.
responses:
All packets are Transaction responses.
This should be fairly easy to handle.
For DCE_RPC calls:
requests:
First packet: Transaction
Remaining Packets: WriteAndX
Ops. Here we use WriteAndX to add the remaining bytes for the
data-field.
Here we match using FID instead of MID (since MIDs will be
different?)
Leach and SNIA does not specify what values this call will use for
file offset or any of the other
fields. A capture with such transactions would be greatly
appreciated.
responses:
First packet: Transaction
Remaining packets: ReadAndX.
Same issues as for the requests.
So, the issue is first to figure out exactly how the Read/Write-AndX
paramters looks like.
Also I dont want to do anything that makes it difficult to add further
features.
(Read/Write-AndX are of course candidates for stuff like File-reassembly and
such)
Observation: For a fully reassembled DCERPC call, it would not make sense to
show the
DCERPC call for the WriteAndX packets (correct me if you think I am wrong)
but only
for the first Transaction call.
Should the DCERPC dissector be called and displayed in the tree for every
packet containing fragments
of the DCERPC call or only the initial Transaction call?
One other thing that might require potential changes is the reassembly.
I havent looked at it lately but initially one had to supply LastFragment as
a flag when adding
a fragment. This will not work for Read/Write-AndX since we can then not
determine from the fragments
if it is the last or not.
We need (if it doesnt exist already) a method to specify a fixed length when
creating the reassembly so we use
that one instead of the LastFragment flag. This would probably be quite easy
to add.
I think the order of tasks to complete this would be
1, fix dissect_smb() to clean up NT-Cancel and also make it handle the three
secondary transaction calls in exactly the
same way. (easy)
2, patch up dissect_transaction_request/response() to also handle the very
similar Transaction[2] Secondary calls. (easy)
3, (difficult) patch Transaction reassembly so it can do reassembly on the
data-area regardless if the remaining data is
inside another transaction [secondary] or inside a read/writeandx call.
I have capture where the response is divided inside multiple Transaction
response calls.
I would LOVE to get my hands on a capture which shows Transaction Secondary
calls.
(can be created by setting huge EA attributes to a file?)
I would also LOVE to get a capture containing WriteAndX calls. Though I can
probably create such myself
if I really need to.
----- Original Message -----
From: "Tim Potter
Subject: Re: [Ethereal-dev] [PATCH] fid tracking
> On Mon, Nov 19, 2001 at 10:49:34AM +1100, Tim Potter wrote:
>
> > OK this is where it gets complicated. Small DCERPC requests and
responses
> > (under 5620 bytes I think) are sent using a single SMBtrans. For larger
> > requests and responses the DCERPC packet is fragmented and the fragments
> > are sent using SMBreadX or SMBwritex. The only way to link these
together
> > is by the FID which is the same in the SMB{read,write}X packets as it is
> > in the SMBtrans packets. I guess if you see the packets out of order
then
> > you have to do some tricky stuff in your defragmenter but that's OK.
>
> One thing I forgot to mention - to determine whether a DCERPC packet
> is fragmented, the error in the SMB header is set to 0x80000005
> (STATUS_BUFFER_OVERFLOW) in the case of some pipes or ERROR_MORE_DATA
> for others. There's also some information in the DCERPC header of
> the first packet. Look at the flags and the fragment offset field.
> Note that there can be DCERPC fragmentation as well as SMB fragmentation
> which is why you will probably see the first and last fragment set in
> a packet header but the packet spans multiple SMB packets.
>
>
> Tim.
