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

[Bruce Fitzsimons <Bruce@xxxxxxxxxxxxxx>]

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