gmane.network.wireshark.bugs

[Bug 8387] ZigBee ZCL OnOff cluster not recognized.

2013-05-22T21:52:32

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8387

Fabio Tarabelloni <fabio.tarabelloni< at >reloc.it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10130|0                           |1
        is obsolete|                            |
  Attachment #10827|                            |review_for_checkin?
              Flags|                            |

--- Comment #10 from Fabio Tarabelloni <fabio.tarabelloni< at >reloc.it> ---
Created attachment 10827
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10827&action=edit
Improved patch with fix

I hope to have fixed the suggested issue. I have compile the sources and create
the .diff file from Linux. It's the first time I use Linux to create a .diff
file, so I hope it works fine.

[Bug 8699] patch to support Raptor/Raptor-Q FEC inRMT dissector

2013-05-22T20:31:07

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8699

Michael Mann <mmann78< at >netscape.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10804|review_for_checkin?         |review_for_checkin+
              Flags|                            |

--- Comment #8 from Michael Mann <mmann78< at >netscape.net> ---
Comment on attachment 10804
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10804
patch to support  dissecting Raptor and Raptor Q FEC in RMT dissector

Committed to rev 49523.

[Bug 8707] Preferences with trailing commas areignored

2013-05-22T19:37:21

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8707

Cal Turney <turney_cal< at >emc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |turney_cal< at >emc.com

--- Comment #3 from Cal Turney <turney_cal< at >emc.com> ---
It is fairly common in our group for preferences such as gui.column.format to
be manually edited in profiles that are used with old and current versions of
Wireshark, and in versions with proprietary dissector plugins. In a few cases
we've failed to delete a trailing comma, saved the preferences file, and lost
an elaborate set of column definitions.

[Bug 8707] Preferences with trailing commas areignored

2013-05-22T19:02:53

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8707

--- Comment #2 from Cal Turney <turney_cal< at >emc.com> ---
Created attachment 10826
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10826&action=edit
Preference file containing gui.column.format with a trailing comma in the
column list

[Bug 8707] Preferences with trailing commas areignored

2013-05-22T18:59:51

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8707

Cal Turney <turney_cal< at >emc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10825|                            |review_for_checkin?
              Flags|                            |

--- Comment #1 from Cal Turney <turney_cal< at >emc.com> ---
Created attachment 10825
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10825&action=edit
In 'read_prefs_file()' if a trailing comma is detected it is eliminated, a
warning is issued, and if saved, the updated value is used.

[Bug 8707] New: Preferences with trailing commasare ignored

2013-05-22T18:57:55

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8707

            Bug ID: 8707
           Summary: Preferences with trailing commas are ignored
    Classification: Unclassified
           Product: Wireshark
           Version: 1.11.x (Experimental)
          Hardware: x86
                OS: All
            Status: UNCONFIRMED
          Severity: Minor
          Priority: Low
         Component: Wireshark
          Assignee: bugzilla-admin< at >wireshark.org
          Reporter: turney_cal< at >emc.com

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, wi

[Bug 8589] [PATCH] 9P dissector enhancement

2013-05-22T12:47:57

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8589

--- Comment #19 from Dominique Martinet <xvnfrhr.unzneqfjef< at >noclue.notk.org> ---
(In reply to comment #18)

Kind of a shame, but I guess the string itself isn't much compared to the size
of every packets of the capture... :)
Data is currently index by fid, but a fid is re-used as soon as it is freed, so
we will end up with many frame number intervals for a relatively limited set of
fids.
The _le functions and associated RB-tree look nice, I'm starting to think one
tree per fid in the current hashtable and lookup with this wouldn't be too bad.


I'll draft something and open a new bug with a v0 patch in a couple of weeks or
so.

[Bug 8700] Bluetooth: Highlight correct bytes insome SDP trees

2013-05-22T11:51:44

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8700

Michal Labedzki <michal.labedzki< at >tieto.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10824|                            |review_for_checkin?
              Flags|                            |

--- Comment #3 from Michal Labedzki <michal.labedzki< at >tieto.com> ---
Created attachment 10824
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10824&action=edit
[PATCH 2] Bluetooth: Highlight correct bytes in some SDP trees

Hi, thanks Michael. But we have a problem. Please see PATCH 2 content and
compare it to Wireshark SVN and GIT history:
http://code.wireshark.org/git/?p=wireshark;a=blobdiff;f=epan/dissectors/packet-btsdp.c;h=3f4841a4a26cdb53cc55cdaae2e3b4e6af1f3f13;hp=9a57c16709f66bd20f26adbf3c202fe6638130ca;hb=1bdf3446c5ef9bbe1d7cfc6a8b488ce9d3b57e7d;hpb=f4bb7f45beea42d193367601d9b4dc9e5989f25c
 and GIT code - GIT code is the same like

[Bug 8700] Bluetooth: Highlight correct bytes insome SDP trees

2013-05-22T11:45:07

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8700

Michal Labedzki <michal.labedzki< at >tieto.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |INCOMPLETE
         Resolution|FIXED                       |---
     Ever confirmed|0                           |1

[Bug 8633] New Dissector for Common Address Redundancy Protocol (CARP)

2013-05-22T08:56:54

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8633

--- Comment #6 from Alexis La Goutte <alexis.lagoutte< at >gmail.com> ---
(In reply to comment #5)
Do you see often a VRRP with 7 IP Address ?

May be add a pref to disable CARP...

[Bug 8633] New Dissector for Common Address Redundancy Protocol (CARP)

2013-05-22T08:44:33

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8633

Uli Heilmeier <uh< at >heilmeier.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10727|0                           |1
        is obsolete|                            |
  Attachment #10823|                            |review_for_checkin?
              Flags|                            |

--- Comment #5 from Uli Heilmeier <uh< at >heilmeier.eu> ---
Created attachment 10823
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10823&action=edit
CARP dissector patch

Thanks Martin and Alexis for your comments.
< at >Martin: Writing the dissector was inspired by your GUUG workshop. Thanks for
that.

I changed the things Martin mentioned.
To check if the packet is really CARP I used the length and the Auth len field.
Unfortunately a VRRP packet may also have an address count of 7 and can also
have more than 36 bytes. So the check is not safe.
At least the

[Bug 8633] New Dissector for Common Address Redundancy Protocol (CARP)

2013-05-22T08:33:06

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8633

--- Comment #4 from Uli Heilmeier <uh< at >heilmeier.eu> ---
Created attachment 10822
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10822&action=edit
Sample capture for VRRP

A sample for one form of VRRP.

[Bug 8691] Adding support of BGP flow spec RFC 5575

2013-05-22T08:07:22

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8691

Alexis La Goutte <alexis.lagoutte< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10805|0                           |1
        is obsolete|                            |
  Attachment #10805|review_for_checkin?         |
              Flags|                            |

[Bug 8691] Adding support of BGP flow spec RFC 5575

2013-05-22T08:06:58

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8691

Alexis La Goutte <alexis.lagoutte< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10821|0                           |1
           is patch|                            |
  Attachment #10821|application/octet-stream    |text/plain
          mime type|                            |
  Attachment #10821|                            |review_for_checkin?
              Flags|                            |

[Bug 8706] "Stream" should be changed to "Follow Stream" in the 'Font and Colors' dialog

2013-05-22T01:55:25

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8706

--- Comment #2 from Evan Huus <eapache< at >gmail.com> ---
Scheduled for backport for the next RC of 1.10.

[Bug 8706] "Stream" should be changed to "Follow Stream" in the 'Font and Colors' dialog

2013-05-22T01:50:40

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8706

Evan Huus <eapache< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |eapache< at >gmail.com
         Resolution|---                         |FIXED

[Bug 8706] "Stream" should be changed to "Follow Stream" in the 'Font and Colors' dialog

2013-05-22T01:50:29

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8706

Evan Huus <eapache< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10820|review_for_checkin?         |review_for_checkin+
              Flags|                            |

--- Comment #1 from Evan Huus <eapache< at >gmail.com> ---
Comment on attachment 10820
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=10820
Patches to prefs_font_color.c

Great suggestion, committed in r49488.

[Bug 8703] TCP conversation: bits/sec calculationmisleading

2013-05-22T01:25:07

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8703

Evan Huus <eapache< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eapache< at >gmail.com
           Hardware|x86-64                      |All
            Version|1.8.7                       |SVN
                 OS|Windows 7                   |All
           Severity|Normal                      |Minor

--- Comment #1 from Evan Huus <eapache< at >gmail.com> ---
For the first case we could potentially do something special when we don't have
a statistically significant number of packets - I'm not sure what that
'something special' would be though. Maybe just put the rate as N/A and then
put an explanation in a tooltip?

The second case is much trickier - there are statistical techniques for
removing outliers, but they're complicated, not always appropriate, and
probably wouldn't work in your case anyways because

[Bug 8705] "No such preference" warnings are displayed for 5 obsolete and 1 platform-specific preference

2013-05-21T22:55:29

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8705

--- Comment #9 from Cal Turney <turney_cal< at >emc.com> ---
(In reply to comment #8)

Except when the

Thanks to you both for the education.  And, Guy, thanks for relieving me of the
responsibility (OK, the compulsion) to stylistically terraform every file I
happen to be working in. :=)

[Bug 8705] "No such preference" warnings are displayed for 5 obsolete and 1 platform-specific preference

2013-05-21T22:29:41

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8705

Jeff Morriss <jeff.morriss.ws< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeff.morriss.ws< at >gmail.com

--- Comment #8 from Jeff Morriss <jeff.morriss.ws< at >gmail.com> ---
(In reply to comment #7)

Except when the thing being switched on is an enum in which case it's useful to
NOT have a default case: that way a (good) compiler can warn you that you've
missed a case.

[Bug 8705] "No such preference" warnings are displayed for 5 obsolete and 1 platform-specific preference

2013-05-21T22:02:04

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8705

--- Comment #7 from Guy Harris <guy< at >alum.mit.edu> ---
(In reply to comment #6)

Somewhat neutral.  C's switch statement's "fallthrough" property is a bit
weird, and break statements could be considered to be an "end this arm of the
conditional" delimiters, and, as such, useful even if they follow a return or a
goto.