As of the parent commit, there is a generic "may_fail" option through
which we could still ignore an error. Thus, command_fail is superfluous,
and avoids some extra code.
Further, in all these cases, we should better be informed about any
error, so let's not use may_fail for these tests.
There might be various occasions where a CI step should be attempted to
be executed, despite a chance of failing. For instance, we might want
to try executing an instable Iperf test, and still mark the CI as
passing if it fails.
This commit introduces a generic "may_fail" option that will mark any CI
test as succeeded, despite having failed.
Ideally, we would print a warning in the HTML code, but this is not
possible because each step emits its own HTML code, instead of the main
loop handling this. We can improve this in the future.
SPEC 38.331 section 5.2.2.6
Inform MAC that UL SYNC got lost because of T430 expiry
- Send message NR_MAC_RRC_CONFIG_RESET with cause UL_SYNC_LOST_T430_EXPIRY to MAC
Reacquire SIB19 after T430 expiry
This is not checked in this commit
- RACH needs to be performed through probably PDCCH order to reobtain UL-SYNC
- system usecase involving Recovery from T430 expiry not tested yet as that requires changes on gNB side.
Spec 38.331 section 5.2.2.4.21 indicates this
1> start or restart T430 for serving cell with the timer value set to ntn-UlSyncValidityDuration for the serving cell
from the subframe indicated by epochTime for the serving cell;
NOTE: UE should attempt to re-acquire SIB19 before the end of the duration indicated by ntn-UlSyncValidityDuration and epochTime
Epochtime IE
When explicitly provided through SIB, or through dedicated signaling, the EpochTime is the starting time of a DL
sub-frame, indicated by a SFN and a sub-frame number signaled together with the assistance information.
For serving cell, the field sfn indicates the current SFN or the next upcoming SFN after the frame where the message indicating the epochTime is received.
This field is mandatory present when ntn-Config is provided in dedicated configuration.
gNB implementation related to epochtime will be done in a separate merge request.
Adds the packing and unpacking functions needed for the PM Table in CONFIG.request
This table tag is specified in SCF222.10.06(0x104B), previous versions didn't have a tag for this table, and this version of the spec introduces the parameter `num_pm_idx`, previously not present.
A struct nfapi_nr_pm_tlv_ve_t is added to represent this TLV in order to be able to use the pack_nr_tlv function.
The necessary additions to the utility functions are done to account for this table.
The unitary test is changed to fill this table with randomized data to test transport and copy.
Adds the packing and unpacking functions needed for the DBT Table in CONFIG.request
This table tag is specified in SCF222.5.0 (0x1043) and this tag is used to transport the table, previous versions did not include a tag for the table.
A struct nfapi_nr_dbt_tlv_ve_t is added to represent this TLV in order to be able to use the pack_nr_tlv function.
The necessary additions to the utility functions are done to account for this table.
The unitary test is changed to fill this table with randomized data to test transport and copy.
NR UE fallback to RRCSetup from RRCReestablishment
Implementation of the procedure to handle reception of RRCSetup as response
to RRCReestablishment request
Step 004000 appears double in the XML description. Remove one to avoid
that it is executed twice (because the Python code goes through the list
of test descriptions and executes all that match the current ID =>
double if appears twice).
Corrected a logic bug in usrp_lib.cpp where the code mistakenly checked
openair0_cfg[0].clock_source instead of time_source when a time_source
was already specified in usrp_args.
Also improved the warning log to clarify that the config value is being
ignored in favor of the explicit user-provided usrp_args.
Co-authored-by: Alexandre Serio <alexandre.j.serio@altice.pt>
Integration: `2025.w24`
Closes#965
See merge request oai/openairinterface5g!3476
* !3354 Preparation Work for N2 Handover
* !3383 Add configurable values of NR RLC and NR PDCP to the configuration file
* !3468 Resolve "SSB frequency at gnb.sa.band78.fr1.24PRB.usrpb210.conf is invalid"
* !3466 YAML related updates
* !3460 SRS configuration
* !3474 Fix AMF selection fallback by PLMN ID when no UE identity is present or matching
* !3473 Fix various bugs and inconsistencies in config read, SCTP, ITTI, GTP
* !3169 NR RU improvements for analog beamforming
* !3456 CI: update config for AW2S pipeline
* !3369 Add Security Mode Reject lib/unit test and adopt in stack
* !3457 Fix NR reestablishment
* !3412 [E2 agent] E2AP README update and OAI-FlexRIC CI pipeline improvements
[E2 agent] E2AP README update and OAI-FlexRIC CI pipeline improvements
- E2AP README - add OSC nearRT-RIC section; update with proper FlexRIC
links, and explanations on prerequisites, as well as for xApps
- OAI-FlexRIC CI - use separate containers for xApps
- add reference files for CU-UP/CU-CP
- add logging for KPM NSSAI condition
Fix NR reestablishment by implementing the "DRB-suspend" at the MAC.
This means that the during reestablishment, gNB MAC discards received
DRB packets, and does not schedule DRB. Fix a couple of additional
issues in reestablishment. # Please enter a commit message to explain
why this merge is necessary,
For additional information, see
https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2668#note_119369
The spCellConfig is to be dropped during reestablishment and to be
applied after reconfiguration. Implement this using the
RRCReconfigurationComplete acknowledgment from the CU to the DU,
applying the spCellConfig if present (which signals a prior
reestablishment). Remove a prior flag that is not needed anymore, and
do not "guess" when is the reconfiguration, because it is now handled in
the case of the ack.
The spCellConfig is not relevant as long as we use a common search space
for DCIs (and the activation of dedicated search space happens after
applying spCellConfig). For PUCCH, there is the PDSCH transmission of
RRCReconfiguration which gets ack'ed in the default PUCCH.
RRCReconfigurationComplete is sent in PUSCH (again through common
search space). In theory, there cannot be another PUCCH before the
application of spCellConfig, as all bearers are still suspended, and
there should not be another SRB1 transmission in the meantime, as only
one RRC transaction can be active at a time.
Co-authored-by: francescomani <email@francescomani.it>
Add a flag for each RB that tracks suspension state. Mark all RBs
(except SRB1) as suspended on reestablishment, and de-suspend on
reconfiguration. Only check RLC status for non-suspended RBs. For UL
data traffic, check that DRB/SRB2 exist (SRB1 should be there as soon as
the UE context exists).
Add Security Mode Reject lib/unit test and adopt in stack
This MR is adding the library for the NAS Security Mode Reject, and
relevant unit test.
The UE shall send a SECURITY MODE REJECT containing a 5GMM cause that
typically indicates one of the following cause values: (23) UE security
capabilities mismatch. (24) security mode rejected, unspecified
- The message shall be protected if a security context is available.
- The message is adopted in the handling of Security Mode Command failure.
See 3GPP TS 24.501 5.4.2.5 "NAS security mode command not accepted by
the UE".
This MR includes changes from !3262:
> This patch series addresses a security issue where the UE improperly
> accepts a Security Mode Command (SMC) without an authentication header
> (Security Header 0). This behavior violates TS 24.501 and enables an
> attacker to bypass authentication, set integrity protection to NULL
> (NIA0), and reconfigure the UE without proper verification.
>
> We identified the following issues:
>
> 1. The UE currently accepts unauthenticated SMC messages, even
> allowing NIA0 and EIA0 to be set outside emergency mode.
> 2. When applying NIA0, the MAC field remains uninitialized,
> consistently containing the sequence 0xFF3F0000, making it feasible
> to bypass authentication and enforce insecure configurations.
> 3. The UE does not properly signal security mode failures to the Core
> Network.
>
> This patch series tries to address the above-mentioned issues:
>
> 1. Reject unauthenticated SMC messages, enforcing the requirement that
> they must be integrity-protected.
> 2. Validate MAC before applying security settings, ensuring that only
> authenticated messages are accepted.
> 3. Tear down the security context if an integrity check fails.
> 4. Introduce the Security Mode Reject message to inform the Core
> Network of failed SMC procedures, as required by TS 24.501.
This change performs the algorithm rejection in the corresponding NAS
handler for 5G, since the protocol definitions differ between LTE and
5G, regarding NIA0/EIA0 user plane traffic.
Therefore, for 5G NIA0 is rejected, since it is not allowed under normal
circumstances, while LTE user plane traffic can indeed have EIA0
selected.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
It is not allowed to accept an unauthenticated SMC message,
as this effectively bypasses all security measures and
enables a malicioius attacker to compromise the confidentiality
and integrity of exchanged messages.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Co-authored-by: Guido Casati <hello@guidocasati.com>
Retrieving the mac is necessary during the handling of the SMC, since the
context is generated from the specified keys therein. Therefore, it is
necessary to check the MAC right after generation and ensure the authenticity
of the message. If it is not given, the message must be rejected.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Co-authored-by: Guido Casati <hello@guidocasati.com>
This is necessary to indicate to the Core network, that
the security mode command procedure has failed.
Check for the security context presence when generating the Security Mode
reject message: according to 3GPP TS 24.501 5.4.2.5 "NAS security mode command
not accepted by the UE" The UE shall send a SECURITY MODE REJECT containing
a 5GMM cause that typically indicates one of the following cause values:
(23) UE security capabilities mismatch
(24) security mode rejected, unspecified
The message shall be protected if a security context is available
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Co-authored-by: Guido Casati <hello@guidocasati.com>
This 5GMM message is required for an invalid security mode command,
e.g. when the MAC integrity fails, or the wrong Security Header is set.
* Add encode/decode functions for common IEs in fgmm_lib: this library
provides encoding/decoding helpers for IEs shared across multiple
NAS messages. The goal is to avoid the legacy approach of creating
separate files per IE
* add NAS Cause enc/dec lib
* Adopted byte_array_t to handle the buffer
Co-authored-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Fix various bugs and inconsistencies in config read, SCTP, ITTI, GTP
Fix bugs across various layers, mostly layer 3, including memory leaks.
See the commits for more details.
Robert Schmidt