Wireshark-bugs: [Wireshark-bugs] [Bug 9303] some DCERPC fragment are not identify leading to cor
Comment # 13
on bug 9303
from Anders Broman
(In reply to comment #12)
> (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.
The GSlist should be in frame data.
You are receiving this mail because:
- You are watching all bug changes.
