On Sun, Nov 18, 2001 at 09:17:34AM +1100, Ronnie Sahlberg wrote:
[...]
> > Should I add this to the smb_info_t, or the smb_saved_info_t, or
> > perhaps start breaking things out into a separate structure of its own
> > like smb_ntcreate_info_t?
>
> Please if possible try to keep smb_info as small as possible. It affects the
> runtime requirement of ethereal and thethereal.
Yes - I can see the memory requirements for this adding up quickly for
large captures.
> If possible, reuse an existing varialbe in that structure which is not
> relevant for msrpc or create a union.
Why not create a per subcommand union in the smb_info structure? The
fid is only used in tracking smbtrans calls.
> (does msrpc use the subcmd or info_level ? if not, perhaps one of these can
> be reused)
It uses neither. Better to make this into a union than overload the
value - too confusing.
> Also, please keep an eye on the CVS traffic. There will probably be from
> time to time some small changes to the
> smb_info structures to remove redundant information and to lower the size
> and memory impact of it.
Sure.
> Perhaps the smb_info handling should be changed as Guy suggested to just
> contain frame_req/frame_res and
> a void * to point to protocol specific data.
This is kind of what I have done in another patch to the dcerpc code.
I've created a protocol specific private info structure which contains
a union:
#define DCERPC_TRANSPORT_SMB 1
typedef struct _dcerpc_private_info {
int transport_type; /* Tag */
union {
struct { /* TRANSPORT_SMB */
guint16 fid;
} smb;
} data;
} dcerpc_private_info;
The dissect_pipe_msrpc() function creates one of these before invoking
the dcerpc dissector:
dcerpc_private_info dcerpc_priv;
smb_info_t *smb_priv = (smb_info_t *)pinfo->private_data;
dcerpc_priv.transport_type = DCERPC_TRANSPORT_SMB;
dcerpc_priv.data.smb.fid = smb_priv->fid;
pinfo->private_data = &dcerpc_priv;
<call msrpc dissector>
pinfo->private_data = smb_priv;
The smb private data is restored (not sure whether this is necessary
but it may stop a memory leak?
> Apart from that, cool. Does this mean we will see some msrpc command
> dissectors?
Yep - I have been working on one for the spoolss system as this is
what I need to analyse some printer driver bugs I have been looking at.
I've started on the lsa dissector as an example.
> 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.
Tim.
