Wireshark-bugs: [Wireshark-bugs] [Bug 12475] New: Qt: After modifying coloring rules, the colori
Date: Thu, 26 May 2016 05:01:37 +0000
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 | [email protected] |
Reporter | [email protected] |
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 <[email protected]> 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.
- Prev by Date: [Wireshark-bugs] [Bug 12474] Requesting Protocol Addition: 'Pro DJ Link'
- Next by Date: [Wireshark-bugs] [Bug 12472] SMB Open andX extended response decoded incorrectly
- Previous by thread: [Wireshark-bugs] [Bug 12474] Requesting Protocol Addition: 'Pro DJ Link'
- Next by thread: [Wireshark-bugs] [Bug 12476] New: IO graph not displaying HTTP.time in graph correctly
- Index(es):