Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GTP] Incorrect destination TEID=0 (#3043) #3114

Merged
merged 1 commit into from
Apr 6, 2024
Merged

[GTP] Incorrect destination TEID=0 (#3043) #3114

merged 1 commit into from
Apr 6, 2024

Conversation

acetcom
Copy link
Member

@acetcom acetcom commented Apr 6, 2024

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 TEI=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.

To address this issue, I modified the GTP Response message to check the Sender F-TEID and send it accordingly, setting the destination TEID to the value of the Sender F-TEID.

I've made this modification only for SMF, but MME and SGW-C have not done so; if you need to, you can work from the examples in SMF.

Similarly, the same situation can happen with PFCP. If anyone needs to do this in the future, I think you can work on it this way.

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 TEI=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.

To address this issue, I modified the GTP Response message to check
the Sender F-TEID and send it accordingly, setting the destination TEID
to the value of the Sender F-TEID.

I've made this modification only for SMF, but MME and SGW-C have not done so;
if you need to, you can work from the examples in SMF.

Similarly, the same situation can happen with PFCP. If anyone needs to do this
in the future, I think you can work on it this way.
@acetcom acetcom merged commit 8484a5a into main Apr 6, 2024
6 checks passed
@acetcom acetcom deleted the i3043 branch April 6, 2024 07:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant