If your configuration file does not contain a parameter
the softmodem only printed "Failed to parse eNB configuration file"
without telling you what parameter was not found.
This quick fix adds a warning in such cases.
It also exists at the first error rather than trying to
parse the rest of the configuration file.
This hotfix does not change the processing at all.
At this point, stat_re == 0, so the behavior is the
same as before. But the code was wrong. There should
have been no test, it's a NACK, period.
download asn1c from oai gitlab
We need to test at least one attach by the UEs of the test setup, to check that the local asn1c is the same as the one from github we used so far.
I don't think we need to do lots of traffic, it's only about control plane (rrc, s1ap).
And of course see if compilation is still ok.
See merge request !40
the official asn1c repository at github posed problems to
some people in the past. It's better to have it locally
for such a critical piece of the software.
This tracer takes the traces ENB_MAC_UE_DL_PDU_WITH_DATA
and ENB_MAC_UE_UL_PDU_WITH_DATA from a trace file
(as generated by the "record" tracer) and sends them
in UDP packets correctly formatted for wireshark to
dissect them.
One unresolved problem I face with my version of
wireshark (1.10.6) is that I don't get the frame number,
only subframe. See in the code to change the behavior
if you use a more recent version of wireshark.
You need to properly configure wireshark for it to work.
See $OPENAIR_DIR/openair2/UTIL/OPT/README.txt.
This was causing oaisim to fail way too often at the startup
of a connection.
Things should go better with this patch.
It may not be the end of the story, the use of retrans_num_bytes_to_retransmit
is not clear to me. The problem I see is: what if the max number of
retransimission has been reached (if that has a meaning at all in RLC AM)?
will this value be decreased or not?
The code was changing the rnti in the red-black tree without
removing/reinserting the context. This is wrong because the
rnti is a key of the red-black tree and you cannot change the
key in a stored item at will.
There are also modifications of the function mac_eNB_rrc_ul_failure
which has to remove the UE in any case.
And rrc_mac_remove_ue has been changed for the case where
the UE is not found.
It creates more problems than it solves.
We replace this approach by a straightforward
synchronous one.
Now in the downlink, at frame f and subframe s
we use HARQ process (f * 10 + s) % 8.
This is similar to uplink scheduling.
The T has 2 processes: the tracee and the local tracer
if the tracee dies (segfault or whatever) the tracee
may still be running.
So there is a third process that monitors those two others
and kill everything when one dies.
The problem is that this third process has to be the parent
of the two others. That makes debugging the tracee with gdb
impossible. This new option disables the third monitor process.
And it's sent at each connection attempt.
Before it was sent only once to the first tracer.
Plus there was a bug (length:(len) should have been length:(send_size)).
That led to uplink two resource blocks to fail being decoded (not always),
due to wrong channel estimation. (As was the previous hotfix for five
resource blocks.)
This commit also includes some cleanup of some historical code that is
not relevant anymore.
XY_LOOP_MODE: replace old points with new ones, using the maximum size
of the view
XY_FORCE_MODE: append_forced sets those and only those points
and we crash if we pass too much points
improve the use of the variable "frame" in oaisim
The modifications are only in oaisim.c.
It is thus needless to run soft-modem tests.
Only oaisim tests are required.
See merge request !34
this is like timeview but the plotting is done at frame/subframe
resolution of a given reference clock signal, let's say.
The realtime information of the events is not used. It's all
logical.
It will be used to log harq processes for the moment.
this may be removed at some point, it's very brutal. But when you
write some code, it may happen (it "may"!!) that *sometimes* the
code does not work and crashes. In thoses cases I prefer the
local tracer (or the tracee) to go away immediately without even
thinking about it maybe still running in the background.
In case of monitoring (as opposed to debugging) maybe it's preferable
to let the process live its life as it wants.
Time will tell.
Cedric Roux