On Mon, 9 May 2005, Ulf Lamping wrote:
> 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.
True, but then again simple expressions work for them.
> And it's also not obvious at first sight that the display filter string
> *is* a RegEx.
Which they will learn once they're ready. I've seen some never are ready,
but most of them do, to different levels of proficiency.
> >>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...
LOL
> 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.
Network monitoring _is_ an annoying thing. Just today I had a guy in the
office (he's well educated and experienced) explaining to me an inpossible
chain of messages seen in a capture. Listing to his rant, I just had to
ask him one simple question: at which node was this capture made? Then he
saw the light, why he was missing some of the messages he was expecting.
Bottom line: Everyone can start a capture. Analyzing it requires
intelligence.
> >>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.
Try to make that work on a complex expression. Not so easy.
I would go for some more examples of these cases in the help tab "Display
Filters", before sending them of into the online variant.
Good night,
Jaap