Hello
Thank you for your comment. Here is my thought:
I wrote the FP dissector to work with Catapult DCT2000 log files,
which for me are often user-plane only tests without NBAP or ALCAP
traffic. The dissector relies upon per-frame information being
available (see struct _fp_info from packet-umts_fp.h). For DCT2000,
this information is stored separately for each frame, and attached to
the packet before the FP dissector will be called. If the same
information is not available with K12xx, it could also be made to
alternatively look up some global tables or conversation data created
by the NBAP or ALCAP dissectors.
That is the part I am still figuring out. For K12xx, there are
per-source and per packet
information. Also some more information is in *.stk file. For the part
inside *.stk, tables will
be unavoidable.
I have not considered trying to dissect the MAC and RLC headers within
the FP TBs. This would be hard because you would need to know all of
their configuration details and effectively to simulate those layers
and the primitives exchanged between them. For me, just having
Wireshark's filtering and graphing available for the FP layer has
already been *very* useful.
My target would be the ability to dissect RRC messages. I am not really
sure how
much work is involved in RLC/MAC work. Thank you for pointing this issue
out.
Now I have to add those channel reconfiguration messages into the design.
Best regards
Kriang
