Ulf Lamping schrieb:
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.
Of course, we should try to educate the user before they sent a mail.
The aggresive way: :)
By popping up window when a user uses the "not equal" operator in a display
filter expression. Title of the window: 'What you should know about using "!="
in a display filter.'
Of course you should be able to deactivate this behaviour.
Regards,
Lars
