Guy Harris <gharris@xxxxxxxxx> writes:
>
> Nope - you're just slicing some data off, rather than rearranging it or
> modifying it, so you don't create a new data source.
>
> Once the SMB dissector is tvbuffified, that'd be done with
> "tvb_new_subset()"; for now, however, you have to do it with
> "tvb_create_from_top()", as "packet-smb-mailslot.c" does.
>
Excellent. I've done that, and it works.
Next issue: conversation support for SMB. The dcerpc dissector needs
to keep track of some things per conversation. It's doing this just
fine for TCP and UDP. The problem is that the conversation stuff
doesn't support SMB 'conversations'. The scenario where it will break
down at present is this:
Client connects to server on port 139.
Client opens named pipe \lsarpc.
Client does dcerpc over that named pipe.
Client opens named pipe \samr.
Client does dcerpc over this new named pipe.
Now, without some support for SMB in the conversation stuff, dcerpc is
going to think it's all one TCP conversation, when it's really two SMB
conversations. I think that we might be able to use the SMB file/pipe
number as the 'port' of the conversation, but I haven't looked into
the conversation stuff too deeply. Anyone more familiar with it care
to render advice?
Todd