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 - Colorfilter expressions matching incorrectly in ethereal-gnome
Summary: Colorfilter expressions matching incorrectly in ethereal-gnome
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ethereal
Version: 3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokal
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-07 16:15 UTC by Robert Nichols
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-11 09:39:22 UTC


Attachments (Terms of Use)
Capture file, 6 packets, from tcpdump. (deleted)
2005-04-07 16:19 UTC, Robert Nichols
no flags Details

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.



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