Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 154118

Summary: Colorfilter expressions matching incorrectly in ethereal-gnome
Product: [Fedora] Fedora Reporter: Robert Nichols <rnichols42>
Component: etherealAssignee: Radek Vokal <rvokal>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-11 09:39:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Capture file, 6 packets, from tcpdump. none

Description Robert Nichols 2005-04-07 16:15:27 UTC
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 16:19:40 UTC
Created attachment 112819 [details]
Capture file, 6 packets, from tcpdump.

Comment 2 Robert Nichols 2005-04-07 16:27:30 UTC
Expected results section should read: "Only packets 2 and 5 should be colored."

Comment 3 Radek Vokal 2005-04-11 09:39:22 UTC
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 20:21:44 UTC
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.