2020-04-26 19:36:05 +00:00
|
|
|
/*
|
2024-03-25 23:04:26 +00:00
|
|
|
* Copyright (C) 2019-2023 by Sukchan Lee <acetcom@gmail.com>
|
2020-04-26 19:36:05 +00:00
|
|
|
*
|
|
|
|
* This file is part of Open5GS.
|
|
|
|
*
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU Affero General Public License as published by
|
|
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program. If not, see <https://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "context.h"
|
|
|
|
#include "pfcp-path.h"
|
2020-06-18 01:43:16 +00:00
|
|
|
#include "gtp-path.h"
|
2020-04-26 19:36:05 +00:00
|
|
|
#include "n4-handler.h"
|
|
|
|
|
2022-04-08 14:10:42 +00:00
|
|
|
static void upf_n4_handle_create_urr(upf_sess_t *sess, ogs_pfcp_tlv_create_urr_t *create_urr_arr,
|
|
|
|
uint8_t *cause_value, uint8_t *offending_ie_value)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
ogs_pfcp_urr_t *urr;
|
|
|
|
|
|
|
|
*cause_value = OGS_PFCP_CAUSE_REQUEST_ACCEPTED;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_URR; i++) {
|
|
|
|
urr = ogs_pfcp_handle_create_urr(&sess->pfcp, &create_urr_arr[i],
|
|
|
|
cause_value, offending_ie_value);
|
|
|
|
if (!urr)
|
|
|
|
return;
|
|
|
|
|
2022-05-24 13:54:30 +00:00
|
|
|
/* TODO: enable counters somewhere else if ISTM not set, upon first pkt received */
|
|
|
|
if (urr->meas_info.istm) {
|
|
|
|
upf_sess_urr_acc_timers_setup(sess, urr);
|
2022-04-08 14:10:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
void upf_n4_handle_session_establishment_request(
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
upf_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message)
|
2020-04-26 19:36:05 +00:00
|
|
|
{
|
2020-07-20 01:42:58 +00:00
|
|
|
ogs_pfcp_pdr_t *pdr = NULL;
|
2020-08-13 00:31:22 +00:00
|
|
|
ogs_pfcp_far_t *far = NULL;
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_pfcp_pdr_t *created_pdr[OGS_MAX_NUM_OF_PDR];
|
|
|
|
int num_of_created_pdr = 0;
|
|
|
|
uint8_t cause_value = 0;
|
|
|
|
uint8_t offending_ie_value = 0;
|
|
|
|
int i;
|
|
|
|
|
2023-04-15 09:54:03 +00:00
|
|
|
ogs_pfcp_sereq_flags_t sereq_flags;
|
|
|
|
bool restoration_indication = false;
|
|
|
|
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_session_establishment_request_t *req = NULL;
|
|
|
|
|
2022-08-19 12:08:27 +00:00
|
|
|
upf_metrics_inst_global_inc(UPF_METR_GLOB_CTR_SM_N4SESSIONESTABREQ);
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_assert(xact);
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_assert(message);
|
|
|
|
req = &message->pfcp_session_establishment_request;
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_assert(req);
|
|
|
|
|
2020-07-09 05:38:09 +00:00
|
|
|
ogs_debug("Session Establishment Request");
|
2020-04-26 19:36:05 +00:00
|
|
|
|
|
|
|
cause_value = OGS_PFCP_CAUSE_REQUEST_ACCEPTED;
|
|
|
|
|
|
|
|
if (!sess) {
|
2020-12-03 06:16:57 +00:00
|
|
|
ogs_error("No Context");
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_send_error_message(
|
|
|
|
xact, sess ? sess->smf_n4_f_seid.seid : message->h.seid,
|
2020-04-26 19:36:05 +00:00
|
|
|
OGS_PFCP_SESSION_ESTABLISHMENT_RESPONSE_TYPE,
|
2020-12-03 06:16:57 +00:00
|
|
|
OGS_PFCP_CAUSE_MANDATORY_IE_MISSING, 0);
|
2022-08-19 12:08:27 +00:00
|
|
|
upf_metrics_inst_by_cause_add(OGS_PFCP_CAUSE_MANDATORY_IE_MISSING,
|
|
|
|
UPF_METR_CTR_SM_N4SESSIONESTABFAIL, 1);
|
2020-04-26 19:36:05 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-04-15 09:54:03 +00:00
|
|
|
memset(&sereq_flags, 0, sizeof(sereq_flags));
|
|
|
|
if (req->pfcpsereq_flags.presence == 1)
|
|
|
|
sereq_flags.value = req->pfcpsereq_flags.u8;
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_PDR; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
created_pdr[i] = ogs_pfcp_handle_create_pdr(&sess->pfcp,
|
2023-04-15 09:54:03 +00:00
|
|
|
&req->create_pdr[i], &sereq_flags,
|
|
|
|
&cause_value, &offending_ie_value);
|
2020-04-26 19:36:05 +00:00
|
|
|
if (created_pdr[i] == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
num_of_created_pdr = i;
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_FAR; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_create_far(&sess->pfcp, &req->create_far[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2022-04-08 14:10:42 +00:00
|
|
|
upf_n4_handle_create_urr(sess, &req->create_urr[0], &cause_value, &offending_ie_value);
|
2021-10-04 13:28:32 +00:00
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2023-04-11 08:28:33 +00:00
|
|
|
if (req->apn_dnn.presence) {
|
|
|
|
char apn_dnn[OGS_MAX_DNN_LEN+1];
|
|
|
|
|
|
|
|
ogs_assert(0 < ogs_fqdn_parse(apn_dnn, req->apn_dnn.data,
|
|
|
|
ogs_min(req->apn_dnn.len, OGS_MAX_DNN_LEN)));
|
|
|
|
|
|
|
|
if (sess->apn_dnn)
|
|
|
|
ogs_free(sess->apn_dnn);
|
|
|
|
sess->apn_dnn = ogs_strdup(apn_dnn);
|
|
|
|
ogs_assert(sess->apn_dnn);
|
|
|
|
}
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_QER; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_create_qer(&sess->pfcp, &req->create_qer[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
2023-04-11 08:28:33 +00:00
|
|
|
upf_metrics_inst_by_dnn_add(sess->apn_dnn,
|
|
|
|
UPF_METR_GAUGE_UPF_QOSFLOWS, 1);
|
2020-04-26 19:36:05 +00:00
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2020-12-03 06:16:57 +00:00
|
|
|
ogs_pfcp_handle_create_bar(&sess->pfcp, &req->create_bar,
|
|
|
|
&cause_value, &offending_ie_value);
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2023-05-14 01:19:37 +00:00
|
|
|
/* Setup GTP Node */
|
|
|
|
ogs_list_for_each(&sess->pfcp.far_list, far) {
|
|
|
|
if (OGS_ERROR == ogs_pfcp_setup_far_gtpu_node(far)) {
|
|
|
|
ogs_fatal("CHECK CONFIGURATION: upf.gtpu");
|
|
|
|
ogs_fatal("ogs_pfcp_setup_far_gtpu_node() failed");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
if (far->gnode)
|
|
|
|
ogs_pfcp_far_f_teid_hash_set(far);
|
|
|
|
}
|
|
|
|
|
2023-04-15 09:54:03 +00:00
|
|
|
/* PFCPSEReq-Flags */
|
|
|
|
if (sereq_flags.restoration_indication == 1) {
|
|
|
|
for (i = 0; i < num_of_created_pdr; i++) {
|
|
|
|
pdr = created_pdr[i];
|
|
|
|
ogs_assert(pdr);
|
|
|
|
|
|
|
|
if (pdr->f_teid_len)
|
|
|
|
ogs_pfcp_pdr_swap_teid(pdr);
|
|
|
|
}
|
|
|
|
restoration_indication = true;
|
|
|
|
}
|
|
|
|
|
2020-07-20 01:42:58 +00:00
|
|
|
for (i = 0; i < num_of_created_pdr; i++) {
|
|
|
|
pdr = created_pdr[i];
|
|
|
|
ogs_assert(pdr);
|
|
|
|
|
2020-12-03 06:16:57 +00:00
|
|
|
/* Setup UE IP address */
|
2022-04-14 08:34:55 +00:00
|
|
|
if (pdr->ue_ip_addr_len) {
|
|
|
|
if (req->pdn_type.presence == 1) {
|
2022-06-23 13:04:01 +00:00
|
|
|
cause_value = upf_sess_set_ue_ip(sess, req->pdn_type.u8, pdr);
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
2022-04-14 08:34:55 +00:00
|
|
|
} else {
|
|
|
|
ogs_error("No PDN Type");
|
|
|
|
}
|
2020-12-03 06:16:57 +00:00
|
|
|
}
|
|
|
|
|
2023-01-18 11:32:42 +00:00
|
|
|
if (pdr->ipv4_framed_routes) {
|
|
|
|
cause_value =
|
|
|
|
upf_sess_set_ue_ipv4_framed_routes(sess,
|
|
|
|
pdr->ipv4_framed_routes);
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pdr->ipv6_framed_routes) {
|
|
|
|
cause_value =
|
|
|
|
upf_sess_set_ue_ipv6_framed_routes(sess,
|
|
|
|
pdr->ipv6_framed_routes);
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2020-12-03 06:16:57 +00:00
|
|
|
/* Setup UPF-N3-TEID & QFI Hash */
|
2023-04-15 09:54:03 +00:00
|
|
|
if (pdr->f_teid_len)
|
|
|
|
ogs_pfcp_object_teid_hash_set(
|
|
|
|
OGS_PFCP_OBJ_SESS_TYPE, pdr, restoration_indication);
|
2020-07-20 01:42:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Send Buffered Packet to gNB/SGW */
|
|
|
|
ogs_list_for_each(&sess->pfcp.pdr_list, pdr) {
|
|
|
|
if (pdr->src_if == OGS_PFCP_INTERFACE_CORE) { /* Downlink */
|
2020-08-13 00:31:22 +00:00
|
|
|
ogs_pfcp_send_buffered_packet(pdr);
|
2020-07-20 01:42:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-04-15 09:54:03 +00:00
|
|
|
if (restoration_indication == true ||
|
|
|
|
ogs_pfcp_self()->up_function_features.ftup == 0)
|
|
|
|
ogs_assert(OGS_OK ==
|
|
|
|
upf_pfcp_send_session_establishment_response(
|
|
|
|
xact, sess, NULL, 0));
|
|
|
|
else
|
|
|
|
ogs_assert(OGS_OK ==
|
|
|
|
upf_pfcp_send_session_establishment_response(
|
|
|
|
xact, sess, created_pdr, num_of_created_pdr));
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
cleanup:
|
2022-08-19 12:08:27 +00:00
|
|
|
upf_metrics_inst_by_cause_add(cause_value,
|
|
|
|
UPF_METR_CTR_SM_N4SESSIONESTABFAIL, 1);
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_pfcp_sess_clear(&sess->pfcp);
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_send_error_message(
|
|
|
|
xact, sess ? sess->smf_n4_f_seid.seid : message->h.seid,
|
2020-04-26 19:36:05 +00:00
|
|
|
OGS_PFCP_SESSION_ESTABLISHMENT_RESPONSE_TYPE,
|
|
|
|
cause_value, offending_ie_value);
|
|
|
|
}
|
|
|
|
|
|
|
|
void upf_n4_handle_session_modification_request(
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
upf_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message)
|
2020-04-26 19:36:05 +00:00
|
|
|
{
|
2020-07-20 01:42:58 +00:00
|
|
|
ogs_pfcp_pdr_t *pdr = NULL;
|
2020-08-13 00:31:22 +00:00
|
|
|
ogs_pfcp_far_t *far = NULL;
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_pfcp_pdr_t *created_pdr[OGS_MAX_NUM_OF_PDR];
|
|
|
|
int num_of_created_pdr = 0;
|
|
|
|
uint8_t cause_value = 0;
|
|
|
|
uint8_t offending_ie_value = 0;
|
|
|
|
int i;
|
|
|
|
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_session_modification_request_t *req = NULL;
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_assert(xact);
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_assert(message);
|
|
|
|
req = &message->pfcp_session_modification_request;
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_assert(req);
|
|
|
|
|
2020-07-09 05:38:09 +00:00
|
|
|
ogs_debug("Session Modification Request");
|
2020-04-26 19:36:05 +00:00
|
|
|
|
|
|
|
cause_value = OGS_PFCP_CAUSE_REQUEST_ACCEPTED;
|
|
|
|
|
|
|
|
if (!sess) {
|
2020-08-13 00:31:22 +00:00
|
|
|
ogs_error("No Context");
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_send_error_message(
|
|
|
|
xact, sess ? sess->smf_n4_f_seid.seid : message->h.seid,
|
2020-04-26 19:36:05 +00:00
|
|
|
OGS_PFCP_SESSION_MODIFICATION_RESPONSE_TYPE,
|
|
|
|
OGS_PFCP_CAUSE_SESSION_CONTEXT_NOT_FOUND, 0);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_PDR; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
created_pdr[i] = ogs_pfcp_handle_create_pdr(&sess->pfcp,
|
2023-04-15 09:54:03 +00:00
|
|
|
&req->create_pdr[i], NULL, &cause_value, &offending_ie_value);
|
2020-04-26 19:36:05 +00:00
|
|
|
if (created_pdr[i] == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
num_of_created_pdr = i;
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_PDR; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_update_pdr(&sess->pfcp, &req->update_pdr[i],
|
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_PDR; i++) {
|
|
|
|
if (ogs_pfcp_handle_remove_pdr(&sess->pfcp, &req->remove_pdr[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == false)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_FAR; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_create_far(&sess->pfcp, &req->create_far[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2020-06-17 05:22:28 +00:00
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_FAR; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_update_far_flags(&sess->pfcp, &req->update_far[i],
|
2020-06-17 05:22:28 +00:00
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2020-08-13 00:31:22 +00:00
|
|
|
/* Send End Marker to gNB */
|
|
|
|
ogs_list_for_each(&sess->pfcp.pdr_list, pdr) {
|
2022-04-30 01:23:12 +00:00
|
|
|
if (pdr->src_if == OGS_PFCP_INTERFACE_CORE) { /* Downlink */
|
|
|
|
far = pdr->far;
|
|
|
|
if (far && far->smreq_flags.send_end_marker_packets)
|
|
|
|
ogs_assert(OGS_ERROR != ogs_pfcp_send_end_marker(pdr));
|
|
|
|
}
|
2020-08-13 00:31:22 +00:00
|
|
|
}
|
|
|
|
/* Clear PFCPSMReq-Flags */
|
|
|
|
ogs_list_for_each(&sess->pfcp.far_list, far)
|
|
|
|
far->smreq_flags.value = 0;
|
|
|
|
|
2020-06-17 05:22:28 +00:00
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_FAR; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_update_far(&sess->pfcp, &req->update_far[i],
|
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_FAR; i++) {
|
|
|
|
if (ogs_pfcp_handle_remove_far(&sess->pfcp, &req->remove_far[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == false)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2022-04-08 14:10:42 +00:00
|
|
|
upf_n4_handle_create_urr(sess, &req->create_urr[0], &cause_value, &offending_ie_value);
|
2021-10-04 13:28:32 +00:00
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_URR; i++) {
|
|
|
|
if (ogs_pfcp_handle_update_urr(&sess->pfcp, &req->update_urr[i],
|
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_URR; i++) {
|
|
|
|
if (ogs_pfcp_handle_remove_urr(&sess->pfcp, &req->remove_urr[i],
|
|
|
|
&cause_value, &offending_ie_value) == false)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_QER; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_create_qer(&sess->pfcp, &req->create_qer[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
2023-04-11 08:28:33 +00:00
|
|
|
upf_metrics_inst_by_dnn_add(sess->apn_dnn,
|
2022-08-19 12:08:27 +00:00
|
|
|
UPF_METR_GAUGE_UPF_QOSFLOWS, 1);
|
2020-04-26 19:36:05 +00:00
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_QER; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_update_qer(&sess->pfcp, &req->update_qer[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2020-06-17 05:22:28 +00:00
|
|
|
for (i = 0; i < OGS_MAX_NUM_OF_QER; i++) {
|
2020-08-13 00:31:22 +00:00
|
|
|
if (ogs_pfcp_handle_remove_qer(&sess->pfcp, &req->remove_qer[i],
|
2020-04-26 19:36:05 +00:00
|
|
|
&cause_value, &offending_ie_value) == false)
|
|
|
|
break;
|
2023-04-11 08:28:33 +00:00
|
|
|
upf_metrics_inst_by_dnn_add(sess->apn_dnn,
|
2022-08-19 12:08:27 +00:00
|
|
|
UPF_METR_GAUGE_UPF_QOSFLOWS, -1);
|
2020-04-26 19:36:05 +00:00
|
|
|
}
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2020-12-03 06:16:57 +00:00
|
|
|
ogs_pfcp_handle_create_bar(&sess->pfcp, &req->create_bar,
|
|
|
|
&cause_value, &offending_ie_value);
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
ogs_pfcp_handle_remove_bar(&sess->pfcp, &req->remove_bar,
|
|
|
|
&cause_value, &offending_ie_value);
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED)
|
|
|
|
goto cleanup;
|
|
|
|
|
2020-08-13 00:31:22 +00:00
|
|
|
/* Setup GTP Node */
|
2021-03-15 01:01:55 +00:00
|
|
|
ogs_list_for_each(&sess->pfcp.far_list, far) {
|
2023-05-14 01:19:37 +00:00
|
|
|
if (OGS_ERROR == ogs_pfcp_setup_far_gtpu_node(far)) {
|
|
|
|
ogs_fatal("CHECK CONFIGURATION: upf.gtpu");
|
|
|
|
ogs_fatal("ogs_pfcp_setup_far_gtpu_node() failed");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2021-03-15 01:01:55 +00:00
|
|
|
if (far->gnode)
|
|
|
|
ogs_pfcp_far_f_teid_hash_set(far);
|
|
|
|
}
|
2020-08-13 00:31:22 +00:00
|
|
|
|
2020-07-20 01:42:58 +00:00
|
|
|
for (i = 0; i < num_of_created_pdr; i++) {
|
|
|
|
pdr = created_pdr[i];
|
|
|
|
ogs_assert(pdr);
|
|
|
|
|
2023-04-15 09:54:03 +00:00
|
|
|
/* Setup UPF-N3-TEID & QFI Hash */
|
|
|
|
if (pdr->f_teid_len)
|
|
|
|
ogs_pfcp_object_teid_hash_set(OGS_PFCP_OBJ_SESS_TYPE, pdr, false);
|
2020-07-20 01:42:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Send Buffered Packet to gNB/SGW */
|
|
|
|
ogs_list_for_each(&sess->pfcp.pdr_list, pdr) {
|
|
|
|
if (pdr->src_if == OGS_PFCP_INTERFACE_CORE) { /* Downlink */
|
2020-08-13 00:31:22 +00:00
|
|
|
ogs_pfcp_send_buffered_packet(pdr);
|
2020-07-20 01:42:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-04-15 09:54:03 +00:00
|
|
|
if (ogs_pfcp_self()->up_function_features.ftup == 0)
|
|
|
|
ogs_assert(OGS_OK ==
|
|
|
|
upf_pfcp_send_session_modification_response(
|
|
|
|
xact, sess, NULL, 0));
|
|
|
|
else
|
|
|
|
ogs_assert(OGS_OK ==
|
|
|
|
upf_pfcp_send_session_modification_response(
|
|
|
|
xact, sess, created_pdr, num_of_created_pdr));
|
2020-04-26 19:36:05 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
ogs_pfcp_sess_clear(&sess->pfcp);
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_send_error_message(
|
|
|
|
xact, sess ? sess->smf_n4_f_seid.seid : message->h.seid,
|
2020-04-26 19:36:05 +00:00
|
|
|
OGS_PFCP_SESSION_MODIFICATION_RESPONSE_TYPE,
|
|
|
|
cause_value, offending_ie_value);
|
|
|
|
}
|
|
|
|
|
|
|
|
void upf_n4_handle_session_deletion_request(
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
upf_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message)
|
2020-04-26 19:36:05 +00:00
|
|
|
{
|
2022-08-19 12:08:27 +00:00
|
|
|
ogs_pfcp_qer_t *qer = NULL;
|
|
|
|
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_session_deletion_request_t *req = NULL;
|
|
|
|
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_assert(xact);
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_assert(message);
|
|
|
|
req = &message->pfcp_session_deletion_request;
|
2020-04-26 19:36:05 +00:00
|
|
|
ogs_assert(req);
|
|
|
|
|
2020-07-09 05:38:09 +00:00
|
|
|
ogs_debug("Session Deletion Request");
|
2020-04-26 19:36:05 +00:00
|
|
|
|
|
|
|
if (!sess) {
|
2020-08-13 00:31:22 +00:00
|
|
|
ogs_error("No Context");
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_send_error_message(xact,
|
|
|
|
sess ? sess->smf_n4_f_seid.seid : message->h.seid,
|
2020-07-04 03:14:48 +00:00
|
|
|
OGS_PFCP_SESSION_DELETION_RESPONSE_TYPE,
|
2020-04-26 19:36:05 +00:00
|
|
|
OGS_PFCP_CAUSE_SESSION_CONTEXT_NOT_FOUND, 0);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
upf_pfcp_send_session_deletion_response(xact, sess);
|
2022-08-19 12:08:27 +00:00
|
|
|
|
2023-08-08 13:32:06 +00:00
|
|
|
ogs_list_for_each(&sess->pfcp.qer_list, qer) {
|
|
|
|
upf_metrics_inst_by_dnn_add(sess->apn_dnn,
|
|
|
|
UPF_METR_GAUGE_UPF_QOSFLOWS, -1);
|
2022-08-19 12:08:27 +00:00
|
|
|
}
|
2020-04-26 19:36:05 +00:00
|
|
|
upf_sess_remove(sess);
|
|
|
|
}
|
2021-01-18 16:48:35 +00:00
|
|
|
|
|
|
|
void upf_n4_handle_session_report_response(
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
upf_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message)
|
2021-01-18 16:48:35 +00:00
|
|
|
{
|
|
|
|
uint8_t cause_value = 0;
|
|
|
|
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_pfcp_session_report_response_t *rsp = NULL;
|
|
|
|
|
2021-01-18 16:48:35 +00:00
|
|
|
ogs_assert(xact);
|
[PFCP/GTP] Incorrect TEI/SEID=0 (#3043)
If eg. PCRF or AAA diameter link is not yet ready (eg. PCRF crashed),
and a client sends a CreateSessionRequest announcing its ow F-TEID,
then open5gs-smfd answers with Create Session Response Cause="Remote peer not responding",
but it is not setting the received F-TEID in the header of the response,
instead it sends with TEID=0.
As a result, the peer cannot match the CreateSessionResponse,
and needs to rely on its own timeout timer to figure out
that specific request failed.
See 3GPP TS 29.274 5.5 Usage of the GTPv2-C Header:
```
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
```
This happens with Delete Session Requests and can happen with any PFCP message.
I've fixed TEID/SEID to send the value in the reponse message as is if it was received.
2024-04-05 12:36:30 +00:00
|
|
|
ogs_assert(message);
|
|
|
|
rsp = &message->pfcp_session_report_response;
|
2021-01-18 16:48:35 +00:00
|
|
|
ogs_assert(rsp);
|
|
|
|
|
|
|
|
ogs_pfcp_xact_commit(xact);
|
|
|
|
|
2022-03-15 04:34:32 +00:00
|
|
|
ogs_debug("Session Report Response");
|
2021-01-18 16:48:35 +00:00
|
|
|
|
|
|
|
cause_value = OGS_PFCP_CAUSE_REQUEST_ACCEPTED;
|
|
|
|
|
|
|
|
if (!sess) {
|
|
|
|
ogs_warn("No Context");
|
|
|
|
cause_value = OGS_PFCP_CAUSE_SESSION_CONTEXT_NOT_FOUND;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rsp->cause.presence) {
|
|
|
|
if (rsp->cause.u8 != OGS_PFCP_CAUSE_REQUEST_ACCEPTED) {
|
|
|
|
ogs_error("PFCP Cause[%d] : Not Accepted", rsp->cause.u8);
|
|
|
|
cause_value = rsp->cause.u8;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ogs_error("No Cause");
|
|
|
|
cause_value = OGS_PFCP_CAUSE_MANDATORY_IE_MISSING;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cause_value != OGS_PFCP_CAUSE_REQUEST_ACCEPTED) {
|
|
|
|
ogs_error("Cause request not accepted[%d]", cause_value);
|
|
|
|
return;
|
2022-08-19 12:08:27 +00:00
|
|
|
} else {
|
|
|
|
upf_metrics_inst_global_inc(UPF_METR_GLOB_CTR_SM_N4SESSIONREPORTSUCC);
|
2021-01-18 16:48:35 +00:00
|
|
|
}
|
2022-08-19 12:08:27 +00:00
|
|
|
|
2021-01-18 16:48:35 +00:00
|
|
|
}
|