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

_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to