|Summary:||Colorfilter expressions matching incorrectly in ethereal-gnome|
|Product:||[Fedora] Fedora||Reporter:||Robert Nichols <rnichols42>|
|Component:||ethereal||Assignee:||Radek Vokal <rvokal>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-04-11 09:39:22 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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==188.8.131.52 && 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==184.108.40.206 means, for ethereal, "in this packet there is a source field inside an IP header that equals 220.127.116.11"; it does not mean "the first IP header in this packet has a source field that equals 18.104.22.168". 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==22.214.171.124 && 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.