osmocom
/
wireshark
11
0
Fork 1
Code Issues Pull Requests Projects Releases Wiki Activity

WSUG: Add a sub-chapter about new display filter syntax 

Explain how the optional explicit syntax works and in which
cases it might be useful.
This commit is contained in:
João Valverde 2022-03-08 13:55:50 +00:00 committed by A Wireshark GitLab Utility
parent 7aa5b08016
commit 7ea63a134e
1 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
docbook/wsug_src/WSUG_chapter_work.adoc
View File

@ -825,6 +825,38 @@ the old filter names for the time being, e.g., “bootp.type” is equivalent
to “dhcp.type” but Wireshark will show the warning “"bootp" is deprecated”
when you use it. Support for the deprecated fields may be removed in the future.
==== Some protocol names can be ambiguous
In some uncommon cases relational display filter expressions (equal, less than, etc.)
can be ambiguous. The filter name of a protocol or protocol field can contain
any letter and digit in any order, possibly separated by dots. That can be
indistinguishable from a literal value (usually numerical values in hexadecimal).
For example the semantic value of `fc` can be the protocol Fibre Channel or the
number 0xfc in hexadecimal. The 0x prefix is optional for literal values and
furthermore "0xfc" would be a syntactically valid filter name for a protocol.
Wireshark will use a heuristic for parsing those expressions. A value on the
right hand side of the expression is treated as literal value first. If that
fails it is treated as a protocol or protocol field (if one exists with that
name). If that fails it is a syntactical error. On the left hand side values
are always treated as protocol fields. Literal values are not considered on the
LHS. So the expression `fc == fc` is parsed as
"Byte array of protocol with name 'fc' equals byte array { 0xfc } of length 1".
Sometimes this may not be the intended meaning and there is additional syntax
to resolve the ambiguity. Lexical tokens prefixed with colon, or in-between angle
brackets, are always and only treated as literal values. Tokens prefixed with a
dot are always treated as a protocol name (the dot stands for the root of the
protocol namespace and is optional).
----
frame[10:] contains .fc or frame[10] == :fc and not frame contains <cafe.face>
----
The most common use case for a display filter relational expression is to compare
a field with a constant value on the right hand side and in that case the heuristic
method used will parse the expression correctly. In the not-so-common case, or
if you are writing a script, or you think your expression may not be giving the
expected results it is advisable to use the explicit syntax to resolve any
possible ambiguity in the meaning of filter expression.
[#ChWorkFilterAddExpressionSection]
=== The “Display Filter Expression” Dialog Box