RSL CHAN ACT contains a MS_POWER IE which is intended to be used as the
initial power level for the MS, before the UL power control loop is
starting.
In our case, if ul_power_target != 0, then the DSP takes care of power
control. If ul_power_target == 0, then we instruct the phone to
constantly use the value specified by the BSC in the MS_POWER IE.
FIXME: Actually implement a proper power control algoritihm inside
osmo-bts so we don't have to rely on the DSP implementation.
In case opening a calibration file is failing an error will will be
logged, the caller and implementation were inconsistent about the API
version that is supported for the calibration data, attempt to make
the cut-off at 2.4.0.
Issue the RfDeactivate.REQ before sending the MphClose.REQ. Ideally
we would issue MphClose.REQ after the RfDeactivate.CNF but this is
not possible right now.
The current approach makes the following warning of the DSP go away
on shutdown. This was tested with my E71 and an active silent-call
using a SDCCH.
DSP Warning:
[ERROR] : DeviceMng_ValidateL1Handle() => Invalid layer 1 handle
* Simplify the callback signature. The trx is now the first argument.
* Embed the calibration data into the femtol1_hdl.
Tests:
* All commits are compile tested
* All commits bring up the radio (without using calibration data)
* Calibration data loading has been tested with the merge
* All commits allow a IMSI Attach and a MO Call (to an invalid unknown
number). All channels are freed after this. It has been tested with
the E71.
The TxPower handled used to call the requestion function without
a callback. In that case the msgb is leaked. The code still allows
the callback to be NULL so we will just delete the message in that
case.
All users (but the gsm_compl) of the l1if_req_compl use it with
is_system_primitive=1. We can now remove this parameter from the
method. Introduce _l1if_req_compl that will insert the item into
the queue for us.
l1if_gsm_req_compl everyone is passing the trx as data pointer right
now, remove it from the request procedure right now as it can be
deducted from the femtol1_hdl.
AGCH is reported as part of the PCH because we are not searching
for the BS-AG-BLKS-RES inside the SI3 and do not use MphConfigReq
to change this setting.
If the CRCX does not indicate the remote IP address, then we still were
binding to 0.0.0.0 and used that address successively in the CRCX_ACK.
As a workaround, we now use the source IP address of the RTP socket,
assuming that the outbound routes to BSC and the MGW are identical.
This is of course not always true, but I don't think there are any
better alternatives...
for whatever reason i decided that a port number in
osmo_rtp_get_bound_ip_port() needs to be a int * and not a uint16_t * at
the time, so we have to deal with this here rather than breaking the
ABI.
After we create a socket and bind it to INADDR_ANY, we cannot yet use
getsockname() to resolve the locally bound IP. This only works after
the socket has been connected to the remote IP. So we have to move the
osmo_rtp_get_bound_ip_port() to a code section after
osmo_rtp_socket_connect() has already happened.
With the code prior to this commit, unless "rtp bind-ip" was used in the
config file, we reported "0.0.0.0" as the "Source IP AddresS" in the IPA
CRCX ACK to the BSC. This is of course wrong, as the BSC will then use
this "0.0.0.0" as destination address for the incoming RTP stream :(
Please note that for this fix to work, you also need a libosmoabis.git
with commit d426d458ca96ba29793e35b1b2a73fbcb3b2c888 which actually
causes osmo_rtp_socket_connect() to actually issue connect() on the
socket at all.
Instead of explicitly having to specify the local IP address for RTP
sockets in the BTS, we just use "0.0.0.0" instead, which gets
translated to INADDR_ANY.
We still accept the configuration directive in old config files, but
when we write, the line will no longer be re-written to the file.
TODO: IMHO, the IPA RSL CRCX/MDCX actually permit the BSC to specify the
IP address on the BTS side, and we probably simply ignore this at this
point.
When we send a fill frame on SACCH, we need to have two bytes for the L1
header at the beginning (inserted by the DSP).
Thanks for Andreas Eversberg for pointing it out.
As we currently don't use any BSC-based MS power control in either
OpenBSC nor in OsmoBTS, this bug has never shown up so far.
Thanks to Andreas Eversberg for spotting this.
Move the channel activation out of the loop into a dedicated function.
This is done in preparation of separating the decision to activate
something and sending the request.
Prepare to change the queue and callback handling. For the TX power
VTY command it is still possible that it will conflict with other
callbacks and the easiest way is to beging with sending these requests
through another method that allows us a more strict test.
The wait list code has a limitation that for two requests of the
same kind it does not know where the confirmation belongs to. This
limitation is triggered when two lchan's get activated/deactivated
at the same time and is noticed once we start to count the SAPIs.
Set the hLayer3 to the lchan identifier, use the trx as closure for
the callback and resolve the lchan in the callback using these two
bits of information.
We are using this conversion for both hLayer2 and hLayer3. Make the
function name more generic to indicate that this function can be used
with the hLayer3.
The functions that call the methods were updated using spatch and
@rule1@
expression E;
expression F;
@@
- l1if_hLayer2_to_lchan(E, F)
+ l1if_hLayer_to_lchan(E, F)
@rule2@
expression E;
expression F;
@@
- l1if_lchan_to_hLayer2(E)
+ l1if_lchan_to_hLayer(E)
During call testing using an E71 and dialing a number of an expired (lac
set to 0) subscribe the CC Release and other messages are sent after or
during the channel modification. This appears to lead to some reception
issues in the DSP code and giving use empty (u8size == 0) FACCH frames.
The real issue might be inside the MNCC code of NITB and the lack of a
size check inside the LAPDm code (our msgb has enough data though).
Passing the empty FACCH frame into the LAPDm code lead to the generation
of RSL ERROR INDICATION with cause FRAME_UNIMPL as some bits were zero.
Add a check for 0 into the FACCH code. As the code path is shared with
SDCCH it is also discarding zero sized SDCCH frames. These have not been
observed during my testing. The lacking size check in LAPDm will be
addressed separately.
During call testing the IPA CRCX was also failing due the BTS trying
to bind to an unassigned IP address.
The other message in this method is using a \n as well and the line
is generally now followed with a LOGPC.
It looked like this:
<0006> l1_if.c:672 SACCH with size 0<2 !?!<0006> tch.c:540 (bts=0,trx=0,ts=2,ss=0) Rx Payload size 0
We only need to run this once and we know the clock error. In case it
is 0/0 we know that we didn't receive one of the two clocks. This could
be because the GPS doesn't have a fix. I accidently pushed this code into
the master branch and it is too late to rebase.
These attributes are saved in paging_state, we don't need to save them a
second time in struct gsm_bts_role_bts. Add get and set methods for
these attributes and use them consitently in the VTY code.
This was experienced by Daniel on his 64bit machine. The paging
expiration time was too high and not set by the code at all. Using
gdb watchpoints he found the place where the memory is written. The
issue is that the size of the pointer (8) and not the size of the
data structure was copied (3).
Fix the issue by assigning the de-referenced value. gcc generates
the same code as if we had written:
memcpy(&ps->chan_desc, chan_desc, sizeof(*chan_desc));
When only signalling is used on the TCH/H it is normal that there
is no TCH data. Save CPU time by not printing the message. This
needs to be moved to be edge triggered.
This was found and debugged by Sylvain. The BTS will always support
A5/0 so we do not keep track of that, the first bit of the flags is
used for A5/1, second for A5/2... but for RSL there is an offset to
go from RSL to A5(x). Add a testcase and change the code.
This file is created in ./configure so we shouldn't remove it with make.
Otherwise ./configure && make clean && make check fails
with:
make[3]: *** No rule to make target `atconfig', needed by `check-local'.
Stop.
* Comment out the osmo-bts-bb/Makefile as we have removed it from
the SUBDIRS and are not packaging the code right now
* Add missing include files for the build
Harald Welte
Holger Hans Peter Freyther