For bi-directions, the rules are created in the same form as for downlink
as shown below, so to apply them for uplink, we need to swap the rules
according to the interface.
RX : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
GX : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
PFCP : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
RULE : Source <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> Destination <UE_IP> <UE_PORT>
TFT : Local <UE_IP> <UE_PORT> REMOTE <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
RX : permit in from <UE_IP> <UE_PORT> to <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
GX : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
PFCP : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
RULE : Source <UE_IP> <UE_PORT> Destination <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
TFT : Local <UE_IP> <UE_PORT> REMOTE <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
As mentioned in the sgwu.yaml configuration file, it is possible to configure multiple addresses with different source_interface values for the gtpu interface.
Following the this section, I defined two addresses, one with source_interface set to 0 and another with source_interface set to 1. My expectation was to see different addresses for the two PDRs in the Session Establishment Response message during session establishment. However, both addresses were the same, and it was the address I had set for source_interface = 0.
When I looked into the code, I found the reason for the issue. In the lib/pfcp/context.c file, on line 1185, the function that determines the address is called as follows:
...
} else {
ogs_gtpu_resource_t *resource = NULL;
resource = ogs_pfcp_find_gtpu_resource(
&ogs_gtp_self()->gtpu_resource_list,
pdr->dnn, OGS_PFCP_INTERFACE_ACCESS);
if (resource) {
...
In the last parameter of this function, a constant value, OGS_PFCP_INTERFACE_ACCESS, is used. This causes every PDR with any source_interface to be considered as "access," and the value 0 is used for its interface.
I replaced the value with pdr->src_if, and the bug was resolved.
Scenario is handover on S1AP, data forwarding is enabled, and
the Source ENB is forwarding DL PDCP packets to EPC(SGWU)
with PDCP SN included. SGWU is also forwarding these packets
to the Target ENB.
However the PDCP SN is not present in the forwarded packets
from SGWU to Target ENB.
I modified this part, and there was the same problem in 5GC, fixed it as well.
A lot of code in GTP-U has been modified,
so if you have any problems, please let us know right away.
After examining the call stack and reading the source code, I found that
in /lib/core/ogs-pool.h line 152: (pool)->array[i] = i+1;
then in lib/pfcp/context.c line 78: pdr_random_to_index[ogs_pfcp_pdr_teid_pool.array[i]] = i;
ogs_pfcp_pdr_teid_pool.array[i] may exceed the size of pdr_random_to_index, leading to a heap-buffer-overflow.
When converting bitrates from bits per second to kilobits per second,
if the conversion results in fractions, the resulting value should be
rounded upwards
ogs_pool_init() shall be used in the initialization routine.
Otherwise, memory will be fragment since this function uses system malloc()
Compared with ogs_pool_init()
ogs_pool_create() could be called while the process is running,
so this function should use ogs_malloc() instead of system malloc()
TS23.007 17.4.1
19A PFCP based restart procedures
After a PFCP entity has restarted, it shall immediately update all local Recovery Time Stamps and shall clear all remote
Recovery Time Stamps. When peer PFCP entities information is available, i.e. when the PFCP Association is still alive,
the restarted PFCP entity shall send its updated Recovery Time Stamps in a Heartbeat Request message to the peer
PFCP entities before initiating any PFCP session signalling.
* [pfcp] response_timeout should never call ogs_pfcp_xact_delete (#50)
* also remove ogs_pfcp_xact_delete since never called
* also had to catch one more ogs_pfcp_sendto()
---------
Co-authored-by: Spencer Sevilla <spencer@MacBook-Air.local>
A buffer overflow occurred in ALPINE
because the size of the pfcp message structure increased by
ogs_pfcp_tlv_framed_route_t framed_route[8];
ogs_pfcp_tlv_framed_ipv6_route_t framed_ipv6_route[8];