Ethereal-dev: Re: [Ethereal-dev] [PATCH] fid tracking

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

From: "Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>
Date: Sun, 18 Nov 2001 15:20:43 +1100
Hi Tim, Hi List

----- Original Message -----
From: "Tim Potter"
Subject: Re: [Ethereal-dev] [PATCH] fid tracking

[snip]
> > You might be interested in this:
> > Some MSRPC calls are fairly large? right? larger than a SMB packet,
right?
> > I am looking right now into adding support to do defragmentation of
> > transaction calls
> > and will within a day or two create patches wich will add
defragmentation of
> > SMB Transaction calls.
>
> That would totally rock!  You don't have to have a very big msrpc
> request/response to hit the fragmentation limit at the moment.
>

I assume you know that ethereal already can desegment NBSS packets, that is
simply done by
enabling TCP desegmentation and NBSS desegmentation in preferences.
(NBSS desegmentation is ON by default, but TCP desegmentation must b
enabled)
Thisd gives you ~2-3kb PDUs when they hit the SMB layer.
Better than nothing.

I look into reassembly of Transaction (responses) as well. But there are a
few things I need to think through first.
To start with, only the responses to Transaction calls can be fragmented
(since requests does not have the
data/parameter displacement field, only responses have that one).
(Any idea of what Transaction[2] Secondary looks like and if it actually
exists in normal captures?)

For reassembly of Transaction responses I think I need to add the following:
*) Some sort of unique identifier to identify the PDU they belong to.
SMB->MID is not unique enough since it
is only 16bit and reused too often.
For this I think it might be nessecary to add some sort of
command-seq-number to smb_info that starts at 1 and is
incremented for each new SMB command which is seen.
*) As far as I see MSPRC does not use the parameter area for the transaction
call, only setup and data.
I assume setup is always reasonably small (as in a few bytes) so it does not
need reassembly.
Question: Will each fragmented transaction SMB contain an identical copy of
the setup data or is it only stored in
the first fragment?
If you could send me a capture or two with MSRPC PDUs spanning multiple SMB
Transaction
calls it would be a great help)
The parameter area is always(?) empty in MSRPC calls?
Only the data area needs defragmentation. When the data area is completely
defragmented, should if be supplied to PIPE/MSRPC
dissectors for each packet holding a fragment or would it be enough only to
call PIPE/SMPRC for
the packet containing the first fragment?

How does MSRPC handle fragmentation for the case where the request needs to
contain a lot of data?
Question since the Transaction call does not seemingly supply the means to
do fragmentation for requestsd, only responses.
Is this done in the DCERPC layer?

I have some Transaction2 captures which use fragmentation I will test the
code on.
Expect a test version in one or two days.


Tim, I see you post from +1100. Canberra I assume.
If you get past Sydney, gimme a yell and well have an ehtereal meeting over
a barbeque and a crate of VB.