Comment # 9
on bug 7393
from john dite
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #1)
> > > After a quick look at the source code, no dissector is registered for the ED
> > > TPDU data part => adjusting the bug summary accordingly.
> >
> > I'm not a programmer, but I have read up a bit of how the dissectors are
> > supposed to work.
> > Your comment regarding a specific dissector surprised me, as I would have
> > expected any data parts, independent of the OSI Transport PDU type where
> > they occurred, to be passed to the next higher level dissector that has
> > registered itself to the cotp dissector list, in this case the OSI Session
> > dissector packet-ses.c. Am I missing something ?
>
> So as to be able to identify what the next higher level dissector is, the
> dissector must be able to identify which data should be forwarded, and to
> which dissector (either heuristically or by an identifier allowing to
> exactly identify what the higher level protocol is). This is not currently
> done for ED-TPDU, as seen in packet-ositp.c function ositp_decode_ED(): it
> systematically send the payload to the data dissector, with a comment
> indicating that something is missing:
> /*
> * XXX - hand this to subdissectors but tell them that this is
> * in an ED packet?
> */
Thanks for update. I've looked at packet-ositp.c at the functions
ositp_decode_ED() and ositp_decode_DT() and the only thing that stands out with
regards to dissectors is the *subdissector_found pointer referenced in
ositp_decode_DT(). I did not glean from the comments in ositp_decode_ED() that
something was missing. The call_dissector() calls looked similar in
ositp_decode_ED() to that of ositp_decode_DT(). Still trying to learn.
You are receiving this mail because:
- You are watching all bug changes.