Re: [Wireshark-dev] New syntax for range support in membership operator: tcp.port in {1662-1664}

2018-04-15 Thread Roland Knall 
+1 for the double dot

On Sun, Apr 15, 2018 at 10:28 PM, Jasper Bongertz 
wrote:

> 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 <*
> pe...@lekensteyn.nl
>
>
>
>
>
>
> *> 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==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 
>
> 
> ___
> Sent via:Wireshark-dev mailing list 
> 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
>
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] New syntax for range support in membership operator: tcp.port in {1662-1664}

2018-04-15 Thread Jasper Bongertz 
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  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==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 
> 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

smime.p7s
Description: S/MIME Cryptographic Signature
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] New syntax for range support in membership operator: tcp.port in {1662-1664}

2018-04-15 Thread Jaap Keuter 
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  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==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 
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

[Wireshark-dev] New syntax for range support in membership operator: tcp.port in {1662-1664}

2018-04-15 Thread Peter Wu 
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 
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