Wireshark mailing list archives

Re: F1AP Messages are not getting dissected correctly.


From: Pascal Quantin <pascal () wireshark org>
Date: Wed, 16 Dec 2020 18:52:05 +0100

Dear Simran,

Le mer. 16 déc. 2020 à 17:38, Simran Kumawat <kumawat.simran () 5g iith ac in>
a écrit :

Hi Sir/Ma'am,

This is Simran Kumawat, Project Associate at 5G-TestBed Project, IIT
Hyderabad.
I am working on the F1AP interface currently, I observed a few things as
mentioned below.
Wireshark is dissecting f1ap msgs like this -
1. Initiating Message ----------------------> Initiating Message
2. SuccessfulOutcome Message--------> Initiating Message
3. UnsuccessfulOutcome Message-----> SuccessfulOutcome Message
The information contained is also the same but the problem is  only at
this moment. for example ,
wireshark is dissecting F1SetupResponse ------------> F1SetupRequest and

F1SetupFailure----------------> F1SetupResponse
with the same content. There is no problem in the code because after
decoding at receiver side, I am printing the info contained in the packet.
I am attaching the wireshark capture for your reference and logs from
sender and receiver side.

I request you to please check with the issue mentioned above.
In case of any query, please get back to me.


Wireshark decodes your pcap as:
F1 Application Protocol
    F1AP-PDU: successfulOutcome (1)
        successfulOutcome
            procedureCode: id-F1Setup (1)
            criticality: reject (0)
            value
                F1SetupResponse
                    protocolIEs: 2 items
                        Item 0: id-TransactionID
                            ProtocolIE-Field
                                id: id-TransactionID (78)
                                criticality: reject (0)
                                value
                                    TransactionID: 20
                        Item 1: id-Cause
                            ProtocolIE-Field
                                id: id-Cause (0)
                                criticality: reject (0)
                                value
                                    Cause: radioNetwork (0)
                                        radioNetwork: unspecified (0)

Which matches the decoding obtained with other ASN.1 engines (like
https://asn1.io/asn1playground/ for example, as seen below):
F1AP-PDU ::= successfulOutcome : {
  procedureCode 1,
  criticality reject,
  value F1SetupResponse : {
    protocolIEs {
      {
        id 78,
        criticality reject,
        value TransactionID : 20
      },
      {
        id 0,
        criticality reject,
        value OCTET STRING : '00'H
      }
    }
  }
}

So the bug is on your side.

Best regards,
Pascal.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: