http://blog.gmane.org/gmane.network.wireshark.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.network.wireshark.bugs/51260 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8823 Bug ID: 8823 Summary: ip.opt.type triggers for TCP NOP option Classification: Unclassified Product: Wireshark Version: 1.10.0 Hardware: All OS: All Status: UNCONFIRMED Severity: Minor Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: lcharbonnier&lt; at &gt;gmail.com Created attachment 11023 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=11023&amp;action=edit screen capture of the bug Build Information: -- When using ip.opt.type display filter, tcp packets including NOP options are displayed even if no ip options are present. It appears that the TCP dissector recognizes the NOP option type as ip.opt.type (instead of tcp.option_kind, for example). Same behaviour is also observed for sub-options (ip.opt.type.copy, ip.opt.type.class, ip.opt.type.number). Screen capture is from 1.8.2 on OSX, validated same behaviour on 1.10.0 on Win32. </pre> bugzilla-daemon< at >wireshark.org 2013-06-20T01:12:51 http://comments.gmane.org/gmane.network.wireshark.bugs/51242 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8822 Bug ID: 8822 Summary: HTTP heuristic is expensive when checking binary TCP protocols Classification: Unclassified Product: Wireshark Version: SVN Hardware: x86 OS: All Status: UNCONFIRMED Severity: Trivial Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: martin.r.mathieson&lt; at &gt;googlemail.com Created attachment 11022 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=11022&amp;action=edit Returns if first byte isn't printable rather than scan to end of line. Build Information: -- In a profiled run with FTP traffic, the HTTP dissector looking for the end of a line of data (which was binary) was taking around 3% of runtime. The patch I will attach will make the HTTP dissector return immediately if the first character is not printable, but I don't know the protocol well enough to be sure that this is safe to do. </pre> bugzilla-daemon< at >wireshark.org 2013-06-19T18:54:15 http://comments.gmane.org/gmane.network.wireshark.bugs/51218 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8821 Bug ID: 8821 Summary: determine number of parallel make jobs for OsX support libs build Classification: Unclassified Product: Wireshark Version: SVN Hardware: x86 OS: Mac OS X 10.7 Status: UNCONFIRMED Severity: Enhancement Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: doj&lt; at &gt;cubic.org Build Information: -- if no make options are given to the macosx-setup.sh script by the user, the script sets the number of parallel make jobs to 1.5x CPU cores. Bonus enhancement: print the "export PKG_CONFIG_PATH" information in autogen.sh on OsX, so people don't have to remember it. </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T22:57:32 http://comments.gmane.org/gmane.network.wireshark.bugs/51215 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8820 Bug ID: 8820 Summary: create moduleinfo.h from moduleinfo.nmake for plugins Classification: Unclassified Product: Wireshark Version: SVN Hardware: x86 OS: Mac OS X 10.7 Status: UNCONFIRMED Severity: Enhancement Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: doj&lt; at &gt;cubic.org Build Information: -- In the plugin directory the files moduleinfo.h and moduleinfo.nmake define some stuff for the plugin build. Both files define the same things and their contents have to be kept in sync. The attached patch adds a python helper program to generate a moduleinfo.h from a moduleinfo.nmake file. It also changes all plugins in current SVN trunk to use the new way. The patch is supposed to remove all moduleinfo.h files from the SVN repository (but that can not be expressed in a diff file). I have tested these changes with cmake builds on OsX and Linux, autoconf builds on OsX and Linux and nmake builds on Win32. </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T22:42:55 http://comments.gmane.org/gmane.network.wireshark.bugs/51208 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8819 Bug ID: 8819 Summary: CMake Enabled/Disabled Features is empty Classification: Unclassified Product: Wireshark Version: SVN Hardware: All OS: All Status: UNCONFIRMED Severity: Normal Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: alexis.lagoutte&lt; at &gt;gmail.com Build Information: -- Hi, When use CMake to build Wireshark, the table with list of Enabled/Disabled feature is empty. </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T20:35:48 http://comments.gmane.org/gmane.network.wireshark.bugs/51191 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8818 Bug ID: 8818 Summary: MIME: Add support for ELF files Classification: Unclassified Product: Wireshark Version: SVN Hardware: All OS: All Status: UNCONFIRMED Severity: Enhancement Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: michal.labedzki&lt; at &gt;tieto.com Created attachment 11009 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=11009&amp;action=edit Example ELF file Build Information: TShark 1.11.0 (SVN Rev Unknown from unknown) Copyright 1998-2013 Gerald Combs &lt;gerald&lt; at &gt;wireshark.org&gt; 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.9.4, 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 &lt; at &gt; 3.40GHz Built using gcc 4.8.1. -- Hi, I would like to present new dissector: elf_file. It based on ELF specification (and DWARF, etc.). It add feature to open and dissect Linux executable, for example Wireshark binary, *.so libs, *.o objects, coredumps, etc. This work is mostly completed, but there are other tasks what it will be nice to have: 1. Dissect .text section for symbol functions and assembler. 2. Dissect ".plt" section/s. Maybe others too (any interesting section?) So I would like to do not close this bug while ELF dissector will be as full as possible. However first patch can be reviewed and applied. Current dissector features: 1. Dissect sections: .dynsyn, .symtab, .eh_frame_hdr, .eh_frame, string tables. 2. Info about overlapping and backholes (unused part of file) </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T12:48:51 http://comments.gmane.org/gmane.network.wireshark.bugs/51190 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8817 Bug ID: 8817 Summary: hosts location Classification: Unclassified Product: Wireshark Version: 1.10.0 Hardware: x86 OS: Windows 7 Status: UNCONFIRMED Severity: Normal Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: GaryChaulklin&lt; at &gt;yahoo.com Build Information: Version 1.10.0 (SVN Rev 49790 from /trunk-1.10) Copyright 1998-2013 Gerald Combs &lt;gerald&lt; at &gt;wireshark.org&gt; 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 Jun 5 2013), with AirPcap. Running on 32-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) Core(TM) i7-3520M CPU &lt; at &gt; 2.90GHz, with 3036MB of physical memory. Built using Microsoft Visual C++ 10.0 build 40219 -- Starting with 1.10.0 Wireshark does not use the hosts file located at: "C:\Users\myUserID\AppData\Roaming\Wireshark". </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T12:30:36 http://comments.gmane.org/gmane.network.wireshark.bugs/51182 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8816 Bug ID: 8816 Summary: The wireshark displays "Packet size limited during capture" Classification: Unclassified Product: Wireshark Version: 1.10.0 Hardware: x86 OS: Windows 7 Status: UNCONFIRMED Severity: Major Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: xn212516&lt; at &gt;163.com Created attachment 11008 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=11008&amp;action=edit The 26th packet displays "Packet size limited during capture" Build Information: the newest stable version: 1.10.0 -- Hi, all: I use the new stable Wireshark relase (1.10.0) to open the attachment package, and it displays "Packet size limited during capture" in the 26th packet. I think maybe it is a bug of Wireshark. Could any one help to check it? Thanks very much! Best Regards Nan Xiao </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T07:46:31 http://comments.gmane.org/gmane.network.wireshark.bugs/51181 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8815 Bug ID: 8815 Summary: OSX 10.9 "Mavericks": Wireshark not capturing in promiscuous mode Classification: Unclassified Product: Wireshark Version: 1.10.0 Hardware: x86-64 OS: Mac OS X 10.8 Status: UNCONFIRMED Severity: Critical Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: info782323&lt; at &gt;gmail.com Build Information: stable 1.10.0 -- Testing Wireshark 1.10.0 on OSX 10.9 "Mavericks" it is only possible to capture packets from the local machine. Seems promiscuous mode does not work under OSX 10.9. Used the same setup for long time with previous OSX versions, so the setup is fine. </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T06:27:25 http://comments.gmane.org/gmane.network.wireshark.bugs/51180 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8814 Bug ID: 8814 Summary: Provide a windows installer (MSI) package that can be easily deployed Classification: Unclassified Product: Wireshark Version: unspecified Hardware: x86 OS: Windows 7 Status: UNCONFIRMED Severity: Enhancement Priority: Low Component: Extras Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: elhoim&lt; at &gt;gmail.com Build Information: -- Provide a windows installer package (MSI) that can be automatically deployed - https://en.wikipedia.org/wiki/Windows_Installer for more details </pre> bugzilla-daemon< at >wireshark.org 2013-06-18T04:34:02 http://comments.gmane.org/gmane.network.wireshark.bugs/51145 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8813 Bug ID: 8813 Summary: Detection of ipv6 works only on Solaris 8 Classification: Unclassified Product: Wireshark Version: 1.10.0 Hardware: SPARC OS: Solaris Status: UNCONFIRMED Severity: Major Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: dam&lt; at &gt;opencsw.org Build Information: In acinclude.m4 the detection line for Solaris looks like if test "`uname -s`" = "SunOS" &amp;&amp; test "`uname -r`" = "5.8"; then The test should be enhanced to work either from Solaris 8 onwards (5.9, 5.10, 5.11...) or check the respective headers. -- </pre> bugzilla-daemon< at >wireshark.org 2013-06-17T14:50:23 http://comments.gmane.org/gmane.network.wireshark.bugs/51141 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8812 Bug ID: 8812 Summary: Revision 49981 does not compile on my system Classification: Unclassified Product: Wireshark Version: SVN Hardware: x86-64 OS: Ubuntu Status: UNCONFIRMED Severity: Normal Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: marko.hrastovec&lt; at &gt;gmail.com Created attachment 11001 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=11001&amp;action=edit The patch that solves the compiler error on my system Build Information: -- Hi, the revision 49981 from SVN does not compile on my system. I am attaching the patch which solves the problem for me. </pre> bugzilla-daemon< at >wireshark.org 2013-06-17T11:03:46 http://comments.gmane.org/gmane.network.wireshark.bugs/51140 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8811 Bug ID: 8811 Summary: Revision 49981 does not compile on my system Classification: Unclassified Product: Wireshark Version: SVN Hardware: x86-64 OS: Ubuntu Status: UNCONFIRMED Severity: Normal Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: marko.hrastovec&lt; at &gt;gmail.com Created attachment 11000 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=11000&amp;action=edit Patch that corrects an error which prevents compiling on my system. Build Information: -- Hi, I updated the sources from SVN and tried to compile. Revision 49981 does not compile on my system. The patch is attached. </pre> bugzilla-daemon< at >wireshark.org 2013-06-17T10:38:23 http://comments.gmane.org/gmane.network.wireshark.bugs/51138 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8810 Bug ID: 8810 Summary: nfs4: allow filtering on opnames like "nfs.main_opcode==WRITE" Classification: Unclassified Product: Wireshark Version: SVN Hardware: x86 OS: All Status: UNCONFIRMED Severity: Minor Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: ndevos&lt; at &gt;redhat.com Attachment #10999 review_for_checkin? Flags: Created attachment 10999 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10999&amp;action=edit Use value_string array names_nfs4_operation_ext for nfs.main_opname, just like nfs.opname does Build Information: -- One can now use filters like this, without needing to know the number of the operation. Example: $ ./tshark -r dump.pcap.gz -q \ -z rpc,srt,100003,4,nfs.main_opcode==WRITE ================================================================== NFS Version 4 SRT Statistics: Filter: nfs.main_opcode==WRITE Procedure Calls Min SRT Max SRT Avg SRT Total COMPOUND 4875 0.000191 0.038207 0.002282 11.126054 ================================================================== Currently one needs to know that WRITE has value 38, and use this number in the filter. This change makes filtering more user friendly, just like filtering on nfs.opcode already allows. </pre> bugzilla-daemon< at >wireshark.org 2013-06-17T07:54:12 http://comments.gmane.org/gmane.network.wireshark.bugs/51137 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8809 Bug ID: 8809 Summary: Wrong size of LLRP ProtocolID Parameter in Accessspec Parameter Classification: Unclassified Product: Wireshark Version: 1.10.0 Hardware: All OS: Windows 8 Status: UNCONFIRMED Severity: Normal Priority: Low Component: Wireshark Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: christoph.howischer&lt; at &gt;enso-detego.com Created attachment 10998 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10998&amp;action=edit The wrongly parsed capture file. Build Information: -- The LLRP Standard 1.0.1 defines the ProtocolID Parameter as 8 bit value (see LLRP Standard 1.0.1 document, page 138, AccessSpecParameter) but Wireshark treats it as 16 bit value and therefore doesn't recognize the EPCGlobalClass1Gen2 protocol type and marks the whole packet afterwards as invalid. See the attached capture file. </pre> bugzilla-daemon< at >wireshark.org 2013-06-17T06:47:00 http://comments.gmane.org/gmane.network.wireshark.bugs/51124 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8808 Bug ID: 8808 Summary: 64KB packet limit Classification: Unclassified Product: Wireshark Version: SVN Hardware: All OS: All Status: UNCONFIRMED Severity: Normal Priority: Low Component: Capture file support (libwiretap) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: desowin&lt; at &gt;gmail.com Created attachment 10996 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10996&amp;action=edit Remove orig_len check. This is not the final solution. Build Information: wireshark 1.11.0 (SVN Rev 49965 from master) Copyright 1998-2013 Gerald Combs &lt;gerald&lt; at &gt;wireshark.org&gt; 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 GTK+ 2.24.18, with Cairo 1.12.14, with Pango 1.32.5, with GLib 2.36.1, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux), with libnl 1, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, without PortAudio, without AirPcap. 1 Running on Linux 3.8.7, with locale en_US.utf8, with libpcap version 1.4.0, with libz 1.2.8, GnuTLS 2.12.23, Gcrypt 1.5.0. AMD A4-3305M APU with Radeon(tm) HD Graphics Built using gcc 4.7.3. -- Wireshark errors out with "The capture file appears to be damaged or corrupt. (pcap: File has 65563-byte packet, bigger than maximum of 65535)" whilst analyzing some USBPcap files. USBPcap packets contain complete data from I/O Request Packet containing the USB Request Block and actually some drivers send IRPs with such big data buffers. USBPcap does limit the packets to 64KB by default. You can use commandline switch (-s) to increase it. The quick solution is to not check the orig_len field against WTAP_MAX_PACKET_SIZE. I think the incl_len should get checked against the snaplen from global pcap header and not the WTAP_MAX_PACKET_SIZE. </pre> bugzilla-daemon< at >wireshark.org 2013-06-16T23:21:17 http://comments.gmane.org/gmane.network.wireshark.bugs/51118 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8807 Bug ID: 8807 Summary: Handle non-packet records returned from lib wiretap, with plugins supported Classification: Unclassified Product: Wireshark Version: SVN Hardware: All OS: All Status: UNCONFIRMED Severity: Enhancement Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: guy&lt; at &gt;alum.mit.edu CC: eapache&lt; at &gt;gmail.com, hashstat&lt; at &gt;pnnl.gov Depends on: 8590 Build Information: -- +++ This bug was initially created as a clone of Bug #8590 +++ Build Information: The patches patch cleanly against SVN revision 48894. -- The current processing of PCAP-NG has limitations that are addressed by the attached patches. First, dissection of the PCAP-NG blocks is occurring in the wiretap library instead of the wireshark library where dissection errors are less likely to cause problems. Second, it is difficult to present any data other than real packet data to the dissection engine. Third, multiple section header blocks are not supported. Finally, there is no way to add additional block types and/or options via a plug-in dissector. pcapng-block.patch provides enhanced PCAP-NG support. The only thing the patched libwiretap parses is a PCAP-NG block which is passed in its entirety to the dissection engine as the packet data with a new encapsulation type: WTAP_ENCAP_PCAPNG_BLOCK. A new PCAP-NG dissector replaces the Frame dissector as the top-level dissector. Frames that are not of the new encapsulation type are immediately passed on to the Frame dissector while PCAP-NG data continues through the PCAP-NG dissector and a PCAP-NG tree replaces the Frame tree at the top level. Packet block dissectors eventually call the Frame dissector to continue processing as normal while non-packet blocks are displayed without a Frame tree. Multiple sections are supported and can be in different byte orders. All block metadata and options are available to explore in the dissection tree. Unknown block types are displayed but not completely dissected. Dissectors for new block types and options can be registered by compiled-in or plug-in dissectors. pcapng-hone.patch demonstrates a Hone (https://github.com/HoneProject) dissector that adds two block types and several options to some standard block types. Write support, at this point, is rudimentary. Only blocks for selected frames are written to file. Therefore, the section header block and at least one interface description block must be selected from each section before export/saving or an invalid PCAP-NG file will result. Future work would include ensuring required/dependent frames were written along with those selected. Please try the patches and see if you don't agree that this is an improvement in PCAP-NG parsing. Thank you, Brandon Carpenter </pre> bugzilla-daemon< at >wireshark.org 2013-06-16T21:58:01 http://comments.gmane.org/gmane.network.wireshark.bugs/51100 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8806 Bug ID: 8806 Summary: Buildbot crash output: fuzz-2013-06-15-26126.pcap Classification: Unclassified Product: Wireshark Version: unspecified Hardware: x86-64 URL: http://www.wireshark.org/download/automated/captures/f uzz-2013-06-15-26126.pcap OS: Ubuntu Status: CONFIRMED Severity: Major Priority: High Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: buildbot-do-not-reply&lt; at &gt;wireshark.org Problems have been found with the following capture file: http://www.wireshark.org/download/automated/captures/fuzz-2013-06-15-26126.pcap stderr: Input file: /home/wireshark/menagerie/menagerie/10782-flowspec_redir_ext_com.pcap Build host information: Linux wsbb04 3.2.0-45-generic #70-Ubuntu SMP Wed May 29 20:12:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 12.04.2 LTS Release: 12.04 Codename: precise Buildbot information: BUILDBOT_REPOSITORY=http://code.wireshark.org/git/wireshark BUILDBOT_BUILDNUMBER=1936 BUILDBOT_URL=http://buildbot.wireshark.org/trunk/ BUILDBOT_BUILDERNAME=Clang-Code-Analysis BUILDBOT_SLAVENAME=clang-code-analysis BUILDBOT_GOT_REVISION=3846abe34d6861c6ee0bba61fcd5baa4d213885c Return value: 134 Dissector bug: 0 Valgrind error count: 0 Git commit commit 3846abe34d6861c6ee0bba61fcd5baa4d213885c Author: Michael Mann &lt;mmann78&lt; at &gt;netscape.net&gt; Date: Sun Jun 16 00:14:07 2013 +0000 Replace if-else-if with switch statements svn path=/trunk/; revision=49948 Command and args: ./tshark -nVxr ***MEMORY-ERROR***: [31391]: GSlice: MemChecker: failure in debugging tree: Cannot allocate memory [ no debug trace ] </pre> bugzilla-daemon< at >wireshark.org 2013-06-16T09:30:03 http://comments.gmane.org/gmane.network.wireshark.bugs/51083 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8805 Bug ID: 8805 Summary: Wireshark not recognizing skinny version 19 Classification: Unclassified Product: Wireshark Version: 1.10.0 Hardware: x86 OS: Windows XP Status: UNCONFIRMED Severity: Major Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: kevin.tang.nz&lt; at &gt;gmail.com Created attachment 10990 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10990&amp;action=edit packet capture file and screen dump Build Information: wireshark version 1.10 -- Current wireshark version 1.10 not recognizing skinny version 19. I have attached the packet capture file and screen dump. you can use free 7-zip software to open it. I also post this discuss in Linkedin wireshark user group. http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&amp;discussionID=248979661&amp;gid=64481&amp;commentID=144458731&amp;trk=view_disc&amp;ut=1tLFhwrY7CKRM1 </pre> bugzilla-daemon< at >wireshark.org 2013-06-15T06:47:16 http://comments.gmane.org/gmane.network.wireshark.bugs/51075 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8804 Bug ID: 8804 Summary: Remove check_col from PIDL dissecors Classification: Unclassified Product: Wireshark Version: SVN Hardware: All OS: All Status: UNCONFIRMED Severity: Enhancement Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: mmann78&lt; at &gt;netscape.net Created attachment 10989 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10989&amp;action=edit PIDL "source" with no check_col() calls Build Information: ersion 1.11.0 (SVN Rev 49941 from /trunk) Copyright 1998-2013 Gerald Combs &lt;gerald&lt; at &gt;wireshark.org&gt; 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 Jun 14 2013), with AirPcap. Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap. Intel(R) Core(TM) i7 CPU Q 720 &lt; at &gt; 1.60GHz, with 2047MB of physical memory. Built using Microsoft Visual C++ 10.0 build 40219 -- The attached patch is the changes necessary to generate the PIDL dissectors without any check_col() calls. I'm not sure what (if any) of this should be sent to samba. Haven't quite figured out the PIDL generation part, so if someone wants to take this patch and generate the necessary source, go right ahead. </pre> bugzilla-daemon< at >wireshark.org 2013-06-15T00:02:40 http://comments.gmane.org/gmane.network.wireshark.bugs/51073 <pre>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8803 Bug ID: 8803 Summary: iSCSI: Data-In PDUs are not reassembled if there is Bidirectional Read Residual Underflow. Classification: Unclassified Product: Wireshark Version: SVN Hardware: x86-64 OS: Windows 7 Status: UNCONFIRMED Severity: Major Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-admin&lt; at &gt;wireshark.org Reporter: uce&lt; at &gt;rjgodoy.com.ar Created attachment 10988 --&gt; https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10988&amp;action=edit patch that fixes the issue for ordered sequences, and breaks dissection of unordered sequences Build Information: iSCSI dissector from SVN (latest) compiled as plugin, and standard Wireshark distribution: Version 1.10.0 (SVN Rev 49790 from /trunk-1.10) Compiled (64-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, without Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 5 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) Core(TM) i5-3570K CPU &lt; at &gt; 3.40GHz, with 8074MB of physical memory. Built using Microsoft Visual C++ 10.0 build 40219 -- When there is Bidirectional Read Residual Underflow in the Data-In buffer (i.e. "some bytes were not transferred to the initiator out of the number of bytes expected to be transferred", in a bidirectional operation), the SCSI layer fails to reassemble the Data-In sequence (even if there is a single PDU in that Sequence). From my understanding of the SCSI reassembling process (packet-scsi.c:5618), that should happen for unidirectional Residual Underflow, but I haven't verified if that is the case. The actual transferred length can be computed from: 1. from the Residual Count in the SCSI Response PDU if the last Data-In PDU in the sequence does not have the S bit set. 2. from the Residual Count in the final Data-IN PDU if it has the S bit set. 3. as Buffer Offset + DataSegmentLength on the final Data-IN PDU, if there are several Data-In PDU, the first Buffer Offset is 0 (?), and the sequence is ordered (as in DataPDUInOrder=Yes) 4. as the difference between the largest (Buffer Offset + DataSegmentLength) and the smallest Buffer Offset. The submitted patch implements methods 2 and 3, and *works for me* since all my test cases are ordered (and I have no idea how to implement the other approaches, nor I can test them). This patch will break dissection of unordered sequences (even if they have no underflow condition). Example: SCSI Request PDU Bidirectional Read Data Length: 0x0040000 Data-In PDU Flags: 0x80 1... .... = F: Final PDU in sequence .... ...0 = S: Response does not contain SCSI status DataSegmentLength: 0x00000018 BufferOffset: 0x00000000 ResidualCount: 0x00000000 (no Residual Count because there is no Status) SCSI Response PDU DataSegmentLength: 0x00000000 BidiReadResidualCount: 0x0003ffe8 Flags: 0x88 .... 1... = u: Read part of bi-directional command underflowed </pre> bugzilla-daemon< at >wireshark.org 2013-06-14T23:48:13 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.wireshark.bugs