2019-04-27 14:54:30 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2019 by Sukchan Lee <acetcom@gmail.com>
|
|
|
|
*
|
|
|
|
* 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/>.
|
|
|
|
*/
|
|
|
|
|
2020-08-13 00:31:22 +00:00
|
|
|
#ifndef SGWU_SXA_HANDLER_H
|
|
|
|
#define SGWU_SXA_HANDLER_H
|
|
|
|
|
|
|
|
#include "context.h"
|
2019-04-27 14:54:30 +00:00
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2020-08-13 00:31:22 +00:00
|
|
|
void sgwu_sxa_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
|
|
|
sgwu_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message);
|
2020-08-13 00:31:22 +00:00
|
|
|
void sgwu_sxa_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
|
|
|
sgwu_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message);
|
2020-08-13 00:31:22 +00:00
|
|
|
void sgwu_sxa_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
|
|
|
sgwu_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message);
|
2020-08-13 00:31:22 +00:00
|
|
|
|
|
|
|
void sgwu_sxa_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
|
|
|
sgwu_sess_t *sess, ogs_pfcp_xact_t *xact, ogs_pfcp_message_t *message);
|
2019-04-27 14:54:30 +00:00
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2020-08-13 00:31:22 +00:00
|
|
|
#endif /* SGWU_SXA_HANDLER_H */
|