The following error was appearing when running LTE UE:
inet_pton(): cannot convert -64.-74.0.2 to IPv4 network address
The allocated address by the core actually is 192.182.0.2.
On my host "char" is signed, leading to the above error (192 and 182
are seen as signed).
Let's force "ip_addr" unsigned and everyone is happy.
OAI is riddled with boolean_t, FALSE, TRUE, etc. This makes no sense, as
there is a standard bool type, and could lead to nasty bugs if a
definition of a bool is non-standard (0 == false, true == !false). This
commit removes all non-standard bools in the whole project.
Updated the configuration files. Added a sleep to
ensure that the LTE UE gets attached to the EPC
before the bearer is modified to be gNB. Updated
the ifconfig tunnel up command to be brought up
by the NR UE socket when in NSA mode. Lastly,
started the gNB PDCP layer in S1 mode.
Once the LTE UE's tunnel interface with the EPC
is ready to be established, if we are in NSA mode,
we do not want to launch the tunnel interface
from the LTE UE side, but in the NR UE. Via itti_msgs
we send the string containing the tunnel interface
'up' command to the NR UE and bring it up from the NR UE.
Every if statement that includes a check for
the NFAPI_MODE that did not check for the new
PNF_STANDALONE_MODE now has been updated. Also
changed the tx_req and dl_config_req logs
when they are received at the OAI UE to be
info logs instead of error logs.
This completely removes the UESIM_EXPANSION define: it does not compile
at the moment. Its function was to multiplex multiple UEs on the same
TUN interface. However, this functionality is not needed since it is
possible to allocate many TUN devices (i.e., >= 32).
This change allows us to disable the LOG_I messages to reduce
overhead.
Removed LOG_VAR macro because it was used in only one place, and
a better solution is to simply use `__attribute__((unused))`.
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.
Those functions modify a global char array (a string).
Let's pass a buffer to those functions, so that it's
thread safe. The caller has been modified, with hopefully
a buffer big enough (still bigger than what was there before,
so should not break more than it did).
Surprisingly, it touches every part of openair3, and most of the prototype.
Moreover, a special attention have been put to callback review.
However, there are still places to fix or review indicated by FIXME
Cedric Roux