UDM may send a Deregistration Notification to AMF, to deregister
specific UE from the network - Network-Initiated Deregistration.
Deregistration procedure includes sending Deregistration Request to UE,
starting a timer T3522, releasing PDU sessions from SMF, releasing PCF
policies from PCF, and waiting for Deregistration Accept from UE.
Not yet implemented is:
- to prevent deregistration of UE in case it has any emergency sessions,
- page UE when UE is in IDLE mode.
According to TS 23.502, 4.2.2.2.2, AMF sends Registration event to UDM
in the following cases:
- If the AMF has changed since the last Registration procedure, or
- if the UE provides a SUPI which doesn't refer to a valid context in
the AMF,
- or if the UE registers to the same AMF it has already registered
to a non- 3GPP access (i.e. the UE is registered over a non-3GPP access
and initiates this Registration procedure to add a 3GPP access).
In case that UE re-registers to the network with a GUTI, it bypasses
authentication check to the AUSF. In this case, AMF does not send
Registration event to UDM.
Consequently, when UE deregisters again, AMF would send a Deregistration
Event to a UDM, which does not have a context for it.
3GPP standard does not say when AMF sends Deregistration Event to UDM,
only that it is optional.
These (De-)Registration events are for (de-)registering AMF to the UDM
for serving the UE. And not for (de-)registering UE itself for purpose
of tracking when UE is registered on the network.
This partially reverts commit 7be7029ac4
Don't attempt to restart systemd-networkd if systemd is not running
(e.g. installing open5gs inside a chroot).
Fix for:
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
dpkg: error processing package open5gs-upf:amd64 (--configure):
installed open5gs-upf:amd64 package post-installation script subprocess returned error exit status 1
Static code analysis can be executed with following commands:
meson build
ninja -C build analyze-cppcheck
ninja -C build analyze-clang-tidy
These commands are available only if additional tools are installed:
- cppcheck
- clang-tidy
- clang-tools is optional if you want to paralelize the clang-tidy
In case of cppcheck analysis, a file called build/cppchecklog.log is
created with the analysis results.
In case of clang-tidy analysis, some checks are disabled. See file
.clang-tidy, and reenable them if you see fit.
Also it does not scan all the files in the project, since some of them
are imported from other sources. It does not scan any sources under:
- subprojects/
- lib/asn1c/
- lib/ipfw/
3GPP TS 29.244 7.2.2.4.2 documents that the peer will set SEID=0 in the
response when we request something for a session not existing at the peer.
If that's the case, we still want to locate the local session which
originated the request, so let's store the local SEID in the xact when
submitting the message, so that we can retrieve the related SEID and
find the session if we receive SEID=0.
It was spotted that if DeleteSessionReq sent by SMF is answered by UPF
with cause="Session context not found", then it contains SEID=0 (this is
correct as per specs). Hence, since SEID=0 session is not looked up, so
sess=NULL.
A follow up commit improves the situation by looking up the SEID in the
originating request message in that case.
In that case, ogs_pfcp_ue_ip_alloc() will fail with the error message
"CHECK CONFIGURATION: Cannot find subnet [...]" and the assert will make
upf crash.
That's not desirable, let's keep it running and simply reject the
request. The error log is big enoguh to find out.
* [SMF] Avoid abort() if gtp_node mempool becomes full
Related: https://github.com/open5gs/open5gs/issues/1621
* [SMF] metrics: Add new ctr tracking gtp_node allocation failures
This metrics is useful to track whether at some point the mempool went
full, so that config needs to be updated to increase the mempool size.
Gy (3GPP TS 32.299 ) refers to AVP in DCCA (RFC4006).
RFC4006 5.1.2:
"[...] by including the Multiple-Services-Indicator AVP in the first
interrogation."
Nokia's infocenter documentation also states it's sent during Initial CCR
only: "(CCR-I only)".
"build" Docker image previously downloaded latest version of Open5GS
from github, and built the project from that.
Use local source files for building instead.
Valgrind memcheck tool reports an error, of invalid read beyond the
allocated memory.
Function "write_cb()" already allocates (realloc) +1 byte and
null-terminates the data. But the length "conn->size" does not contain
this extra null-terminated byte.
When a copy of the received data is made in "check_multi_info()", it
does not include the null character, resulting in potentially a
non-null terminated string.
Later on when parsing the data, "strlen()" will read beyond the
allocated memory to search for the null character, resulting in an
invalid read.
==1994== Invalid read of size 1
==1994== at 0x484ED24: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1994== by 0x4D3F401: cJSON_ParseWithOpts (cJSON.c:1109)
==1994== by 0x4D3F65C: cJSON_Parse (cJSON.c:1197)
==1994== by 0x4C927DE: parse_json (message.c:913)
==1994== by 0x4C972D8: parse_content (message.c:1790)
==1994== by 0x4C90096: ogs_sbi_parse_response (message.c:589)
==1994== by 0x136431: amf_state_operational (amf-sm.c:248)
...
==1994== Address 0x668371d is 0 bytes after a block of size 253 alloc'd
==1994== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1994== by 0x5107D7F: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.3.3)
==1994== by 0x510814B: _talloc_memdup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.3.3)
==1994== by 0x4871568: ogs_talloc_memdup (ogs-strings.c:184)
==1994== by 0x4CA7755: check_multi_info (client.c:475)
...
Sukchan Lee
Bostjan Meglic
Oliver Smith
Networkmama
Pau Espin
Bostjan Meglic
JagannathS
jmasterfunk84