Comment # 4
on bug 8178
from Guy Harris
(In reply to comment #0)
> When the following filter is applied in Wireshark, it should return zero frames because a Create request doesn’t have a ‘smb2.file_info.infolevel’ field:
>
> smb2.cmd == 5 && smb2.file_info.infolevel
No. When the following filter is applied in Wireshark, it should return the
number of frames that contain both an SMB2 Create request and a request that
has an information level field in a file information structure; that's how the
filter language is defined to work. That might be inconvenient, or confusing,
for some users, but it might be *expected* by other users. For example,
somebody might be looking for a frame containing two particular SMB2 in the
same frame with "smb2.cmd == X && smb2.cmd == Y" (and a filter such as "ip.src
== XX.YY.ZZ.WW && smb2.cmd == X" can't be applied to an SMB2 request, as SMB2
requests don't have IP addresses, the IP datagrams that contain the data that
make up the SMB2 requests have IP addresses).
The filter language is, by design, simple-minded; it knows nothing about the
semantics of any of the protocols, it only knows about protocol trees. The
filter code doesn't know anything about SMB2 requests or responses; it knows
only about a bunch of named fields that appear in the protocol tree.
What's needed here is a way to specify, in a filter _expression_, that a filter
_expression_ should be applied to particular subtrees of a protocol tree, rather
than to the protocol tree as a whole, e.g.
same_subtree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel)
which means "for all subtrees under an "smb2" node, see whether "smb2.cmd == 5
and smb2.file_info.infolevel" matches, and evaluate to "true" if there is at
least one such subtree where the filter matches on that subtree and "false"
otherwise".
You are receiving this mail because:
- You are watching all bug changes.