ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: [Wireshark-dev] GTP' (gtp prime) versus GTP dissector

From: Bruce Fitzsimons <Bruce@xxxxxxxxxxxxxx>
Date: Wed, 20 Feb 2008 21:01:29 +1300
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