* In LTE there is logic that checks the thread configurtion with the
getters `get_thread_parallel_conf()` and `get_thread_worker_conf()`
in NR these getters are not used, only setters, which have no impact
* buffer is allocated but not freed after use by PDCP
> Direct leak of 192 byte(s) in 3 object(s) allocated from:
> 0 0x7ffff74b4c38 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
> 1 0x55555775ee74 in encode_dyn_cb /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/per_encoder.c:23
> 2 0x55555774776e in _uper_encode_flush_outp /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:126
> 3 0x55555774776e in uper_encode /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:36
> 4 0x555557747c91 in uper_encode_to_new_buffer /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:85
> 5 0x5555576c5172 in do_NR_ULInformationTransfer /openair2/RRC/NR/MESSAGES/asn1_msg.c:965
> 6 0x555556fba691 in rrc_nrue /openair2/RRC/NR_UE/rrc_UE.c:1819
> 7 0x555556fc4d2e in rrc_nrue_task /openair2/RRC/NR_UE/rrc_UE.c:1717
> 8 0x7ffff5e94ac2 in start_thread nptl/pthread_create.c:442
* bcch_message is malloced by ASN.1 decoder and needs to be always freed after use along with its contents
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>0 0x7ffff74b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>1 0x555557737ecd in SEQUENCE_decode_uper /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/constr_SEQUENCE_uper.c:37
>2 0x555557746f81 in uper_decode /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/uper_decoder.c:83
>3 0x5555577471fe in uper_decode_complete /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/uper_decoder.c:16
>4 0x555556f8b1c9 in nr_rrc_ue_decode_NR_BCCH_DL_SCH_Message /openair2/RRC/NR_UE/rrc_UE.c:732
>5 0x555556fbc365 in rrc_nrue /openair2/RRC/NR_UE/rrc_UE.c:1775
>6 0x555556fc4c2e in rrc_nrue_task /openair2/RRC/NR_UE/rrc_UE.c:1718
>7 0x7ffff5e94ac2 in start_thread nptl/pthread_create.c:442
* local dl_dcch_msg shall be freed after use
> Direct leak of 384 byte(s) in 6 object(s) allocated from:
>0 0x7ffff74b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>1 0x555557737ced in SEQUENCE_decode_uper /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/constr_SEQUENCE_uper.c:37
>2 0x555557746da1 in uper_decode /cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/uper_decoder.c:83
>3 0x555556fa4b31 in nr_rrc_ue_decode_dcch /openair2/RRC/NR_UE/rrc_UE.c:1612
>4 0x555556fbb25c in rrc_nrue /openair2/RRC/NR_UE/rrc_UE.c:1792
>5 0x555556fc4a4e in rrc_nrue_task /openair2/RRC/NR_UE/rrc_UE.c:1718
>6 0x7ffff5e94ac2 in start_thread nptl/pthread_create.c:442
* The RRC task is freeing the ITTI message but the message members that are allocated separetely still need to be freed
> Direct leak of 470 byte(s) in 6 object(s) allocated from:
>0 0x7ffff74b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>1 0x55555721f117 in itti_malloc /common/utils/ocp_itti/intertask_interface.cpp:64
>2 0x555556f2356c in deliver_sdu_srb /openair2/LAYER2/nr_pdcp/nr_pdcp_oai_api.c:775
>3 0x555556f4e10e in nr_pdcp_entity_recv_pdu /openair2/LAYER2/nr_pdcp/nr_pdcp_entity.c:184
>4 0x555556f278ad in do_pdcp_data_ind /openair2/LAYER2/nr_pdcp/nr_pdcp_oai_api.c:285
>5 0x555556f278ad in pdcp_data_ind_thread /openair2/LAYER2/nr_pdcp/nr_pdcp_oai_api.c:307
>6 0x7ffff5e94ac2 in start_thread nptl/pthread_create.c:442
* allocate memory in heap for the struct ue_CapabilityRAT_Container used locally for buffer encoding
* free the struct members only for the ul_dcch_msg allocated on the stack
> Direct leak of 40 byte(s) in 1 object(s) allocated from:
> 0 0x7ffff74b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> 1 0x555556f7a89f in nr_rrc_ue_process_ueCapabilityEnquiry /openair2/RRC/NR_UE/rrc_UE.c:1861
> 2 0x555556fa4d85 in nr_rrc_ue_decode_dcch /openair2/RRC/NR_UE/rrc_UE.c:1650
> 3 0x555556fbb33c in rrc_nrue /openair2/RRC/NR_UE/rrc_UE.c:1790
> 4 0x555556fc4b2e in rrc_nrue_task /openair2/RRC/NR_UE/rrc_UE.c:1716
> 5 0x7ffff5e94ac2 in start_thread nptl/pthread_create.c:442
* strdup() function is returning a malloced string
which must be freed after use
* replace the strdup with direct use of strings to avoid heap allocation
> Direct leak of 23 byte(s) in 1 object(s) allocated from:
> 0 0x7ffff745b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
> 1 0x555559e36f87 in RCconfig_nr_parallel /openair2/GNB_APP/gnb_config.c:2054
> 2 0x555559e38ea3 in NRRCConfig /openair2/GNB_APP/gnb_config.c:2097
> 3 0x555559155542 in get_options /executables/nr-softmodem.c:423
> 4 0x555559155542 in main /executables/nr-softmodem.c:623
> 5 0x7ffff5e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
> Direct leak of 14 byte(s) in 1 object(s) allocated from:
> 0 0x7ffff745b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
> 1 0x555559e370c5 in RCconfig_nr_parallel /openair2/GNB_APP/gnb_config.c:2063
> 2 0x555559e38ea3 in NRRCConfig /openair2/GNB_APP/gnb_config.c:2097
> 3 0x555559155542 in get_options /executables/nr-softmodem.c:423
> 4 0x555559155542 in main /executables/nr-softmodem.c:623
> 5 0x7ffff5e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
- num DL/UL harq processes, bits for harq id in DCIs, set according to IEs configured in RRC messages
- removed going through all the harq processes before triggering nr_ue_ulsch_procedures in phy_procedures_nr_ue.c
- did not remove usage of MAX_HARQ_PROCESSES in init phase
- Enabled configuration for number of dl, ul harq processes in conf file
- set "num_dlharq = 32; num_ulharq = 32;" under "gNBs" section in the conf file
- default values when not configured is 16 for DL, UL harq processes
- IEs in the RRC messages set according to the number of DL, UL harq processes configured.
- If value 32 is configured , then IEs related to num harq processes and dci bits also configured in Bandwidth parts.
- MAX HARQ PROCESSES set to 32
- for PDSCH - default setting in OAI is 16, according to 3GPP rel17 38.331 these are the possible configs
- if no IES are defined then 8
- if nrofHARQ-ProcessesForPDSCH is defined then these values- {n2, n4, n6, n10, n12, n16}
- if nrofHARQ-ProcessesForPDSCH-v1700 is defined then 32
- for harq bits in DCI
- DCI 1_0 - 4 bits spec 38.212, section 7.3.1.2.1
- DCI 1_1 - 4/5 bits according to IE harq-ProcessNumberSizeDCI-1-1, spec 38.212, section 7.3.1.2.2
- for PUSCH - default setting in OAI is 16, according to 3GPP rel17 38.331 these are possible configs
- if no IES are defined then 16
- if nrofHARQ-ProcessesForPUSCH-v1700 is defined then 32
- for harq bits in DCI
- DCI 0_0 - 4 bits spec 38.212, section 7.3.1.1.1
- DCI 0_1 - 4/5 bits according to IE harq-ProcessNumberSizeDCI-0-1, spec 38.212, section 7.3.1.1.2
- FOR HARQ32 , DCI 1_1, DCI 0_1 should be configured in UE dedicated search space. In OAI it is set.
Handle IPv6 (and IPv4v6) PDU sessions by correctly instructing
nas_config() to set up the interface with provided IP addresses.
Note that as of now, IPv6 PDU sessions have not been fully tested.
Remove a useless assert at the gNB; to my understanding the gNB does not
care about the IP session type (at least for IP), as it just
transparently tunnels the IP packets from/to GTP.
I added a comment in the code where to change to request a PDU session
different from IPv4. Currently it is hardcoded to IPv4, and it seems
that a default OAI 5GC config would reject a PDU session type different
from IPv4.
- Read interface flags before setting status to not inadvertently
overwrite existing flags
- Set interface flag point-to-point, remove multicast (I think a UE is
not supposed to send anywhere else than to the UPF, so it seems to not
make sense to declare the interface as multicast)
These rules & route are necessary to properly send packets on oaitun_ue1
interface:
1. This forces the packets coming from a subnet different than the UE's
subnet to go back through oaitun_ue1 rather than via what the default
route defined on the system (e.g., important if ping from the
internet arrives).
2. On machines setting net.ipv4.conf.oaitun_ue1.rp_filter=1 (e.g.
RHEL), this prevents that source filtering for packets coming back is
applied and those packets be dropped. By default, many hosts have
rp_filter=2, so no strict source filtering is applied, and it would
work; on others, this rule prevents source filter dropping.
Prior to this commit, there was a global variable baseNetAddress that
could be set independently through a setter and also through the
configuration module. This baseNetAddress (16 bits IPv4) would then be
complemented with two more bytes in nas_config().
However, this is counter-productive, as not only we have a global
variable that is avoidable (we can give the entire address to
nas_config() directly), but it also would not work with IPv6. Hence,
modify to give nas_config() the entire address. A follow-up commit will
add IPv6 support.
- refactor functions to make them shorter
- provide doxygen strings
- open socket for operation once instead of in each function
- use named constant (from enum) to differentiate interface UP/DOWN
- Linux kernel defines name length as IFNAM_SIZE, so use that for
interface name length. Also, it seems no null-byte is needed.
I initially planned to entirely remove the netmask configuration.
However, in specific configurations, e.g. in 4G Rfsim with feMBMS,
routing does not seem to work anymore using these commands:
iperf -B 10.0.2.2 -s -u -i1
iperf -c 10.0.2.2 -B 10.0.2.1 -u -t 30 -b 2.00M -i1
Therefore, we simplify by hardcoding the netmask to /24, which allows
the above to work.
Remove the broadcast address from the UE, as logically, a UE has nothing
to broadcast: it can only directly talk to the core. Additionally, at
least as of now, the UE interface is shown as "POINTOPOINT", so
broadcasting is not possible.
Does the same change in the _mbms() functions as in the previous commit.
Also, simplify logic in netlink_init_mbms_tun(): directly use the id in
the interface. This requires a slight ID change in the users, which is
also done in this commit.
Instead of implicitly using a hardcoded prefix "oaitun_" interface
name, move that out to the callers of these functions to make it clear.
The ID still remains outside.
The "sister functions" nas_config_mbms()/netlink_init_tun_mbms() will do
the same change in the next commit.
Comparing both functions, it seems that nas_config_mbms_s1() sets the
same parameters, assuming that in nas_config_mbms(), we set
- (UE_NAS_USE_TUN || ENB_NAS_USE_TUN) yielding true -> should yield the
same interface name
- netmask is hardcoded to 255.255.255.0
- baseNetAddress is hardcoded 10.0
So replace the call with nas_config_mbms() by setting parameters
accordingly.
francescomani