Wireshark-bugs: [Wireshark-bugs] [Bug 9303] some DCERPC fragment are not identify leading to cor
Comment # 12
on bug 9303
from Anders Broman
(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.
