Guy Harris
changed
bug 10379
| What |
Removed |
Added |
| Hardware |
x86-64
|
All
|
| OS |
Windows 7
|
All
|
Comment # 6
on bug 10379
from Guy Harris
(In reply to Jerome from comment #5)
> I do see two different places in the dissection where ip.src is one each,
> the phone and the server. So the statement that ip.src is a field cannot be
> true?
The statement that a field can only appear once in a packet is not true.
This means that a filter
{field} {comparison} {value}
should be interpreted as meaning "there exists at least one instance of {field}
with a value such that, when compared with {value} using the comparison
operator {comparison}, compares true". not "the value of {field}, when compared
with {value} using the comparison operator {comparison}, compares true". For
example,
ip.src == 1.2.3.4
means "there exists at least one instance of ip.src that's equal to 1.2.3.4".
A consequence of this is that
ip.src != 1.2.3.4
is *NOT* the negation of
ip.src == 1.2.3.4
The negation of
ip.src == 1.2.3.4
is
!(ip.src == 1.2.3.4)
> Else the field conforms to the Shrodinger's cat rules of physics? If
> one is an embedded copy of the message, shouldn't those fields have
> different names?
No, but for "error packets" such as the embedded IPv4 packet in ICMP packets
(this also happens with ICMPv6 and with the OSI equivalent of ICMP errors),
perhaps filters shouldn't apply to them by default, with a special display
filter syntax used to match on fields in "error packets".
You are receiving this mail because:
- You are watching all bug changes.