Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] New syntax for range support in membership operator: tcp.por

From: Jasper Bongertz <jasper@xxxxxxxxxxxxxx>
Date: Sun, 15 Apr 2018 16:28:33 +0200
Title: Re: [Wireshark-dev] New syntax for range support in membership operator: tcp.port in {1662-1664}
Hi,

+1 for the double dot syntax.

Cheers,
Jasper

Sunday, April 15, 2018, 3:03:53 PM, you wrote:

> Hi,

> In fact I would suggest to consider double dot (‘..’) in this case.
> Reasons:
> * It is a sufficiently unique operator
> * The minus causes too many conflicts, as you have stated
> * triple dot (‘...’, i.e. Ellipsis) is too prone to
> ‘autocorrection’ to the ellipsis symbol, causing copy-paste problems.

> Regards,
> Jaap



>> On 15 Apr 2018, at 13:24, Peter Wu <
peter@xxxxxxxxxxxxx> wrote:

>> 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="" 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@xxxxxxxxxxxxx>
> Archives:    
https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>            
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature