Created attachment 10820 [details] Patches to prefs_font_color.c Build Information: Version 1.11.0-dev (SVN Rev Unknown from unknown) Copyright 1998-2013 Gerald Combs <gerald <at> wireshark.org> and contributors. 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 (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities, without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built May 20 2013), with AirPcap. Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap. Intel(R) Xeon(R) CPU E5507 <at> 2.27GHz, with 4093MB of physical memory. Built using Microsoft Visual C++ 10.0 build 40219 ===================== -- "Stream" should be changed to "Follow Stream" in the "Sample" textbox and "Colors" dropdown menu of the "Font and Colors" dialog: This is needed to draw a distinction between the coloring of packets produced by the "Follow TCP|UDP|SSL Stream" command and the non-colorized output of the 'tcp.stream == n' filter.

Created attachment 10818 [details] Patch that addresses all these issues Build Information: Version 1.11.0-dev (SVN Rev Unknown from unknown) Copyright 1998-2013 Gerald Combs <gerald <at> wireshark.org> and contributors. 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 (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities, without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built May 20 2013), with AirPcap. Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap. Intel(R) Xeon(R) CPU E5507 <at> 2.27GHz, with 4093MB of physical memory. Built using Microsoft Visual C++ 10.0 build 40219 ---------------------------- -- "No such preference" warnings are displayed for 5 obsolete and 1 platform-specific preference: In set_pref()of prefs.c (lines 3824-3833) 'stream.client.<fg/bg>' and 'stream.server.<fg/bg>' should be compared with 'dotp' without the 'stream.' prefix. In addition, 'taps.rtp_player_max_visible', 'client.bg' and 'server.bg' should be compared with 'dotp' rather than 'value'. This warning is also displayed on WIN32/64 platforms for the "print.command" pref because it is not valid on those platforms (see 'read_prefs_file()' in prefs.c, line 3023).

Created attachment 10815 [details] '>"><img src=x onerror=alert(0)> Build Information: -- Hi, I have found a Flash based XSS vulnerability that I would like to report about. I have included the Proof of Concept(PoC) below: Proof of Concept: http://ask.wireshark.org/m/default/media/js/ZeroClipboard.swf?id=\%22%29%29}catch%28e%29{}if%28!self.a%29self.a=!alert%28/wcypierre/%29//&width&height Please patch it as soon as possible. Regards, wcypierre

Build Information: Version 1.8.7 (SVN Rev 49382 from /trunk-1.8) -- TCP conversation list has 527 entries. 1 of them stands out as a relative screamer: 2.6 Mb/s ! on closer inspection, though, this is just a Wireshark-triggered red herring. Here are the details: 2 packets were sent -- pkt 1 had 54B -- pkt 2 had 60B -- delta t between packets = 351 usec. WS is calculating transport of 8 b/B * 114 B / 351 usec = 2,598,290.598291 b/sec My estimation: Not Really! I can't immediately offer suggestions for more realistic calculations, but this situation is a kind of corner case that perhaps should be thought about for special handling. There's a similar conversation elsewhere in this capture: - 4 packets - 54 + 60 + 54 + 50 B = 228 B - delta t --- pkt1 to pkt4: 20.754765 sec --- pkt1 to pkt2: 432 usec --- pkt3 to pkt4: 360 usec - 87.9 b/s I'd be remiss not to mention that the "conversations" that lead to these #s are a bit screwy themselves, as all 6 messages are TCP with sequence # = 1 and FIN + ACK set, and *no* communication from the destination peer. (This is traffic within a corporate network, and not some experimental or academic environment.)

Created attachment 10814 [details] screen capture of a fouled IO Plot Build Information: Version 1.8.7 (SVN Rev 49382 from /trunk-1.8) -- in the IO Graphs window, I have 5 plot lines configured: L1: (unfiltered) L2: cpha or edp or browser or bootp L3: arp L4: tcp L5: icmp The displayed plot is fine. As I move from file to file in a fileset (10 MB/file, typically < 90k frames for spans less than 1 hour,) however, the span of the x axis is incomplete. Originally, I have to scroll right/left to see the whole plot. In the example I have before me now: 1st time in capture = 12:45:53 Last time in capture = 13:22:28 (frame # 87640) IO Graph x-axis displays 12:45:53 to a little after 12:47:33 (I'll attach a screen capture) When this happens, I change the tick interval (10 minutes/tick,) let it replot, an then go back to the original tick interval (1 second/tick,) and all is well. So, unless there's some kind of leak or corruption, this issue seems a user annoyance than a big deal. This problem reproduces easily for me. Other settings on the IO Graph window: - X Axis --- pixels per tick = 1 --- view as time of day: checked - Y Axis --- packets/tick (or bytes/tick - I've seen it with both settings active) --- scale: auto --- smooth: no filter

Created attachment 10811 [details] 2 single export efforts (reforted from native CSV only with Excel's text-to-data feature) Build Information: -- in the IO Graphs window, I have 5 plot lines configured: L1: (unfiltered) L2: cpha or edp or browser or bootp L3: arp L4: tcp L5: icmp The plot looks OK -- nothing irregular, evey line seems to have its own life, varying as I move through different files in a fileset. At first, when I clicked the copy button and pasteed into MS Excel, everything seems OK. I've checked the data in excel and (per timestamp) L1 - L2 - L3 - L4 - L5 = 0, as expected. Working through the 10MB/file fileset, I got ~17k lines exported OK. Somewhere along the line, though, I noticed the following in each exported line: L1 = L3 = L4 This does not seem to reproduce at consistent points in the wireshark experience -- Significantly, you don't need to export 17,000 data points to get here. In fact, the badness happened this morning in a fresh Wireshark session on a freshly rebooted machine. I saw the badness, then tried to reproduce 2x and succeeded the 1st time but not the second. I tried both attempts with .pcap where I had previously observed the problem. I'll try attaching examples.

Build Information: TShark 1.11.0 (SVN Rev Unknown from unknown) Copyright 1998-2013 Gerald Combs <gerald <at> wireshark.org> and contributors. 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 GLib 2.32.3, with libpcap, with libz 1.2.3.4, with POSIX capabilities (Linux), with libnl 2, with SMI 0.4.8, with c-ares 1.7.5, with Lua 5.2, without Python, with GnuTLS 2.12.14, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP. Running on Linux 3.6.9, with locale en_IE.UTF-8, with libpcap version 1.5.0-PRE-GIT_2013_05_15, with libz 1.2.3.4. Intel(R) Core(TM) i7-2600 CPU <at> 3.40GHz Built using gcc 4.6.3. -- Here is the patch for highlight correct bytes in two Bluetooth SDP (btsdp) trees. For current SVN/GIT and Wireshark 1.10.

Created attachment 10804 [details] patch to support dissecting Raptor and Raptor Q FEC in RMT dissector Build Information: -- Raptor FEC is defined in RFC 5053, Raptor Q - in RFC 6330. Currently, RMT dissector is aware that both exist (i.e., it knows about their assigned encoding ids) but won't dissect them. The attached patch adds support for dissecting both Raptor and Raptor Q.

Created attachment 10803 [details] patch file with additional dissection field Build Information: -- Added STREAM_VLAN_ID field to dissection for SET_STREAM_INFO and GET_STREAM_INFO AECP commands in packet-ieee17221.c

Comment # 16 on bug 2412 from Michael Mann Created attachment 10798 [details] Sample dissectors using v2 expert info architecture Updated sample dissectors that I originally used for testing expert info framework. Note that in the ARP dissector I replaced some of the hf items with just the expert info since it's now filterable.

Comment # 15 on bug 2412 from Michael Mann Created attachment 10797 [details] New expert info architecture (v2) Improved expert info framework to include "display filter" functionality per Guy's suggestion. Not sure if expert info needs it's own field type, so it's currently marked as FT_NONE. Fixed the expert_init() issues mentioned in comment #11 by breaking the functionality out into "global expert info initialization" and "packet initialization". Again, I think more can be done with the "registered expert info indexes" than just the raw lookup, but I wanted to start with the base architecture.