[Pascal Quantin <pascal@xxxxxxxxxxxxx>]

Dear Simran,

Le mer. 16 déc. 2020 à 17:38, Simran Kumawat <kumawat.simran@xxxxxxxxxxxxx> 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.