Comment # 8
on bug 11860
from [email protected]
(In reply to Guy Harris from comment #7)
> (In reply to João Valverde from comment #6)
> > The most natural formal interpretation would be an AND relation, which the
> > operator doesn't follow anyway, for convenience.
>
> I.e., the _expression_ {field} {op} {value} should be interpreted as "for all
> instances of {field}, the relation '{value of that instance of the field}
> {op} {value}' is true", rather than as "there is an instance of {field} such
> that the relation '{value of that instance of the field} {op} {value}' is
> true"?
>
> That would mean that "ip.addr == 192.168.0.1" would only match packets from
> 192.168.0.1 to 192.168.0.1; I'm not sure that would be useful.
The issue comes down to
CASE {OP}:
'==' : IF ANY instance of {field} {op} {value} : True
'!=' : IF ALL instance of {field} {op} {value} : True
ECASE : False
The interpretation of the search is different for different {op} fields. The
'ip.addr ==' interprets as source OR destination where as 'ip.addr !='
interprets as source AND destination.
You are receiving this mail because:
- You are watching all bug changes.