Few thoughts on this see inline
On 1/28/07, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:
On 1/27/07, Kriang Lerdsuwanakij <lerdsuwa@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> With above 3 changes together, dissecting Iub traces are correct for
> control and signaling planes. I am still investigating user plane
> frames because writing UMTS RLC/MAC protocol dissector is required.
> .
Hi Kriang,
This is very interesting to me.
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.
ALCAP would be the right one (afaik neither nbap nor ranap should bear
that information), but the problem here is that there's no relation
between the path-id and its vp/vc pair, in order to correlate the
aal2cpss with the alcap call there has to be a user provided table
that maps alcap's path-id to the vp/vc used for the path itself.
I tried to make the info in the struct as general as possible - I plan to
replace 'dct2000_variant' with a sub-version number (e.g. 7 for release
6.7.0), and also to add an 'interface' field to specify IuB or IuR.
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.
Good luck,
Martin
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan