Hi,

Laura requested support for ranges for the "in" display filter operator
in bug 1480 which seems like a reasonable idea. I have a prototype patch
working here: https://code.wireshark.org/review/26945

The initial implementation converted "f in {a-b}" to "f >= a && f <= b",
but this turned out to be problematic when a field has multiple
occurrences. To solve this, I added a new ANY_IN_RANGE DVFM instruction
that checks each field against the range.

One remaining issue is the syntax. The proposed syntax looks a bit ugly
with negative numbers, and is also not implemented for things other than
numbers. It can also be ambiguous.

Example: find SMB server timezone within UTC-0700 and UTC-0400):

    smb.server_timezone in {-420--240}

Example: find all hosts in range 10.0.0.10-10.0.0.60. The CIDR notation
cannot be used to match this, instead you need something verbose like:

    (ip.src >= 10.0.0.10 and ip.src <= 10.0.0.60) or
    (ip.dst >= 10.0.0.10 and ip.dst <= 10.0.0.60)

A potential shorter version (not supported at the moment):

    ip.addr in {10.0.0.10-10.0.0.60}

Another issue: the filter "data.data==1-3" is interpreted as matching
bytes "0103" (because data.data is of type FT_BYTES). The display filter
"data.data in {1-3}" is currently ambiguous (previously it matched the
previous "==" filter, after my patch it becomes "a single byte in range
01 to 03"). One way to address this is to treat only "01:02:03" as byte
patterns and forbid "01-02-03".


With these cases, do you think that using "-" is a good range operator
for the set membership operator? An alternative range syntax suggestion
was proposed in doc/README.display_filter as:

    (x in {a ... z})

Some possible ideas (I don't really like them to be honest):

    tcp.srcport in { 80 1662 ... 1664 }
    tcp.srcport in { 80 1662 .. 1664 }
    tcp.srcport in { 80 [1662, 1664] }
    tcp.srcport in { 80 range(1662, 1664) }

Feedback is welcome!
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to