Hi,
I think you build a strong case for splitting the protocols and I don't
see a problem with it
but I don't have much first hand experience of GTP'...
If the CDR description is in ASN1 (3GPP TS 32.298?) a dissector for that
should be built using asn2wrs.
It might be beneficial to split the GTP' decoding and the actual CDR
dissection in different files
as that may make it easier to make hooks for proprietary formats.
Do you have any example traces to share?
Regards
Anders
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Bruce
Fitzsimons
Sent: den 20 februari 2008 09:01
To: Developer support list for Wireshark
Subject: [Wireshark-dev] GTP' (gtp prime) versus GTP dissector
Hullo list,
I am interested in opinions about if I should continue the current
arrangement of using the packet-gtp.c dissector to decode GTP' (gtp
prime) or not. The current decoder does not properly understand GTP' --
the following problems are evident:
1. The meaning of the last bit in the first byte. This has a name in
GTP, but is...not well described in GTP'. 3GPP TS 32.295 v7 has this
lovely explanation:
"Bit 1 of octet 1 is not used in GTP' (except in v0), and it is marked
'0' in the GTP' header. It is in use in GTP' v0 and distinguishes the
used header-length. In the case of GTP' v0, this bit being marked one
(1) indicates the usage of the 6 octets header. If the bit is set to '0'
(usually the case) the 20-octet header is used. For all other versions
of GTP', this bit is not used and is set to '0'. However, this does not
suggest the use of the 20-octet header, rather a shorter 6-octet
header."
This bit is incorrectly named (in GTP') terms when decoded today ("Is
SNDCP N-PDU included"), and in fact is documented the wrong way around -
GTPv0 with the bit set should say "no" with the current description
since the N-PDU (effectively padding to 20 bytes) is not there.
It really needs changing to be handled specially for GTP'.
2. GTP' is up to v2 but this version does not decode, mostly (I suspect)
due to the interpretation of the above field -- if the bit is not set
then it assumes a 20 byte header. It also says "None (2)" and decodes
it as GTP. I've not tried v1 but I assume the same problem exists.
3. The CDRs are not decoded or otherwise made very available. The hook
(to gtpcdr) is there and it is non-trivial to implement, but it is just
ASN.1 BER and the definitions are available.
4. GTP over TCP is not allowed (I think) after version 0, but GTP' over
UDP or TCP is permitted. Not really a big issue.
Other than that there is the little matter of exceptions for GTP'
scattered through the code. The /* charging */ messages and cause values
scattered through the code are not GTP (speaking strictly) at all.
I put it to the list that GTP' and GTP are not the same protocol. The
description of GTP' even says (R7) "In GTP' messaging only the
signalling plane of GTP is partly reused.". This cryptic little
statement, which is an amendment on the first version that implied a
closer relationship, really means that while it looks the same, and uses
a few of the same constructs, it really isn't the same animal at all.
This is especially the case now the version numbers have diverged.
I would like to separate the GTP and GTP' decoding into different files,
thereby cleaning up both protocol dissectors. The GTP' one becomes quite
simple up until someone gathers the courage to tidy up the ASN.1 and
deploy a full CDR decoder. I imagine that this would be/should be within
the same file?
Thoughts are welcome, I'm happy to do the split and tidy up the above
known buglets but I don't want to provoke a flame war that leads to it
being unused...I'd prefer to have the flame war now ;-)
Seriously though, having just written encode and decode routines for
GTP' ( http://open-cgf.googlecode.com ) I was struck by the differences,
and these bugs, and I'd like to fix it nicely. It is possible to fix
these bugs in place in packet-gtp.c but I believe the way it fails is an
indication that it is time to separate them.
Cheers,
Bruce
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
