Lars Roland wrote:
> Ulf Lamping schrieb:
>
>> Currently we simply substitute "ip.addr" by "(ip.srcaddr ||
>> ip.destaddr)", which is ok for the == operator, but not really for the
>> != operator.
>
> Well, we do not really substitute ip.addr. Instead we make both the IP
> source address and the IP destination address in an IP header
> accessable over the display filter field with the name "ip.addr",
> while "ip.src" access only the IP source addresses and "ip.dst" access
> only IP destination addresses. Note the plural! Whne having more than
> one IP header in a single packet, "ip.src" and "ip.dst" will access
> also more than one address.
>
> A lot people do not know a lot of the display filter logic, especially
> when it comes to the point having a filterable field more than once in
> a single packet. "ip.addr" is only the most famous example here, but
> all other display filter fields are affected, too.
Well, I've noticed that before, but that's a different and less frequent
problem IMHO. And it's more of a problem that people didn't noticed
multiple IP addresses, which is about understanding their current
traffic. The "ip.addr !=" topic is about the filter string handling not
obvious.
> Someone, who knows that the expression "filter-field comparator value"
> always implies "TRUE, if at least once TRUE" doesn't have any problem
> with the display filter logic.
> I think most users expect a different behaviour ("only TRUE, if TRUE
> for all") for the "not equal" comparator.
>
> Anyhow, I would prefer to keep the current logic as it is. I see this
> more or less as an educational issue.
I personally don't like the "educational issue", this only leads to more
traffic to the users mailing list and just annoys users.
>> 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.
>
> How about adding a kind of "help on display filter" button next to the
> display filter field, which will lead to the documentation for display
> filters. There we should also tell about and explain the most common
> mistakes in display filters, with ip.addr != 1.2.3.4 at the very first
> place.
Sounds like a good idea anyway ...
Regards, ULFL