Free memory including the "base pointer". Fix two places in which it was
on the stack to harmonize. The only stack variable is in reception of
new E1 messages (e1ap_handle_message()), which uses
ASN_STRUCT_FREE_CONTENTS_ONLY().
This fixes bugs similar to these logs:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f418f4e68a3 in calloc (/lib64/libasan.so.8+0xe68a3) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
#1 0x00000049e367 in calloc_or_fail /home/richie/oai/common/utils/utils.h:74
#2 0x00000049e367 in encode_e1_bearer_context_release_command /home/richie/oai/openair2/E1AP/lib/e1ap_bearer_context_management.c:1235
#3 0x000000482951 in e1apCUCP_send_BEARER_CONTEXT_RELEASE_COMMAND /home/richie/oai/openair2/E1AP/e1ap.c:546
#4 0x000000482951 in E1AP_CUCP_task /home/richie/oai/openair2/E1AP/e1ap.c:856
#5 0x7f418f428ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f418f4e68a3 in calloc (/lib64/libasan.so.8+0xe68a3) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
#1 0x00000049380a in calloc_or_fail /home/richie/oai/common/utils/utils.h:74
#2 0x00000049380a in encode_E1_bearer_context_setup_request /home/richie/oai/openair2/E1AP/lib/e1ap_bearer_context_management.c:578
#3 0x00000047f6a2 in e1apCUCP_send_BEARER_CONTEXT_SETUP_REQUEST /home/richie/oai/openair2/E1AP/e1ap.c:378
#4 0x0000004829f8 in E1AP_CUCP_task /home/richie/oai/openair2/E1AP/e1ap.c:846
#5 0x7f418f428ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f418f4e68a3 in calloc (/lib64/libasan.so.8+0xe68a3) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
#1 0x00000046ede7 in calloc_or_fail /home/richie/oai/common/utils/utils.h:74
#2 0x00000046ede7 in encode_e1ap_cuup_setup_response /home/richie/oai/openair2/E1AP/lib/e1ap_interface_management.c:305
#3 0x00000047e412 in e1ap_send_SETUP_RESPONSE /home/richie/oai/openair2/E1AP/e1ap.c:167
#4 0x000000482a68 in E1AP_CUCP_task /home/richie/oai/openair2/E1AP/e1ap.c:836
#5 0x7f418f428ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 10b8ccd49f75c21babf1d7abe51bb63589d8471f)
Add enc/dec library and unit test for E1 Bearer Context Modification Failure
This MR is adding:
- the enc/dec library
- unit test
- handler and callback in stack
For the E1 Bearer Context Modification Failure.
This commit does not introduce the callback on the CU-UP to trigger
a Bearer Context Setup Failure when the setup of the bearer context was unsuccessful.
This should be handled properly in the stack e.g. in e1_bearer_context_setup (a comment
in the code says "We assume all DRBs to setup have been setup successfully, so we always
send successful outcome in response and no failed DRBs")
E1AP enc/dec lib improvements
This MR is including some fixes and improvements for the E1AP library,
focusing mostly on Bearer Context Management:
- struct reorganization: split setup and modification request messages
into distinct structures, ensuring compliance with 3GPP TS 38.463
specifications
- add encoding/decoding sub-functions for different IEs
- improvements to Bearer Context Management: Implemented various
improvements to the E1 Bearer Context Setup Response and Request,
including the adoption of encoding/decoding sub-functions for
different IEs
- use lib functions whenever need (e.g. cp_bearer_context_setup_request
in cucp_cuup_e1ap.c)
- handle optional struct members as pointers
- updated copy/equality check utility functions
EDIT: The MR is also including the changes from !3222 (closed):
> While testing E1 with security enabled for DRBs, it was found that
> data traffic was not functional.
>
> The problem was that security settings were modified in the PDCP
> reestablishment happening when receiving Bearer Context Modification
> Request.
>
> So some restructuring was done.
>
> The actual fix is in 18176297, the others are for support. Basically
> we introduce a boolean to check if the security settings are present in
> Bearer Context Modification Request and we change PDCP security settings
> only if they are.
>
> (Note that in OAI CU security settings are not sent in Bearer Context
> Modification Request, so we could also remove all this, but we need to
> be compatible with other cu-up and/or cu-cp.)
Check if the IE is memory allocated to deal with presence/absence of this information
element in Bearer Context Modification Request and add encoding/decoding
in the code.
Note that for decoding the integrity settings may be absent, in which
case we consider NIA0 to be used (no integrity protection). To be refined
if needed.
And for encoding, we always encode integrity settings, even if it's NIA0.
May also be refined if needed.
Bearer context setup request and modification request messages
differ in various IEs according to 9.2.2 of 3GPP TS 38.463, e.g.
the Bearer context setup request does not contain a list of
DRBs to modify and does not contain an UP TL configuration.
Thus, the goal of this commit is to split the setup request message
and the modification request into two different structs:
* adopt e1ap_bearer_mod_req_t where necessary (e.g. fill_e1_bearer_modif)
Also, reorganized existing struct members according to specs:
* remove irrelevant struct members from the setup request
* group members from the same IEs into structs
* set optional struct members IEs as pointers
* add and adopt enc/dec/cp/eq lib functions for single IEs
* add UP_TL_information_t struct with TEID and TL address info and adopt in stack
* use int instead of long for count types
* update the relevant copy/equality check utility functions
Extra:
* add a function to handle Security Information in RRC in the process
* add create_up_tl_info and adopt in unit tests
38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes like
> a Reset procedure would do.
Hence, delete all contexts after reception of E1 Setup Response. This
minimizes a risk of receiving an E1 bearer setup req for an existing UE,
which currently leads to an assert [we trust the CU-CP does not send the
same UE ID twice, as we only "mirror" the existing UE ID].
E1 Setup enc/dec library and unit test
This MR is adding a library for E1 Setup enc/dec functions:
- E1 CU-UP Setup Request
- E1 CU-UP Setup Response
- E1 Setup Failure
and relevant unit tests
* this function is used by both CU-CP and CU-UP
* it behaves differently depending on the type of E1 instance:
CU-CP: inform RRC of E1 connection loss with CU-UP
CU-UP: trigger a new SCTP association request by sending an ITTI to the CU-UP task
* after receiving the E1AP register request, the CU-UP will send a new association request to
SCTP until new E1 connection is achieved by sending a TIMER_HAS_EXPIRED message to the CU-UP
task. The function e1apHandleTimer() is basically triggering a new E1 association request
until new E1 connection is achieved
* print SCTP association state in e1ap.c whenever needed
Related to #878
Rewrite sctp_create_new_listener() to use getaddrinfo() to look up
IPv4/IPv6 addresses via a common interface. This allows to use e.g. DNS,
and enables the SCTP library to listen on IPv6 ports.
To support the above, the corresponding message is changed to not take
an IPv4 address on 4 bytes (and separate IPv6), but a single name that
will be resolved via getaddrinfo()
The previous init message used to allow multiple IPv4/IPv6 addresses;
since this is not used anywhere, remove the corresponding functionality.
Modify all uses of this ITTI message to copy te SCTP init bind addr into
ITTI message.
- PDCP reestablishment on CUCP (DRBs) triggering Bearer Context Modification procedures over E1
- Performing PDCP reestablishment for requested DRBs on CUUP
- Introduced function to notify re-establishment to CU-UP
- removed call to PDCP reestablishment for the DRBs on CUCP (it's done on CUUP)
cuup_notify_reestablishment:
- to fetch PDU session to setup in E1 following logic as in e1_send_bearer_updates
- fill bearer context modification request with stored F1-U tunnel information
during E1 reestablishment, otherwise it would initialized to 0 by default
- update GTP tunnel with the stored configuration after E1 reestablishment
- many structs and definitions are overlapping between the two different E1 procedures
- introduced naming specific to E1 Bearer Context Modification to improve readability
- grouped SDAP and PDCP configuration IEs for better reusability and readability
- introduced functions to set and get default PDCP config (DRBs and Bearer Contexts)
find_or_next_pdu_session:
- find_or_next_pdu_session refers to the E1 Bearer Context Modification Request
-- therefore it has to return pdu_session_to_mod_t* and takes in input e1ap_bearer_mod_req_t *
see !MR2545 for more context
- CU-CP replying to the CU-UP with a Setup Failure message in case of unsuccessfull E1 Setup Request
- message is decoded by the CU-UP, and stops the process
- Implement: Extend the F1 encoding and decoding with Qos
- Implement: E1 decoding for QoS
- Fix: Modify the UE_MODIFICATION_REQUEST_MSG towards DU to contain QoS info based on E1AP context response
- Fix: Modify the E1AP and F1AP message structures
- Fill the Qos configuration to send to MAC
3GPP has the concept of a gNB-CU-UP ID and a (separate) gNB ID (for gNB,
CU-CP). This commit introduces the gNB-CU-UP as a separate ID that has to be
set in the configuration file when running as a CU-UP. For the
CU/monolithic gNB, it is optional (but needs to be the same as the
gNB-ID if specified).
The CU-UP ID is necessary, as some entities, e.g., the e2 agent, need to
signal both IDs, e.g., to reconcile a CU-CP and (multiple) CU-UP(s)
belonging together.
Robert Schmidt