What if it's -1? Is it possible?
We catch the case and abort.

We may do a proper fix if the case happen.
I don't think it will, but who knows...

RRC does not work very well when one UE goes away and comes
back in some situations.

This commit is an attempt at making things work better.

It is probably not the end of the story.

It resulted in wrong log message, leading to complicated
debugging.

Modern UEs have very long UE capabilities.
It disrupts realtime behaviour of the modem.

Let's put a simple log message indicating we got the
UE capabilities.

Here is the problem:
    Sometimes the UE has no PHY context but
    is still present in the MAC with 'ul_failure_timer' = 0 and
    'ul_out_of_sync' = 0. It seems wrong and the UE stays there forever. Let's
    start an UL out of sync procedure in this case.
    The root cause of this problem has to be found and corrected.
    In the meantime, this hack...

This has to be redone at some point.

Here is the problem:
    UE comes. SRB2 is configured via message to RRC.
    At some point the RLC AM is created but not configured yet.
    At this moment (I think) MAC calls mac_rlc_status_ind
    which calls this function. But the init was not finished yet
    and we have a crash below when testing mem_block != NULL.

The "solution" is to test if rlc->input_sdus is NULL.
This is a very dirty hack. I would say the solution
is to use proper locking mechanism because RLC is used
by two threads: PHY/MAC on one hand and RRC on another
hand (I think).

The management of uplink failure generates a DCI to send
a RA PDCCH order. It calls add_ue_spec_dci which increases
DCI_pdu[CC_id]->Num_ue_spec_dci, but this was reset to 0
*after* the DCI generation. Let's reset *before*.

Bug reported by Liang Yong on openair5g-user mailing list.

The function may return NULL if the UE has been dropped
in the PHY layer but is still present in the MAC layer.

Deal with the NULL case everywhere it's needed.

Develop integration w02

See merge request !82

This is the real fix, d5a6817887e720935d9dcc0a6f7d632e85c7d8e5
was not the right solution.

Conflicts:
	targets/RT/USER/lte-softmodem.c

I am not sure this is the correct solution.

The problem seems to be that the RRH GW does not use ITTI
and thus the type 'as_nas_info_t' is not defined, and then
the compilation fails.

The simple fix is to include 'as_message.h' in
'openair2/RRC/LITE/defs.h' if ENABLE_ITTI is not
defined. Maybe it's not good. RRH GW compiles with this fix.

"frame" is not defined, we pass 0 instead.

Maybe not the right solution.

It is defined both in openair2/COMMON/commonDef.h and
openair2/COMMON/platform_types.h.

Removing one or the other definition creates many problems
when compiling this or that part of the system (ue_ip.ko,
at_nas_ue). Let's keep both and protect the definitions
inside #ifdefs.

I'm not sure this is the right fix, so I put a LOG_TRACE
that is displayed when the code comes here.

I chose to remove it from common/utils/itti/itti_types.h,
maybe it's not the correct solution.

Several various fixes are included. Not sure what component of
the system uses this file.

There is one 'abort' added in case a fscanf fails. It may be a
bit too brutal.

This is not absolutely necessary (the processing is ok),
but the warning is annoying.

I forgot one file in the previous commit

Some of them might not be correctly handled.
I put /* TODO: XXX */ where I didn't know if
the fix was correct.

init_nas_s1 may not work properly, but many people complain
about this file, so let's put it in the repository.

We'll fix it at some point if it's not properly usable.

The LOG_X macros emit a lot of warnings when compiling with the T
because they call the function logRecord (or logRecord_mt)
which has not been "marked" as calling printf, so gcc won't
emit typical printf warnings.

With the T, they directly translate to sprintf, so those warnings
pop up, much more verbose due to several macro expansions.

Let's make them pop up all the time so it's easier to fix them.

Develop integration wk01

See merge request !74