Hi,
At 06:07 PM 5/5/01 +1000, Ronnie Sahlberg wrote:
>Hi,
>Has anyone looked at the dissectors for SMB?
I have looked at it many times ...
>I did a few days ago, and checked a few packets with the CIFS draft.
>There are, as I see it, several major problems with the SMB dissector.
So, you don't like my work ... :-)
>1, old style
Yes, it was written a long time ago now. Indeed, it was generated from a
packet description with a Perl script, and I have looked at doing it again,
but continue to run out of time.
>2, incomplete: no smb.file.name=="sdfsdf" or similar display filters
>supported.
Yes, this stuff was added well after I produced the code ...
>Almost no of the fields have search filter names.
Indeed, again, it was written a long time ago.
>No attempts are made to properly dissect the parameter block(s)
Which parameter blocks ... The whole SMB protocol is HUGE.
>No attempts are made to properly dissect the data block(s)
Which data blocks?
>3, broken, some the commands I looked at dissected the SMB packet
>incorrectly.
Hmmm, which ones are broken?
You also missed a few more:
4. Does not handle UNICODE at all
5. Does not put useful stuff in the info field in the first pane ...
>So, what should be done? Perhaps we should just throw out the existing smb
>dissectors and
>start again from scratch. making it properly tvbuffified, and layered in the
>process.
Well, I would like to start again from scratch and re-do my dissector
generator to pick up the problems I missed the first time around.
>My suggestion is to reimplement the entire smb dissector from scratch.
>rewriting packet-smb.c to only dissect the smb header from Protocol[] to and
>including Mid.
Well, it is going to be a lot of work doing it by hand.
>On top of this, one can then add higher layer dissectors, one for each
>command,
Ummm, the SMB protocol is not a separate protocol for each command. The
commands properly belong to the SMB protocol, and then there are other
protocols layered on top of the SMB protocol, like MSRPC and the browsing
protocol, RAP, and so on ...
>which dissects the patameters and data blocks for all the individual
>commands.
>
>
>I think that if packet-smb was reimplemented to only dissect the smb header,
>but doing that properly
>and killing all other smb code would not reduce functionality in ethereal.
>With a new packet-smb.c one could then add higher layer dissectors, one by
>one, for the parameter and
>data block for the commands, like TRANS2_FIND_FIRST2 (which currently is
>broken in such a way as it is
>useless, same for the other TRANS2 commands.)
>
>This will be a lot of work, but by splitting the work up in two layers we
>can have several contributors working
>simultaneously on the task.
>First (a rather small) packet-smb.c which only dissects the smb header.
>Then several (one for each command) packet-smb-xxx.c files which can be
>implemented concurrently.
I would rather see some progress on a program that can take a description
for the SMB protocol and produce a complete dissector from it ...
Unfortunately, I have never had the time to complete such a thing ...
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx
Samba (Team member, www.samba.org), Ethereal (Team member, www.ethereal.com)
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba
