ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] ip.addr != 10.0.0.1 (Guy Harris)

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Tue, 29 Jan 2008 09:55:43 +0100
Hi,

Well, still not that warm fuzzy feeling about it. I'll give you something to think about.

The whole discussion focuses on the use of the != operator, which is the NE operator. We'll need to consider that the same discussion can be held for the LT, LE, GT and GE operators. Imagine this storyline: "I want only the packets with addresses not in my managment lan, so above 10.1.255.255. When I use ip.addr > 10.1.255.255 I still get packets from and to my management LAN". Basically the same problem here, although not reported (and probably not encountered) as frequently.

Another thing is that dfilter expressions become a dialect depending on the place (Wireshark configuration file instance) it runs. That is between different users, but also between configuration file sets, as were recently introduced.

May I offer a different proposal, based on a former colleague's bug solving method. Since we have two (three actually) ways of expressing Not Equal, being "!(...)" and ".. != .." and ".. NE ..", why not drop support for the ".. != .." (and ".. NE ..") ?

This solution has the following advantages:
* It removes code i.s.o. adding hooks in the grammer.lemon or semcheck.c or where ever this warning comes from.
* It shifts the use of the unwanted ".. != .." aways to the desired "!(..)".
* The syntax (error) becomes apparent when editing the expression, not when applying it.
* We could even keep ".. NE .." around for the power users.
This solution has the following disadvantages:
* It drops an operator where people are used to.
* Display filter generators may need to be changed
* Color display filters may become invalid.

Thanx,
Jaap

Sake Blok wrote:
On Tue, Jan 29, 2008 at 10:05:27AM +0900, Kenichi Okuyama wrote:
Sorry to interrupt you. I simply want to make sure. You mean, in
current implementation:

a) ( ip.addr == 1.2.3.4 ) means (( ip.src == 1.2.3.4 )||( ip.dst == 1.2.3.4 )).

b) ( ip.addr != 1.2.3.4 ) means (( ip.src != 1.2.3.4 )||( ip.dst != 1.2.3.4 ))
 which stands for   !(( ip.src == 1.2.3.4 )&&( ip.dst == 1.2.3.4 ))
 ( which means "ignore if both src and dst are 1.2.3.4" )

c) !ip.addr == 1.2.3.4 means ( !( ip.addr == 1.2.3.4 ))
    which stands for ( !(( ip.src == 1.2.3.4 )||( ip.dst == 1.2.3.4 )))
    which stands for ( ip.src != 1.2.3.4 )&&( ip.dst != 1.2.3.4 )

Yes, a, b and c are correct.

I do agree about b) being very confusing. I was trapped by this syntax
only a week ago. It took me very long before I figured out what was
happening.

That's what started this discussion, there are a lot of questions
on the mailinglists about why != doesn't work like expected.

I would vote for a preference value that defaults to make
ip != 10.0.0.1 result in !(ip.addr==10.0.0.1).

It would be best to create a pop-up when the user uses the != operator
the first time (after upgrading Wireshark) telling them about the
difference and where they can change back it back to the old behaviour.
Even the warning window itself should have a "don't show this
message again" checkbox

Stig, Ulf, Guy, Jaap, what do you think of such a compromise?

Cheers,
    Sake