Bug 154118 - Colorfilter expressions matching incorrectly in ethereal-gnome
Colorfilter expressions matching incorrectly in ethereal-gnome
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ethereal (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-07 12:15 EDT by Robert Nichols
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-11 05:39:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Capture file, 6 packets, from tcpdump. (548 bytes, application/octet-stream)
2005-04-07 12:19 EDT, Robert Nichols
no flags Details

  None (edit)
Description Robert Nichols 2005-04-07 12:15:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
Color filter expressions falsely match packets where no match should occur.

Version-Release number of selected component (if applicable):
ethereal-0.10.10-1.FC3.1

How reproducible:
Always

Steps to Reproduce:
1. Start a clean (no existing .ethereal directory) instance of ethereal.
2. Open the attached (short) capture file.
3. Open the Color Filter dialog and create a new filter named "mysrc" with an
   expression "ip.src==24.14.184.105 && tcp" and a background color "green".
4. Click on "Apply".
  

Actual Results:  In addition to the correct packets (2 and 5), packets 3 and 6, which have neither
the correct source IP address nor the correct protocol, will be displayed with a
green background.

Expected Results:  Only packets 2 and 4 should be colored.

Additional info:

gnome-desktop-2.8.0-3  libpcap-0.8.3-7

With multiple, complex color filter expressions there are some strange
interactions.  This is the simplest example I have found.
Comment 1 Robert Nichols 2005-04-07 12:19:40 EDT
Created attachment 112819 [details]
Capture file, 6 packets, from tcpdump.
Comment 2 Robert Nichols 2005-04-07 12:27:30 EDT
Expected results section should read: "Only packets 2 and 5 should be colored."
Comment 3 Radek Vokal 2005-04-11 05:39:22 EDT
I've discussed it with ethereal developers and here's a conclusion. It's
generaly not a bug.

ip.src==24.14.184.105 means, for ethereal, "in this packet there is a 
source field inside an IP header that equals 24.14.184.105"; it does not
mean "the first IP header in this packet has a source field that equals
24.14.184.105". In your capture packets 3 and 6 are ICMP, and the ICMP
payload includes IP headers with those values.

As a practical tip, "ip.src==24.14.184.105 && tcp &&!icmp" should give
the results you are looking for.
Comment 4 Robert Nichols 2005-04-11 16:21:44 EDT
Thanks _very_ much for investigating that.  I never would have guessed that
ethereal would dig down into the returned IP header within the ICMP message
and match on the fields within that header.  That level of unexpected
sophistication is actually pretty scary, but it explains all of the strange
behavior I've been seeing.

Note You need to log in before you can comment on or make changes to this bug.