PFCP dissector for 3GPP 29.244 Sx interface

edit

The packet looks malforned, Wireshark decodes according to 3GPP TS 29.244 V15.3.0 (2018-09-23)

Anders: thank you: it's still the same with Wireshark 3.0.1, so checking message encoding internally now.

Anders: I now have a confirmation from Engineering that it's 29.244 V15.5.0 at our side and also that a number of private extensions besides 3GPP standard IEs are used. Assuming that it's the private ones that are causing this issue and also assuming that it's possible at all to delimit one IE from another solely based on the length values in them all is there anything preventing Wireshark from displaying them all individually and decoding all 3GPP standard ones while flagging all unknown/private ones accordingly? (instead of flagging the whole message as malformed)

As far as I can see the message header is malformed, the protocol has provissions for private IEs and the dissector should handle those.

    /* 7.2.2    Message Header */
/*
    Octet     8     7     6     5     4     3     2     1
      1    | Version         |Spare|Spare|Spare|  MP  |  S  |
      2    |        Message Type                            |
      3    |        Message Length (1st Octet)              |
      4    |        Message Length (2nd Octet)              |
    m to   | If S flag is set to 1, then SEID shall be      |
    k(m+7) | placed into octets 5-12. Otherwise, SEID field |
           | is not present at all.                         |
    n to   | Sequence Number                                |
    (n+2)  |                                                |
    (n+3)  |         Spare                                  |

*/

"As far as I can see the message header is malformed" - I'm sorry but would it be possible to point out exactly what's wrong with the message header itself? The first 16 octets carrying it seem to be decoded perfectly well and only what follows is flagged as malformed... In fact assuming the latter is an IE, even if the "78 da" is a valid standard IE type (<32767 are supposed to be the standard ones) the "63 e0" doesn't look like a valid IE length. Is there anything else that can reside between message header and the first IE by chance?