Comment # 8
on bug 8178
from Guy Harris
(In reply to comment #6)
> Rather than requiring the user to have to remember to specify filters in the
> form "same_subtree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel)",
> symantics should be added to for requesting these tools to filter in a way
> that treats a frame as one request or response tree.
Wireshark has no notion of "request or response trees"; it only has a notion of
a protocol tree. Not all protocols are request/response protocols.
So Wireshark can't process requests or responses in the filtering process.
It *can*, *if* a dissector for a protocol constructs separate *sub*trees for
each PDU/message/whatever and can mark those subtrees so that the filtering
engine (which, again, does not, and should not, have knowledge wired into it
about particular protocols - people should be able to add protocols to
Wireshark without having to hack the filtering engine) knows that, if a filter
specifies it, fields under it should be processed together, so that && and ||
and so on should be done only on fields in the same subtree, with the results
for all subtrees ORed together.
For SMB, SMB2, and NFSv4, it is not sufficient to have the nodes for the
protocol itself be the root nodes of those subtrees, as a single PDU can have
multiple requests or responses (AndX with SMB; compounded requests and
NextCommand with SMB2/SMB3; compound requests in NFSv4), so those dissectors,
and possibly others, would need to be modified to use whatever mechanism is
provided to tag subtrees in that fashion.
This would be done regardless of whether the fields are fields for the protocol
that marked the subtree or not - a message for that protocol may have subtrees
corresponding to some other protocol, and presumably, if you have multiple
XYZZY messages in a frame, and both of those XYZZY messages contain an ABCD
structure handled by the ABCD dissector, a filter such as
xyzzy.cmd == "Hello" && abcd.security_code == "Frob"
would, if requested to have the "process subtrees separately" semantics, be
intended to check for XYZZY "Hello" commands where the ABCD structure has a
security code of "Frob", and shouldn't succeed if the frame contains an XYZZY
"Hello" command where the ABCD structure has a security code of "Frobozz" and
an XYZZY "Wakeup" command where the ABCD structure has a security code of
"Frob".
However, that doesn't say what happens with && and || between a field
underneath one of those subtrees and a field *above* one of those subtrees, so
that leaves it unspecified how the filter
ip.addr == 17.201.41.9 && smb2.cmd == 5
be processed if fields that *do* appear under one of those subtrees are
supposed to be processed in this new fashion.
In addition, making that behavior the default behavior might break existing
filters - for example, filters where somebody's looking for an SMB2 message
with both a LOCK and a WRITE request - so it's not clear that making the new
behavior the default is the right thing to do.
You are receiving this mail because:
- You are watching all bug changes.