Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 12475] New: Qt: After modifying coloring rules, the coloring rule applied to t

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	12475
Summary	Qt: After modifying coloring rules, the coloring rule applied to the first packet reflects the coloring rules previously in effect.
Product	Wireshark
Version	Git
Hardware	All
OS	All
Status	UNCONFIRMED
Severity	Minor
Priority	Low
Component	Qt UI
Assignee	bugzilla-admin@wireshark.org
Reporter	jyoung@gsu.edu

Created attachment 14598 [details]
One host pinging two targets, only one host replies.

Build Information:
Version 2.1.0-3151-gbf62898 (v2.1.0rc0-3151-gbf62898 from unknown)

Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with Qt 5.3.2, with libpcap, without POSIX capabilities, with
GLib 2.36.0, with zlib 1.2.5, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2,
with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with
QtMultimedia, without AirPcap.

Running on Mac OS X 10.10.5, build 14F1808 (Darwin 14.5.0), with locale C, with
libpcap version 1.5.3 - Apple version 47, with GnuTLS 2.12.19, with Gcrypt
1.5.0, with zlib 1.2.5.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.9.00).

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
When changing coloring rules, assuming that a new rule should affect the
colorization of the first displayed packet, the first packet list row will
still be colorized with the previous coloring rule.

Selecting the first displayed packet, expanding the frame tree and reviewing
the Coloring Rule Name will confirm that the rule name in effect is not the one
expected.

This issue has been replicated on both OS X and Windows 8.1 systems. 

Steps to reproduce:

1 - Open the sample capture file attached to this bug
(ping-two-hosts-only-one-replies.pcapng). 

The standard default Wireshark color filter "ICMP" should colorize all packets
as pink.

2 - Open the Colorizing Rules dialog by selecting the menu option View ->
Coloring Rules ... 

3 - In the coloring rules dialog create and enable a new coloring rule.
Set the name to "TEST-TEST-TEST-TEST" with a filter of "icmp.type == 8" and a
background color of orange.

4 - Close the Coloring Rules dialog by clicking on [OK].

The new coloring rules should be in effect with the packets displayed with a
beautiful orange and pink zebra like pattern.

6 - Select the first frame and expand the Frame tree and review the Coloring
Rule Name in effect.  This should be frame #1 since we have no display filter
in effect.

Since frame #1 is a ping request we are expecting the Coloring Rule Name to
report "TEST-TEST-TEST-TEST" but instead it will report "ICMP".

7 - Select a different packet in the packet list (for example packet #2).

Frame #1 even though it is an ICMP ping request it will still be be displayed
in the default pink color instead of the expected orange.

8 - Open the Coloring Rules dialog a second time and then simply click "OK"
without making any changes.

Frame #1 will now be displayed as the expected orange.  The frame tree details
for frame 1 will now report the coloring rule name is TEST-TEST-TEST-TEST.

Note: If there is a display filter in place, the issue will be present on the
first displayed packet.  If the display filter is cleared, the frame that was
previously the first displayed frame will still have the wrong color filter.

Note2:  This issue can also be demonstrated by simply toggling on and off the
specific coloring rule that is matches the first displayed packet (assuming
that a coloring rule exists that will match the first displayed packet). 

Workarounds:

There are several workarounds to this issue.

A - Globally toggle coloring rules off and on to force the coloring rules to be
reapplied. When the coloring rules are disabled, the frame tree Coloring Rule
Name for the first frame will be immediately updated to display the expected
coloring rule (even though coloring rules are off). When the coloring rules are
re-enabled the first frame will now display the expected color. 

or

B - Open the Coloring Rules dialog and then simply click on the [OK] button to
close it without changing any of the coloring rules.  This will cause the first
frame to display the expected color.

or

C - Initiate a reload of the current capture file.

This issue might be similar to the one reported in closed Bug 11871.

---

      You are receiving this mail because:

• You are watching all bug changes.