Fixed an issue in SCP TLS communication for Open5GS where omitted port numbers
in HTTP/HTTPS URIs (e.g., "https://scp.localdomain" implying port 443) were not
handled correctly.
Updated the code to ensure that during FQDN and port comparisons,
cases where the port number is set to 0 are accounted for.
This fix resolves the problem with indirect SBI communication over SCP using TLS
allowing proper connectivity between network functions like BSF and NRF.
The clang scan-build procedure
```
Assume Ubuntu docker container with open5gs mounted to /src.
Assume these tools are installed to docker container:
sudo apt install -y clang-tools clang
For easy reference to clang scan-build tool:
Put normal open5gs build procedure into a file called /src/build
=======================
Inside docker container:
=======================
export CLANG_OUT_DIR=/src/scan_build_results
scan-build -disable-checker deadcode.DeadStores --override-compiler --keep-going
--exclude subprojects --exclude tests --exclude lib/asn1c -maxloop 200 -o $CLANG_OUT_DIR -plist-html /src/build 2>&1 | tee /src/logclang.txt
=======================
Results:
=======================
Results are in html format in $CLANG_OUT_DIR - top level index.html
```
Note that in this analysis the following suppressions were assumed:
- no deadcode.DeadStores analysis since those are not functional findings
- exclude lib/asn1c for reason that is outside of open5gs control
- exclude tests for reason that those are not functional findings
- exclude subprojects since those are outside of open5gs control
- create SDM subscription to UDM when PDU session is created, just
before sending SMF registration to UDM
- delete SDM subscription when PDU session is released
- handle SDM Change Notification, but not yet process items in it
NF should accept 204 No Content for Update Subscription requests.
According to 3GPP 29.510 NRF specification document in figure 5.2.2.5.6.1
NRF may return 204 or 200 for success update operations.
2a. On success, if the NRF accepts the extension of the lifetime
of the subscription, and it accepts the requested value for the "validityTime"
attribute, a response with status code "204 No Content" shall be returned.
2b. On success, if the NRF accepts the extension of the lifetime
of the subscription, but it assigns a validity time different than
the value suggested by the NF Service Consumer, a "200 OK" response code shall
be returned. The response shall contain the new resource representation
of the "subscription" resource, which includes the new validity time,
as determined by the NRF, after which the subscription becomes invalid.
I changed it so that all NFs can receive both 200 and 204 STATUS.
I also changed the default behavior of NRFs to respond with 204,
which is NO CONTEXT.
I created ogs_sbi_xact_find_by_id() with a hash
to replace ogs_sbi_xact_cycle().
Modified to find the xact via xact->id
when making an HTTP request with the SBI client function
and waiting for the HTTP response.
The validity time for NF Instances obtained through NF Discovery was
not properly implemented. Since the validity was 3600 seconds(1 hour),
which caused 5G Core to not work properly after 3600 seconds(1 hour).
There was an issue where an NF Instance should be deleted
when its validity time expired, but it was not working correctly
due to incorrect use of reference count.
Therefore, I have modified the Validity of NF Instances obtained
through NF Discovery to work properly.
I also changed the default value of valdityPeriod to 30 seconds.
Fixed not using Reference Count for adding/deleting NF Instances.
Up until now, NF Instances have been managed by referencing the Reference Count.
Initially, when an NF Instance is added, the Reference Count is incremented and
when it is deleted, the Reference Count is decremented.
If a UE discovers another NF Instance through the NF Discovery function,
the Reference Count is incremented. And if a UE de-registers,
the Reference Count of the discovered NF is decremented.
However, there's a problem with this approach.
When other NF is de-registered,
there is no guarantee that it will be 100% notified.
For example, if a UDM is de-registered, but an SCP is de-registered before it,
the AMF will not be notified that the UDM has been de-registered.
In situations where this is not clear, Reference Count cannot be used.
Therefore, we have modified it to not use the Reference Count method.
Also, when a UE connects, it is modified to always search
whether an NF Instance exists by NF Instance ID whenever it is discovered.
To do this, we modified lib/sbi/path.c as shown below.
```diff
@@ -281,13 +281,15 @@ int ogs_sbi_discover_and_send(ogs_sbi_xact_t *xact)
}
/* Target NF-Instance */
- nf_instance = sbi_object->service_type_array[service_type].nf_instance;
+ nf_instance = ogs_sbi_nf_instance_find(
+ sbi_object->service_type_array[service_type].nf_instance_id);
if (!nf_instance) {
nf_instance = ogs_sbi_nf_instance_find_by_discovery_param(
target_nf_type, requester_nf_type, discovery_option);
- if (nf_instance)
- OGS_SBI_SETUP_NF_INSTANCE(
- sbi_object->service_type_array[service_type], nf_instance);
+ if (nf_instance) {
+ OGS_SBI_SETUP_NF_INSTANCE_ID(
+ sbi_object->service_type_array[service_type], nf_instance->id);
+ }
}
```
A friend in the community was trying to connect an SMF made by another
manufacturer with an SBI interface and found a big problem with Open5GS.
All of the code in the part that generates the Resource URI
from HTTP.location is invalid.
For example, suppose we create a Resource URI with SMContext as below.
{apiRoot}/nsmf-pdusession/<apiVersion>/sm-contexts/{smContextRef}
In this case, Open5GS extracted the {smContextRef} part of the HTTP.location
and appended it to the beginning
{apiRoot}/nsmf-pdusession/<apiVersion>/sm-contexts/.
This implementation may not work properly if the apiRoot changes.
Consider a different port number as shown below.
<HTTP.location>
127.0.0.4:9999/nsmf-pdusession/v1/sm-contexts/1
The SMF may send an apiRoot to the AMF with a changed port number,
in which case the AMF must honor it.
Therefore, instead of extracting only the smContextRef from HTTP.location,
we modified it to use the whole thing to create a Resource URI.
We modified all NFs that use HTTP.location in the same way, not just SMFs.
Cause is set according to particular NF standard.
Additionally:
- OGS_SBI_HTTP_STATUS_MEHTOD_NOT_ALLOWED typo fixed.
- [PCF] Fixed SM Policy establishment error handling
* [SBI] Handle and store AMF info
* [SBI] Add "target GUAMI" discovery option
* [SBI] Handle UeContextTransfer request and response messages
* [AMF] Handle NF discovery from AMF to AMF
* [AMF] Add UE Context Transfer Request/Response from AMF to AMF
* [SCP] Handle UeContextTransfer
* Follow-up on #3052
* [AMF] force authentication after 'Ue context transfer' for now
* [AMF] force authentication after 'Ue context transfer' for now
---------
Co-authored-by: Sukchan Lee <acetcom@gmail.com>
When building the MIME Multipart Media Encapsulation format
within an SBI message in the NF of a third-party product,
Open5GS does not parse properly if it contains a Preamble CRLF.
For example,
```
TCP/HTTP2
Stream: Data, Stream ID: 1, Length 841
MIME Multipart Media Encapsulation, Type: multipart/related, Boundary: "gc0pJq08jU534c"
--->Preamble: 0d0a
First boundary: --gc0pJq08jU534c\r\n
Encapsulated multipart part: (application/json)
Boundary: \r\n--gc0pJq08jU534c\r\n
Encapsulated multipart part: (application/vnd.3gpp.5gnas)
Boundary: \r\n--gc0pJq08jU534c\r\n
Encapsulated multipart part: (application/vnd.3gpp.ngap)
Last Boundary: \r\n--gc0pJq08jU534c--\r\n
```
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>
The UPF is sending Session Report Request after the Session was Deleted,
when the Gy interface is active.
UPF is sending PFCP session report request after the session has been deleted
when the Gy interface is active. This is because some of the timers related to
the report are not deleted when the session is deleted.
We have fixed it to delete all the timers in the session
when the SESSION is deleted.
When the input string contains a number and a unit too large to be
represented by a 64-bit variable, AMF/SMF would crash due to conversion
resulting in a negative value and unable to be used in compiling NAS-PDU
container.
Now the value gets clipped at int64_t maximum value.
Failed to encode ASN-PDU [-1] (../lib/asn1c/util/message.c:42)
../lib/core/ogs-list.h:62:24: warning: invalid conversion from 'void*' to 'ogs_list_t*' {aka 'ogs_list_s*'} [-fpermissive]
../lib/core/ogs-rbtree.h:79:32: warning: invalid conversion from 'const void*' to 'const ogs_rbnode_t*' {aka 'const ogs_rbnode_s*'} [-fpermissive]
[SBI] Fix compiler error - possible uninitialized variable
[SCP] Fix compiler error - Error: this condition has identical branches
In case of additional compiler warnings turned on, the compiler warns
about potentially unused variables. Fix those issues.
According to 3GPP TS 29.510, the search parameter "tai" should be a
single item, not an array of items.
TS 29.510: Table 6.2.3.2.3.1-1:
URI query parameters supported by the GET method on this resource
Revert "[SBI] Change discovery option TAI from array to single item"
This reverts commit b4beff1ae16c64b3c6d84d8bdb47c36e19b705f2.
wip
This problem can be occurred in the following scenarios.
1. Run NFs(NRF/SCP/SMF/UPF/AUSF/UDM/PCF/BSF/NSSF/UDR) except AMF.
2. Run AMF
3. Run gNB/UE and try to register
4. STOP PCF
5. AMF Crashed
AMF discovered the PCF through SCP during the UE registration process.
At this time, ogs_sbi_nf_fsm_init() is not called,
so AMF does not have state information about PCF.
In other words, AMF state is NULL.
In such a situation, when PCF is terminated at this time,
a crash occurs as AMF attempts to change the PCF state.
So, I've fixed that state information is initialized to solve this problem.
* [SBI] Ignore unknown enum values and continue parsing (#2622)
* [SBI] Reject empty enum lists (#2622)
Enum lists that are empty due to ignoring
unsupported enum values are also rejected.
* Revert changing `generator.sh`
Depending on the OpenAPI yaml files, fields can be marked as "nullable".
Which means that the field can be either present, not present, or null.
This feature is important for example in SmContextUpdateData structure,
where many fields are described similar as the following:
This IE shall be included for the modification .... For deleting the
field, it shall contain the Null value.
j
The crash is caused by ogs_assert(data) in listEntry_create(void *data).
Reason for the failing assertion is that in
OpenAPI_subscription_data_t *OpenAPI_subscription_data_parseFromJSON(
cJSON *subscription_dataJSON)
in line 501 of file subscription_data.c the event string is transformed
into an integer/enum value, which in case of an unknown event is 0.
Steps to reproduce:
1. Deploy NRF
2. Run curl --http2-prior-knowledge --header "Content-Type: application/json" --data '{"nfStatusNotificationUri": "test@example.com", "reqNotifEvents": ["unknown"], "subscriptionId": "12345"}' "http://<NRF_IP>:<NRF_PORT>/nnrf-nfm/v1/subscriptions"
Whether or not to send a Setting ACK is determined by the nghttp2 library.
Therefore, when nghttp2 informs us that it want to send an SETTING frame
with ACK by nghttp2_session_want_write(), we need to call session_send()
directly to send it.
From the OpenAPI document,TS29571_CommonData.yaml : BitRate
String representing a bit rate; the prefixes follow the standard symbols from The International
System of Units, and represent x1000 multipliers, with the exception that prefix "K" is
used to represent the standard symbol "k".
POST requests to {apiRoot}/nnrf-nfm/v1/subscriptions return
a HTTP Location header in 201 respose
in the form {apiRoot}/nnrf-nfm/v1/subscriptions/{subscriptionID}
