Wireshark-bugs: [Wireshark-bugs] [Bug 9303] some DCERPC fragment are not identify leading to cor

Date: Tue, 05 Nov 2013 13:56:36 +0000

Comment # 12 on bug 9303 from
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (In reply to comment #8)
> > > > It seems that it's only on the second pass that this information will be
> > > > present.
> > > 
> > > That may be a bug in its own right, I will investigate.
> > 
> > The String is only constructed if field is referenced and the commet says
> > this is because of performance if memory serves.
> 
> Yes, OK that's actually a fairly significant performance win (~5% in my
> benchmarks). 
> 
> There is at least one other dissector (btobex) that uses layer_names for
> dissection though, so we might already have a subtle bug here regardless.
> Michael, CCing you so you can verify that the check on packet-btobex.c:1281
> should really pass on any unvisited packet carried over btrfcomm, and
> shouldn't depend on whether layer_names is referenced or not.
> 
> (Sorry, Matthieu, for somewhat hijacking your bug, but if we can get this
> figured out then the behaviour you want should become trivial).

What about changing it to a Gslist with the protocol handles or proto id
prepended that is always built? The string could be constructed from the list
of handles/ids when needed and possibly saved.


You are receiving this mail because:
  • You are watching all bug changes.