The port to use should be 2152, not 2153.

those popped up thanks to previous commit

- print current working directory
- print git version (if available)
- print security keys
  this last one is a security breach, but as of today
  it's not a problem

No need for this special case. Plus, it fails with the work
from Nokia on compilation cleanup.

----------------------------------------------------------
bug 29

Ttile:
FDD should be TDD.

Bug Location:
  switch (oai_emulation.info.frame_type[0]) {
  case FDD:
    frame_type = "FDD";
    break;

  case TDD:
    frame_type = "FDD";
    break;
  }
----------------------------------------------------------

----------------------------------------------------------
bug 18

Ttile:
Probably he/she wants to copy the contents of arrays, but
this coding doesn't copy anything, moreover index overflow
occurs.

Bug Location:
u2e_t[UE_id][eNB_id]->tx_data[3]=tx[eNB_id][3];
u2e_t[UE_id][eNB_id]->rx_data[3]=rx[NB_eNB_INST+UE_id][3];

Note:
Detected by CppCheck
----------------------------------------------------------
bug 19

Title:
Probably he/she wants to copy the contents of arrays, but
this coding doesn't copy anything, moreover index overflow
occurs.

Bug Location:
e2u_t[eNB_id][UE_id]->tx_data[3]=tx[NB_eNB_INST+UE_id][3];
e2u_t[eNB_id][UE_id]->rx_data[3]=rx[eNB_id][3];

Note:
Detected by CppCheck
----------------------------------------------------------
bug 20

Title:
Probably he/she wants to copy the contents of arrays, but
this coding doesn't copy anything, moreover index overflow
occurs.

Bug Location:
tx_data[3]=cthread->tx_data[3];
rx_data[3]=cthread->rx_data[3];

Note:
Detected by CppCheck
----------------------------------------------------------

- RBs set to 25
- disable SRS

Using "system" to call "git log" is too error-prone.
In the test setup, lte-softmodem was blocked because
"git log" uses a pager ("less") and the pager was
waiting for the user to press enter.

We could pass "--no-pager" to "git log" but then
what if someone runs the softmodem out of the source
tree?

cmake defines PACKAGE_VERSION, we can use that instead,
as is done in openair-cn.

We have a strange problem with the timestamp of the very
first packets received from the LimeSDR that leads to
a complete failure of the eNB.

A simple workaround is to discard the first RX packet
just after a "start" of the device.

We also change the value of "tx_sample_advance" to a more
reasonable value. The problem of timestamp was "solved"
differently in the past and at the time we needed to put
a much higher value.

This may have to be refined at some point.

not sure of this one, to be checked

6 numbers (2 hexa digits each) separated by ':'
plus ending 0 makes 18 bytes, not 6, let's put 20

- LMSSDR was not handled
- bad #if usage
- bad indentation

still not very clean, but better

- import RRC ASN.1 defintions from the specifications
  (file openair2/RRC/LITE/MESSAGES/asn1c/ASN1_files/RRC-e10.asn)
  contrary to rel8/10, all modules have been imported, maybe it's too much
  to refine in case of problems
- deal with rel14 in fix_asn1
- all code that was for Rel10 is now for Rel10/Rel14
- some incompatible changes (mostly in naming) were resolved in favor
  of rel14, see in openair2/RRC/LITE/defs.h
- unsure about the rlc layer, some arrays have changed (values appended),
  I only changed the definition and in tests in the code, I changed
  the index limit, maybe it's not enough

Rel14 is the default compilation mode.

see https://gitlab.eurecom.fr/oai/openairinterface5g/issues/227

When the UE connects to the eNodeB and receives its IP address from the
network, it calls system() to set it in the linux kernel world. This call
is not done in a realtime thread, but in the NAS, which uses its own thread,
independent of the realtime processing.

In some situations this totally disrupts realtime processing.

It is difficult to know precisely why that happens, but it seems that calling
fork(), as system() does, in a multi-threaded program is not a good idea. (So
say several people on the internet.) It is not clear why the softmodem is
impacted, but it seems that fork() is really what triggers the disruption.
Several tests lead to that conclusion.

To fix the problem, we create a child background process very early in main()
(before anything else basically). Then instead of calling system(), the main
process sends the string to the background process. The background process
gets the string, passes it to system() and reports the success/failure back
to the main process.

This solution involves a lot of system calls, but calling system() in the
first place is not cheap either. As long as no realtime thread uses this
mechanism, things should be fine. Time will tell.