Wireshark-dev: Re: [Wireshark-dev] [PATCH] Support ALCAP, NBAP over SSCOP in K12xx
Hello,
You are right, I believe that RRC configures RLC, MAC and FP channels from its own field. There is a beginning to an RRC dissector, whose main dissection function currently doesn't call into the generated ASN.1
code. I don't know enough about RRC to know what that entry point should be.
One of the problems with dissecting MAC headers is that the header for one channel can depend upon what is configured on other channels, e.g. if you have more than one DCH channel, you add the CT field, whereas if there is only one, it should be missed out.
Anyway, I hope we can work out how to at least call the FP dissector.
Regards,
Martin
On 1/28/07, Kriang Lerdsuwanakij <lerdsuwa@xxxxxxxxxxxxxxxxxxxxx> wrote:
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
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
