Also removed several warnings by properly
declaring nr-nFAPI functions and removed
declaration of unused functions. Also, reverted
eNB configuration file changes.
This caused the SCTP descriptor to be reset. This
made issues in the X2 interface between gNB and eNB.
Lots of logs added here. Need to fill NR_UE_Capability_Info
properly.
Now, we are able to fill the UE_Capability_Info that
the LTE UE and eNB are expecting. We then are able to
generate a RRC_DCCH_DATA_COPY_IND to trigger the
processing of the UE_Capability_Info (and sending the
info to the eNB). The info being received at eNB has not
been tested yet.
Also some code clean up.
Also removed the [eNB_index + 1] saving/writing
in the process_MeasObj function. This indexing
was incorrect. Also cleaned up the code, fixed
ssRSRB -> ssbRSRP. Lastly, added assertFatals
around indexing in process_measObj function.
Added check and logs. If we change ind = 1 it
crashes the LTE UE so we log for now. Also cleaned
up a lot of the code. Lastly, we set freed vars to NULL.
This commit has several other changes. The changes
include the following:
1. Changed the port numbers for the NRUE<->Proxy
2. Fixed the send to function in the NR UE
(Previously only sending buffer not buffer+msg_type)
3. Updated pack/unpack of the SSB PDU (new RSRB field added)
4. Fixed several NR logs
5. Opening socket with NRUE<->Proxy AFTER receving RRC
measurement request from the LTE UE
This commit also removed MAX_NUM_NEIGH_CELLs and
replaced it with MAX_GNB_CELLS. This was a minor change
OAI added. The standalone sockets for the NR UE correctly
connect to the proxy. We are currently receiving dl_tti
messages from the proxy.
Also enabled X2 when we are not using the EPC
Added in the case statement for handling the
dl_dcch_msg from the NR UE. Also added in the
proper decoding of that dl_dcch_msg and freeing
This code allocates memory from the heap:
```
static void *UE_phy_stub_standalone_pnf_task(void *arg)
{
...
UL_INFO->crc_ind.crc_indication_body.crc_pdu_list =
calloc(NB_UE_INST, sizeof(nfapi_crc_indication_pdu_t));
```
I see NB_UE_INST==1.
Then this code:
```
void fill_crc_indication_UE_MAC(int Mod_id,
int frame,
int subframe,
UL_IND_t *UL_INFO,
uint8_t crc_flag,
int index,
uint16_t rnti,
nfapi_ul_config_request_t
*ul_config_req) {
...
nfapi_crc_indication_pdu_t *pdu =
&UL_INFO->crc_ind.crc_indication_body
.crc_pdu_list[UL_INFO->crc_ind.crc_indication_body.number_of_crcs];
```
used .number_of_crcs to index into .crc_pdu_list without first
checking if .number_of_crcs is in range.
When run with multiple UEs, sometimes .number_of_crcs==1 and then
-fsanitize=address complains.
Change is to use NUMBER_OF_UE_MAX instead of NB_UE_INST.
With this change, -fsanitize=address stopping complaining.
-fsanitize=address detected that we were trying to access bytes
past the end of a block of malloc'ed memory.
Specifically, in this code:
```
} else if (ENB_NAS_USE_TUN) {
if( LOG_DEBUGFLAG(DEBUG_PDCP) )
log_dump(PDCP, pdcpData, sizeToWrite, LOG_DUMP_CHAR,"PDCP
output to be sent to TUN interface: \n");
ret = write(nas_sock_fd[0], pdcpData, sizeToWrite);
```
-fsanitize=address said:
```
==80==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61100004ffdc at pc 0x7f57c5f576a5 bp 0x7f57bb53c240 sp
0x7f57bb53b9e8
READ of size 108 at 0x61100004ffdc thread T7
0x61100004ffdc is located 0 bytes to the right of 220-byte region
[0x61100004ff00,0x61100004ffdc)
```
So, the code was trying to access the first byte after a block of
heap memory.
sizeToWrite was calculated like this:
```
int sizeToWrite= sizeof (pdcp_data_ind_header_t) +
pdcpHead->data_size;
```
There were a few other similar invocations of write() in the same
function used the wrong size. That sizeToWrite calculation
should be used only when the header is being sent, too, which
happens in only one place in this function.
With this commit, our tests pass and -fsanitize=address is happy.
The global mbms_rab_id was defined as `uint16_t` in
eNB_scheduler_mch.c but `int` in other places. So, code that
wrotes this global would clobber the two bytes that follow the
variable in memory.
Found by `-fsanitize=address`.
For some reason the htons invocation got deleted which broke
the VNF P7 interface.
Also fixed some build issues, not sure how these got onto the
develop branch to begin with.
Removing references to memcpy_dl_config_req and
memcpy_tx_req because these functions are leaking
memory. For our standalone mode we have created
new/modified memcpy_dl/tx_req functions.
Melissa Elkadi