free5gc/pfcp

pfcp's Issues

PFCP module modifications to be used for UPF

Hi team,

I'm interested to use this module, to implement N4 interface handling but from UPF, from the historical usages of this module this looks to be used by SMF rather than UPF, but by looking at the code, I don't see references or limitations that this can only be used by SMF.

My question is, can this be potentially used or modified to be implemented in UPF node side to connect to SMF?

Thanks

decode skips the first byte of network instance

Network Instance sent in the packet:

Create PDR : [Grouped IE]
    IE Type: Create PDR (1)
    IE Length: 115
    PDR ID : 21
    Precedence : 1
    PDI : [Grouped IE]
        IE Type: PDI (2)
        IE Length: 68
        Source Interface : Access
        F-TEID : 
        Network Instance : n3-nw
            IE Type: Network Instance (22)
            IE Length: 5
            **Network Instance: n3-nw**
        SDF Filter : 
        QFI : 
    Outer Header Removal : GTP-U/UDP/IPv4
    FAR ID : Dynamic by CP 21
    URR ID : Dynamic by CP 12
    QER ID : Dynamic by CP 6
Create PDR : [Grouped IE]
    IE Type: Create PDR (1)
    IE Length: 120
    PDR ID : 22
    Precedence : 1
    PDI : [Grouped IE]
        IE Type: PDI (2)
        IE Length: 78
        Source Interface : Core
        Network Instance : dnn.keysight.com
            IE Type: Network Instance (22)
            IE Length: 16
            **Network Instance: dnn.keysight.com**
        UE IP Address : 
            IE Type: UE IP Address (93)
            IE Length: 5
            Flags: 0x06, S/D, V4 (IPv4)
            IPv4 address: 172.16.0.1
        SDF Filter : 
    FAR ID : Dynamic by CP 22
    URR ID : Dynamic by CP 12
    QER ID : Dynamic by CP 6
Create FAR : [Grouped IE]
Create FAR : [Grouped IE]
PDN Type : IPv4
Create URR : [Grouped IE]
Create QER : [Grouped IE]

First byte is missing in the decoded value of Network Instance in PDI
type PDI struct {
SourceInterface *pfcpType.SourceInterface tlv:"20"
LocalFTEID *pfcpType.FTEID tlv:"21"
*NetworkInstance util_3gpp.Dnn tlv:"22"
UEIPAddress *pfcpType.UEIPAddress tlv:"93"
TrafficEndpointID *pfcpType.TrafficEndpointID tlv:"131"
SDFFilter *pfcpType.SDFFilter tlv:"23"
ApplicationID *pfcpType.ApplicationID tlv:"24"
EthernetPDUSessionInformation *pfcpType.EthernetPDUSessionInformation tlv:"142"
EthernetPacketFilter *EthernetPacketFilter tlv:"132"
QFI []*pfcpType.QFI tlv:"124"
FramedRoute *pfcpType.FramedRoute tlv:"153"
FramedRouting *pfcpType.FramedRouting tlv:"154"
FramedIPv6Route *pfcpType.FramedIPv6Route tlv:"155"
}

[51 45 110 119] <-- [3-nw] n is missing
[110 110 46 107 101 121 115 105 103 104 116 46 99 111 109] <--[nn.keysight.com] d is missing

This happens due to bug in UnmarshalBinary method in util_3gpp

func (d *Dnn) UnmarshalBinary(data []byte) error {

(*d) = data[1:]   <-- This skips the first byte
return nil

}

[Bugs] Association related message do not support multiple information element UserPlaneIPResourceInformation

Describe the bug

I have found TS 29.244 release 15 shows multiple UserPlaneIPResourceInformation can be present in some association related message.

To Reproduce

Expected behavior

Multiple IE with the same IE type UserPlaneIPResourceInformation can be present to represent multiple user plane resource information.

Screenshots

Environment (please complete the following information):

Trace File

Configuration File

PCAP File

Log File

Additional context

SMF and UPF in free5GC must modified