Wireshark · Ethereal-dev: Re: [Ethereal-dev] ip.addr != 1.2.3.4 should work as expected

[Ulf Lamping <ulf.lamping@xxxxxx>]

Jaap Keuter wrote:

>Welcome to the wonderfull world of regular expressions.
>For one they are very powerfull, on the other they can bite you.
>  
>
Please remember that there are a lot of people out there which uses
Ethereal and don't know (a lot about) RegEx.

And it's also not obvious at first sight that the display filter string
*is* a RegEx.

>>Would it be possible to change the current display filter so it would
>>work as expected?
>>    
>>
>
>In a sense they do, but since a computer cannot understand the semantics
>of whats expected, you're required to be syntactically accurate.
>
>Check out http://wiki.ethereal.com/DisplayFilters which describes this
>very example :-)
>  
>
Well, yes, I wrote exactly that part in the User's Guide quite some time
ago...

It's not about that I don't know how to handle this, but this is a very
frequent and annoying thing for Ethereal beginners.

>>I don't know the grammatics behind this, so I don't know how much effort
>>this would be and I'm really not the person to change this (I personally
>>hate flex/yacc and alike :-)
>>
>>So is there any reason that this shouldn't be changed, and maybe is
>>there someone able to change it?
>>    
>>
>
>Yes there is. These regular expressions are well worked out in various
>libraries, which are shared among numerous programs. This gives a constant
>way of creating these expressions, which is a Good Thing(sm).
>  
>
Hmmm, it's not about RegEx here, but how to handle the combined fields
like ip.addr, tcp.port and alike.

Currently we simply substitute "ip.addr" by "(ip.srcaddr ||
ip.destaddr)", which is ok for the == operator, but not really for the
!= operator.

We might have a display filter "preprocessor", which converts this in a
way before handling the RegEx in it's current way.

Or maybe simpler warn if the user types something like "ip.addr !=
1.2.3.4" that this is maybe not what he expects, as this string usually
won't make any sense.

Regards, ULFL