Comment # 16
on bug 8947
from Simon Zhong
> I don't think this isn't going to work in all situations. I believe the
> request/response should only be setup on the "first pass", which can't be
> done because the cops_tree will always be NULL on the first pass.
> packet_info has its own variable for detecting "first pass",
> pinfo->fd->flags.visited. That's the only variable that should be used for
> detecting "first pass".
I use diameter dissector as reference, so flags.visited was my first choice,
then I realized that because handle is not in COPS message header
(hop-by-hop-id in diameter is), the 'first pass' doesn't trigger COPS PDU
(which contains handle) dissecting, then while the 'second pass' happens, the
visited flag was already set, so I can't check this flag to determine if the
packet has been processed. That's why I have my own frame_visited flag, and I
have to go through the checking every time.
I understand it's ineffective, and maybe I also misunderstood some basic
concepts. I appropriate if you can point me to a sample which dissect filed
that is not in protocol header but need to be traced, I will definitely go the
more efficient (and correct) way.
> Also, the code to get the "COPS handle" is VERY hacky (handle_hfid is
> completely unnecessary). I think you may be able to just do some of the
> "conversation processing" at the time the handle is dissected, so you don't
> need to "retrieve it retroactively". If "NULL trees" are preventing the
> dissection, perhaps the better solution is to remove them.
> proto_tree_add_xxx calls are protected already protected from NULL trees, it
> would just be an optimization to add the NULL tree check. Typically this
> should only be done around a large group of proto_tree_add_xxx calls that
> don't have other "dissection functionality" (like creating conversation
> data).
I guess this also caused by the algorithm I used to dissect handle field?
Please correct me if I was wrong. Thanks.
You are receiving this mail because:
- You are watching all bug changes.
