Ask Your Question
0

PFCP dissector for 3GPP 29.244 Sx interface

asked 2019-04-16 09:00:37 +0000

dandreye gravatar image

Hi All,

Assuming Wireshark already has PFCP dissector by now (seems like it does from a neighbour PFCP thread) do I need to do anything particular to have mine decoded? Getting "malformed" for every single PFCP packet with Wireshark version 2.6.7 for some reason:

Screenshot: https://drive.google.com/open?id=1C6t...

pcapng: https://drive.google.com/open?id=1HwB...

Many thanks in anticipation!..

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-04-16 10:35:42 +0000

Anders gravatar image

You should try with Wireshark 3.0. It has a more up to date dissector.

edit flag offensive delete link more

Comments

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

Anders gravatar imageAnders ( 2019-04-16 10:44:42 +0000 )edit

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

dandreye gravatar imagedandreye ( 2019-04-16 13:02:03 +0000 )edit

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)

dandreye gravatar imagedandreye ( 2019-04-17 11:11:52 +0000 )edit

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                                  |

*/
Anders gravatar imageAnders ( 2019-04-17 12:07:12 +0000 )edit

"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?

dandreye gravatar imagedandreye ( 2019-04-17 15:46:16 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-04-16 09:00:37 +0000

Seen: 1,637 times

Last updated: Apr 16 '19