Subject: Re: [Ethereal-dev] SMBpatch for read/write and x
Hi,
From: "Tim Potter"
Sent: Thursday, November 29, 2001 7:27 AM
Subject: Re: [Ethereal-dev] SMBpatch for read/write and x
> On Wed, Nov 28, 2001 at 12:51:59PM +0000, Pia Sahlberg wrote:
[snip]
> > I assume this is some optimization, if dissecting in the tree under the
> > protocol branch: proto_pipe, then ONLY check hf_index entries
> > registred for proto_pipe and ignore anything else.
>
> But if I type in "smb" as a filter string (a good trick btw) I get
> all smbs and all msrpc transactions. By your reasoning above I should
> only get the SMB transactions and not the msrpc ones?
No, smb will find everything since SMB is part of the top tree.
However, what I mean is that the tree looks like :
...
SMB ( created by proto_tree_add_protocol(proto_smb) )
smb-stuff ( created by proto_tree_add_item() )
PIPE ( created by proto_tree_add_protocol(proto_pipe) )
pipe-stuff (created by proto_tree_add_item() )
By searching for SMB you will find everything since SMB is the protocol
item
at the first level in the tree.
However, when dissecting the packets (say a ...->smb->pipe packet) and the
dissector gets to dissect-smb-pipe()
then it will do a proto_tree_add_protocol(proto_pipe) which causes the
display filter matching stuff it to temporarely forget
all about smb stuff, and only concentrate on hf_pipe_xxx
(since we are now dissecting inside the proto_pipe protocol)
I assume it is an optimization, when inside proto_X, only look at hf_X when
matching display filters (we have quite a number of displayfilters now)
Perhaps the displayfilter stuff should always scan ALL hf_variables (speed
up smb which holds ~10% of them?)
and be made to handle that?
Say a fast and simple hash that produces values 0-255 (xor of all bytes in
name is fast and simple) which gives us a table between0-255
the table then stores pointers to binary trees, one tree per hash
value.Store the display filter entries matching the hash in the
corresponding
tree. Since these trees are static, we only build the trees when the
application is starting, thus runtime is not really critical, thus we could
also make sure that the trees are perfectly balanced for furter
optimization.
Then we change the display filter stuff to always look through ALL hf_x
fields and not only a subset.
Another thing to put in the TODO list for some unknown future...
Have you tried my proposed workarund i described in the previous mail?
