Extend the router to verify that the message received is
properly encoded. The code can deal with the basic structure
of ETSI OML and vendor specific messages for ip.access and
the osmocom project.
Begin with the basics of a OML Router. This is currently only
capable of accepting a connection and read messages but it will
evolve into a router in multiple stages. The first usage will
be by the sysmobts-mgr. An OML Error Indication will be sent by
the sysmobts-mgr and it will be forwarded to the BSC. In the
second step we will set a relative power reduction from the
sysmobts-mgr.
In the long-term this code will be used to communicate with a
second TRX.
We need to patch the CMR due wanting to support systems that still
have Audiocodes hardware in their chain. I have manually tested
and could listen to my own voice on:
TCH/H & AMR 5.9 & PTSN & BSC
TCH/F & FR1 & Other subscriber & NITB
TCH/F & EFR & Other subscriber & NITB
TCH/H & HR1 & Other subscriber & NITB
TCH/H & AMR 5.9 & Other subscriber & NITB
The tests were done using the Nokia E71, a Blackberry curve and
for the PTSN a HTC 8S were used.
For systems with a bigger PA enabling the full output power at
once might draw more current than a power supply can provide. This
code will step up the output power in smaller steps to avoid this
situation.
The sysmoBTS2050 does not have a OCXO and we should not rely
on the GPS module to always have a fix. Instead use the TCXO
by default and from time to time (and we know we have a fix
calibrate the TCXO). This can be done by:
trx 0 rf-clock-info reset
wait...
trx 0 rf-clock-info correct
write
The output is currently only written to the log as the VTY
connection might go away during the operation. The reset will
set the approriate reference clock and the correct will attempt
to determine and apply the correction. The write terminal will
make sure that next on start a known good value will be used.
For LCR and other systems without out-of-band information we need
to indicate the CMR. Not every air message will include the mode
and we sent a stream that had the CMR set and not-set. This lead
to the AudioCodes MGW only playing every second frame.
Remember the last used mode and initialize it to _NONE when we
receive the multirate config. In case of a real error we will
still use AMR_CMR_NONE.
The initial patch is from Harald. I have added the initialization
and moving of the defines to amr.h.
Manually verified by enabling AMR5.9 and looking at two RTP
packages in sequence. In both cases the CMR was 2. I have looked
at "amr.nb.cmr != 2" in wireshark and only found the MGCP dummy
packet.
The code should only run for the sysmoBTS 2050 and TRX 0.
If the device is not marked as 2050 the code would attempt
to open /dev/ttyS0 and block forever.
Harald is right and that the code is generally not ready
for inclusion. I fell victim of trying to finish it while
the code is not ready at all. It is better to re-introduce
the patches in a smaller and more tested way.
The right way would have been a branch were ready things
are split-off the main/wip commit until everything is ready.
Revert "sysmobts: Have a common prefix for the enum"
This reverts commit 44980347f3.
Revert "utils: Used the enum manuf_type_id in the parameter of add_manufacturer_id_label"
This reverts commit 7d36e5ed46.
Revert "utils: Classify the OML message using the return type"
This reverts commit afee0b7929.
Revert "sysmobts: Do not access out of bound string"
This reverts commit f5f41e8051.
Revert "sysmobts: Separate IPA and OML check into two methods"
This reverts commit 13a224063d.
Revert "screenrc: osmobts-mgr now needs a config file"
This reverts commit 0a1699ff8a.
Revert "make sure osmobts-mgr.cfg file is included in tarballs"
This reverts commit 14c60b425f.
Revert "sysmobts-mgr: Add VTY support for configuring it"
This reverts commit c5fedd24c9.
Revert "sysmobts: Add beginnings of an OML router and create Failure Messages in the sysmobts-manager"
This reverts commit c6ab90b270.
Limit the range from 0 to (_MAX_SYSINFO_TYPE - 1) instead of
0 to 31. This way we will never access the lchan->si.buf[] out
of bounds. This is only a theoretical issue though as the code
filling the lchan->si.buf for the SACCH will not have valid
>= _MAX_SYSINFO_TYPE. Add a small regression test to check we
still schedule all SIs.
Fixes: CID 1040765
Classify the OML message and return the manufacturer type
or an error. Currently ETSI, ip.access and Osmocom are known.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
I have split the function check_oml_msg, in two functions. One for
checking if the ipa header is well-formed and in check_oml_msg,
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Enable the previously commented-out logic to set the CMR (Codec Mode
Request) in AMR RTP frames based on the CMI (CMR Index) of the AMR
speech frame on the Um interface.
This is of course anyway the right thing to do, but also required for an
AMR receiver which doesn't have out-of-band information on the codec
mode, and which also doesn't determine the AMR codec mode based on the
size of the AMR frame (such as lcr as of current master).
We also move the entire CMR generation into the #ifdef section
which is only compiled-in if we do _not_ use the RTP mode of L1.
Make the sysmobts-mgr send a manufacturer O&M message with the power
reduction we want the sysmobts to apply. The sysmobts will handle
this message and set the new tx output power. An ACK/NACK will be
send as a response to the power reduction.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
This patch allows to configure the warning temperature threshold,
the severe temperature threshold of the board and the PA and the
actions like the relative value power that we want to reduce the
transmit power to and the part that we want to switch off or not.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Make the sysmobts listen for OML messages on a Unix Domain Socket.
Messages passing a sanity check will be forwarded to the BSC.
In case the sysmobts-mgr detects a temperature above or below
temperature threshold an OML failure message will be sent
to the BTS.
[moved confinfo into the #ifdef BUILD_SBTS2050]
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Initialize the libosmo-abis VTY nodes more early so we can parse
the config file that was created by "write". Introduce abis_init
to initialize the libosmo-abis and modify abis_open to re-use an
existing line. Update the comments. This has only been tried with
the sysmobts-remote on x86. A TCP connection is opened toward the
configured BSC.
Fixes: SYS#285
Include utils.h to have a declaration of sysmobts_get_nominal_power,
l1_if.c: In function 'l1if_activate_rf':
l1_if.c:1144:6: warning: implicit declaration of function
'sysmobts_get_nominal_power' [-Wimplicit-function-declaration]
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Fix a brown paper bag bug and call the right method. The above was
an infinite recursion. The stack didn't overflow as the compiler
optimized the tail-recursion and coverity didn't complain either.
The issue was introduced in the last minutes before the merge
when I renamed "reset_handover" to "handover_reset" to follow
the object_verb approach throughout the handover.c code. While
doing that I sadly replaced reset_handover with handover_frame
and not handover_reset.
Currently ADM state change request that tries to set the
administrative state to the current value are immediately ACK'ed.
Beside the caching problem, this could lead the protocol
inconsistencies if two such requests are sent one after the other and
the second arrives before the procedure of the first has finished.
This patch removes the shortcut in oml_rx_chg_adm_state() which
immediately called oml_mo_statechg_ack(mo).
Ticket: OW#1132
Sponsored-by: On-Waves ehf
The dequeue code assumed that msg->l3h is a valid pointer but in
the case of the PCU socket it was a null pointer. This lead to
memcpy copying a lot more than 23 bytes which ultimately lead to
a crash. The issue was introduced in the git commits
37c332e5bf and the commit
d290ee029a.
use msg->l3h = msgb_put(msg, len) to make sure that there is a
valid L3 pointer for the message.
(gdb) bt
#0 0x419d6384 in memcpy () from /tmp/ow/lib/libc.so.6
#1 0x0001894c in bts_ccch_copy_msg (bts=0x62248, out_buf=0x62248 "p\025\003", gt=0x1,
is_ag_res=100684) at bts.c:572
#2 0x0000c958 in handle_ph_readytosend_ind (rts_ind=<optimized out>, fl1=0x62e78)
at l1_if.c:515
#3 l1if_handle_ind (fl1=0x62e78, msg=0x8bb08) at l1_if.c:920
#4 0x000147e8 in read_dispatch_one (queue=<optimized out>, msg=0x8bb08, fl1h=<optimized out>)
at l1_transp_hw.c:190
#5 l1if_fd_cb (ofd=0x62f04, what=<optimized out>) at l1_transp_hw.c:224
#6 0x41b9d028 in osmo_select_main (polling=<optimized out>) at select.c:158
#7 0x0000b204 in main (argc=<optimized out>, argv=<optimized out>) at main.c:384
(gdb) p *msg
$12 = {list = {next = 0x100100, prev = 0x200200}, {dst = 0x0, trx = 0x0}, lchan = 0x0,
l1h = 0x0, l2h = 0x0, l3h = 0x0, l4h = 0x0, cb = {0, 0, 0, 0, 0}, data_len = 23, len = 23,
head = 0x8572c "-\006?\020\r\340*q\224#", tail = 0x85743 "",
data = 0x8572c "-\006?\020\r\340*q\224#", _data = 0x8572c "-\006?\020\r\340*q\224#"}
In case the max power reduction has been changed through OML,
let us call the l1if_set_txpower routine to update the nominal
power. This has been manually verified with both BTS #1 and #57.
./bsc_control.py -d localhost -p 4249 -s bts.0.trx.0.max-power-reduction 0
The above command and GNUradio have been used to determine if
the power level has changed at all.
Fixes: SYS#268
These routines do not pass the gsm_abis_mo and parsing the FOM
header of the msg does not seem to be a good idea either. Pass
in the OML object so that the model code can determine what the
void pointer is.
Older hardware didn't have the external attentuator that was used
to control the wanted output power. So starting from the git commit
3c8ff3c70b older hardware was always
transmitting with 23 dBm regardless of the power reduction.
Remember the hardware revision returned by the SystemInformation
primitive, postpone the call to l1if_activate_rf until we know
the board revision.
Manually verified on BTS #1 and #57. On BTS#1 the external
attenuator has not been configured and on BTS#57 it was.
The DSP/FPGA appears to report bogus PhDataInd with hlayer2 == 0.
Currently this would match the TRX==0,TS==0 and SS=0 and then we
report bad measurement reports. Add a magic number to the lower
eight bit of the hLayer2 to differentiate valid numbers.
Addresses:
<0004> measurement.c:97 (bts=0,trx=0,ts=0,ss=0) measurement during state: NONE
<0004> measurement.c:102 (bts=0,trx=0,ts=0,ss=0) no space for uplink measurement
I have extended the principal function that we use for requesting
information to the microcontroller for switching off/on the board
and the PA. And I have extended it for requesting the power status
information of the board and the PA.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Add function for requesting the temperature information to the
microcontroller. I have added a function that we can extend
for requesting more information but in this case we only need to
know the temperature.
I have added to a microcontroller temperature handling function
in the manager for monitoring this information.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Currently a locked cell is actively broadcasting when it is being
bootstrapped after the lock.
This patch adds an initial update of the RF mute state when the TRX
is initialized.
Ticket: OW#1131
Sponsored-by: On-Waves ehf
When the lchan was activated for handover configure it to wait
for a RACH burst. On release make sure to always release the
RACH SAPI (in case it has been allocated). On the first frame
inform handover.c about it and forward the received access burst
to the handover layer.
Using an E71 it was possible to make a handover for SDCCH and
TCH/F from a nanoBTS but also from itself to itself. The vty
commands of OpenBSC and the silent-call have been used for that.
I didn't verify audio handling so far.
The BTS layer needs to inform the handover code when an access
burst has been received. In turn the handover layer will ask the
bts to modify the channel, it will schedule the physical information
inform the BSC with the HANDOVER DETECTION and waits for the BTS
layer to inform it about the first received frame to stop a timer.
This patch implements merging of IMMEDIATE ASSIGN REJECT messages as
suggested in GSM 08.58, 5.7. When a new IMM.ASS.REJ is to be appended
to the AGCH queue and the last message in that queue is of the same
type, the individual entries (up to 4 per message) of both messages
are extracted, combined and stored back. If there are less than 5
entries, all entries fit into the old message and the new one is
discarded. Otherwise, the old message will contain 4 entries and the
remaining ones are stored into the new one which is then appended to
the queue.
Ticket: SYS#224
Sponsored-by: On-Waves ehf
This patch adds the following VTY commands to tune AGCH queue
handling:
agch-queue-management default
agch-queue-management threshold THRES low LOW high HIGH
Examples:
agch-queue-management default
Resets queue management to default parameters.
agch-queue-management threshold 0 low 25 high 75
Start dropping at 25%, drop all messages above 75% queue length
(relative to max queue length corresponding to T3126). Between
low and high, drop with a probability interpolated linearly
between 0 (low) and 1 (high).
agch-queue-management threshold 50 low 0 high 0
Start dropping at 50% and continue until all IMM.ASS.REJ have
been removed from the front (output) of the queue
Sponsored-by: On-Waves ehf
Currently, the AGCH queue length is not limited. This can lead to
large delays and network malfunction if there are many IMM.ASS.REJ
messages.
This patch adds two features:
- Don't accept msgs from the RSL layer when the queue is way too
full (safety measure, mainly if bts_ccch_copy_msg() is not being
called by the L1 layer, currently hard coded to 1000 messages)
- Selectively drop IMM.ASS.REJ from the queue output depending on the
queue length
Ticket: SYS#224
Sponsored-by: On-Waves ehf
This patch extends paging_gen_msg() by adding an output parameter
is_empty that is true, if only a paging message with dummy entries
has been placed into buffer. This feature is then used by
bts_ccch_copy_msg() to insert an AGCH message if is_empty is true.
Ticket: SYS#224
Sponsored-by: On-Waves ehf
Counters are added for the following events (use VTY show to query):
- Dropped IMMEDIATE ASSIGN REJECT messages
- Merged IMMEDIATE ASSIGN REJECT messages
- Rejected AGCH messages
- Use of PCH (non-reserved) for AGCH messages
- Use of AGCH (reserved) for AGCH messages
Sponsored-by: On-Waves ehf
This patch adds a function bts_update_agch_max_queue_length()
to compute a limit of the AGCH queue. This is based on the idea,
that the AGCH queue has a limited drain rate and that CHANNEL
REQUESTs must be answered within a certain time frame, given
by the minimum value of T3126 (see GSM 04.08). When the AGCH queue
reaches that limit, the last message would be delivered in time if
there were no other delays involved (which is not the case).
The calculation is based on the ratio of the number RACH slots and
CCCH blocks per time:
Lmax = (T + 2*S) / R_RACH * R_CCCH
where
T3126_min = (T + 2*S) / R_RACH
R_RACH is the RACH slot rate (e.g. RACHs per multiframe)
R_CCCH is the CCCH block rate (same time base like R_RACH)
The value depends control_channel_desc.ccch_conf and
rach_control.tx_integer (both from SYSINFO_TYPE_3) and should
therefore by called at least each time after one of these is changed.
For this reason, a signal callback is registered under
SS_GLOBAL/S_NEW_SYSINFO which invokes bts_update_agch_max_queue_length().
Sponsored-by: On-Waves ehf
Based-On: "bts: Calculate length of agch queue" by Ivan Kluchnikov
<kluchnikovi@gmail.com>
Before, this patch the program tried to read the info
of the temperature sensor from a wrong location.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
This could lead to a BSC attempting to release the BCCH or a
PDCH. In the case of the BCCH this lead to a funny crash.
Log:
<0000> rsl.c:605 (bts=0,trx=0,ts=0,ss=4) Sending Connection Failure: cause = 0x01
<0000> rsl.c:1720 (bts=0,trx=0,ts=0,ss=0) Rx RSL DEACTIVATE_SACCH
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
msgb_dequeue (queue=0x4007d2d8) at msgb.c:102
102 llist_del(lh);
(gdb) bt
#0 msgb_dequeue (queue=0x4007d2d8) at msgb.c:102
#1 0x4002ed28 in lapd_dl_flush_tx (dl=0x4007d220) at lapd_core.c:173
#2 0x40030cb4 in lapd_dl_reset (dl=0x4007d220) at lapd_core.c:307
#3 0x40030d00 in lapd_dl_exit (dl=0x4007d220) at lapd_core.c:321
#4 0x40033d80 in lapdm_entity_exit (le=<optimized out>) at lapdm.c:169
#5 0x40033d9c in lapdm_channel_exit (lc=0x4007d214) at lapdm.c:180
#6 0x0001a334 in rsl_tx_rf_rel_ack (lchan=0x4007d180) at rsl.c:505
#7 0x0000e908 in lchan_deactivate_sapis (lchan=0x4007d180) at oml.c:1427
#8 sapi_queue_exeute (lchan=0x4007d180) at oml.c:547
#9 0x0000ead0 in sapi_queue_send (lchan=<optimized out>) at oml.c:571
#10 queue_sapi_command (lchan=<optimized out>, cmd=<optimized out>)
at oml.c:609
#11 queue_sapi_command (lchan=0x4007d180, cmd=<optimized out>) at oml.c:601
#12 0x0000faf0 in enqueue_rel_marker (lchan=0x4007d180) at oml.c:1440
#13 lchan_deactivate (lchan=0x4007d180) at oml.c:1447
#14 0x0001004c in bts_model_rsl_chan_rel (lchan=<optimized out>) at oml.c:1647
#15 0x0001b948 in rsl_rx_rf_chan_rel (lchan=0x4007d180) at rsl.c:844
#16 rsl_rx_dchan (msg=0x75a88, trx=0x4007b038) at rsl.c:1727
#17 down_rsl (trx=0x4007b038, msg=0x75a88) at rsl.c:1853
#18 0x000154d4 in sign_link_cb (msg=<optimized out>) at abis.c:132
#19 0x400701c0 in ?? () from /usr/lib/libosmoabis.so.2
#20 0x400701c0 in ?? () from /usr/lib/libosmoabis.so.2
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Fixes: OW#1133
When closing the PCU socket all channels will be closed. In that case
the LAPDm structures might not have been allocated. Mark the channel
as LCHAN_REL_ACT_PCU to avoid going through the RSL code for sending
the message. This avoids a crash when "gprs none" is selected but one
still configures a PDCH and then connects/disconnects the pcu.
#0 llist_del (entry=0x0) at ../include/osmocom/core/linuxlist.h:119
#1 msgb_dequeue (queue=0x400bbc58) at msgb.c:102
#2 0x40110d28 in lapd_dl_flush_tx (dl=0x400bbba0) at lapd_core.c:173
#3 0x40112cb4 in lapd_dl_reset (dl=0x400bbba0) at lapd_core.c:307
#4 0x40112d00 in lapd_dl_exit (dl=0x400bbba0) at lapd_core.c:321
#5 0x40115d80 in lapdm_entity_exit (le=<optimized out>) at lapdm.c:169
#6 0x40115d9c in lapdm_channel_exit (lc=0x400bbb94) at lapdm.c:180
#7 0x0001a334 in rsl_tx_rf_rel_ack (lchan=0x400bbb00) at rsl.c:505
#8 0x0000e908 in lchan_deactivate_sapis (lchan=0x400bbb00) at oml.c:1427
#9 sapi_queue_exeute (lchan=0x400bbb00) at oml.c:547
#10 0x0000ead0 in sapi_queue_send (lchan=<optimized out>) at oml.c:571
#11 queue_sapi_command (lchan=<optimized out>, cmd=<optimized out>) at oml.c:609
#12 queue_sapi_command (lchan=0x400bbb00, cmd=<optimized out>) at oml.c:601
#13 0x0000faf0 in enqueue_rel_marker (lchan=0x400bbb00) at oml.c:1440
#14 lchan_deactivate (lchan=0x400bbb00) at oml.c:1447
#15 0x0001004c in bts_model_rsl_chan_rel (lchan=<optimized out>) at oml.c:1647
#16 0x0001de30 in pcu_sock_close (state=0x62788) at pcu_sock.c:654
#17 0x0001e150 in pcu_sock_read (bfd=0x627a8) at pcu_sock.c:698
#18 pcu_sock_cb (bfd=0x627a8, flags=1) at pcu_sock.c:755
Currently, the DSP is always configured with u8NbrOfAgch = 1 before
SYSINFO type 3 is received. Thus using a different value for
BS_AG_BLKS_RES may lead to inconsistencies and MS failing to receive
paging messages properly.
This patch adds a warning and error logging and should be reverted
when initialisation is done in proper order.
Sponsored-by: On-Waves ehf
This patch adds a common function bts_ccch_copy_msg() that provides
and schedules AGCH and PCH messages. It is basically a frontend to
paging_gen_msg() and bts_agch_dequeue() and contains refactored code
from l1_if.c.
Sponsored-by: On-Waves ehf
Currently, the msg->data pointer is just set to the IMMEDIATE ASSIGN
message and the len is adjusted accordingly. Unfortunately, this
leaves l2h (pointing to the RSL header) and l3h (pointing to the
FULL_IMM_ASS_INFO IE) in an undefined state (outside of [data, tail]).
The code in bts.c accesses the message via msg->data.
This patch sets l3h and l2h correctly. msgb_l3() will point to the
start of the IMM ASS message and should be used instead of msg->data.
Sponsored-by: On-Waves ehf
This patch removes the local 'end' and 'exit' implementations (which
aren't used anyway) and uses the generic ones provided by libosmocore
instead, which are enabled automatically when vty_install_default()
is used.
The prompt strings are modified to match those in
libosmocore/openbsc.
Ticket: OW#952
Sponsored-by: On-Waves ehf
Use 0x52 as error cause as the nanoBTS is doing the same under the
situation. This has been spotted while testing handover using the
VTY command for handover.
Today we had the problem that multiple l1fwd-proxy instances ran
at the same time and not everything working all the time (some
packets were sent to a different host).
Another approach is to use flock on the message queues. This appears
to work fine as well.
Write the requested timing advance into the header. We are currently
using the u8AutoTA mode so the value will be overwritten by the DSP
before the bursts are sent to the MS.
When a frame is sent on the SACCH the LAPDm code will already
prepend two bytes for the tx_power and the ta. In the BTS we want
to use the values that were set by the BSC though. They currently
come from the RSL CHAN ACT but could also be set through the
RSL MS power control command. Update the comment as the space is
not empty.
At the 30C3 we had a NITB crash because of a RLL timeout on a
TCH/F. Jacob analyzed the problem and tracked it down to the
mismatch of LAPDm and the l1 interface to the DSP.
The sysmoBTS L1 has the TSC as a global value, we cannot have individual
per-timestamp or even per-lchan TSC, as the GSM specification would
suggest (and other BTSs support).
Rather than fail silently, write an error message to the log and
return NM_NACK_PARAM_RANGE or RSL_ERR_SERV_OPT_UNIMPL back to the BSC.
If the channel couldn't be activated, the function can simply return
a negated RSL_ERR_* constant which will then be propagated towards
the BSC in an CHAN_ACT_NACK RSL message.
This way, bts_model_check_oml() can return a negated NM_NACK_* constant
which will then be sent as cause value in the corresponding
SET_ATTR_NACK back to the BSC.
In the MPH ACTIVATE-RF.req, we need to specify the nominal maximum
transmit power, i.e. >= what we later request during MPH-INIT.req.
This field was first introduced in API version 2.2, but we never used
it so far. It may help fixing a bug related to excessive power
consumption of the sysmoBTS 2050.
Bind to port 3006 and listen to incoming IPA requests. Currently
we unconditionally respond with the MAC and IP Address of the unit.
To determine the IP Address the kernel is asked for thesource
address of the route for the destination. In contrast to a nanoBTS
we will reply to the port the initial request came from.
The sysmoBTS takes quite a bit of CPU time for the vfprintf that
is used by osmo_hexdump. Do not dump every single frame to improve
the performance a bit.
In the perf the ARM EABI ddiv operation showed up in the most
of expensive symbols. It doesn't really make much sense as the
calls should only be done on configuration.
Most timeslots do not have eight lchan. Use the subslots_per_lchan
map to reduce the number of iterations. Looking at the ARM assembly
showed that no loop-unrolling was done so this could be a speed up.
calib_file.c: In function 'next_calib_file_idx':
calib_file.c:126:3: warning: implicit declaration of function 'band_femto2osmo' [-Wimplicit-function-declaration]
Release/Free the lapdm resources _after_ the channel has
been fully released. Do not forward data unless the lchan
is in the active state.
Reading this code again, there is probably a memory leak for
everytime the PCU will re-connect to the BTS.
(gdb) p lchan->state
$4 = LCHAN_S_REL_REQ
(gdb) bt
#0 lapd_dl_flush_hist (dl=0x40454894) at lapd_core.c:164
#1 0x44873b54 in lapd_rx_u (lctx=0xbe9bd5a8, msg=0x92f90) at lapd_core.c:1040
#2 lapd_ph_data_ind (msg=0x92f90, lctx=0xbe9bd5a8) at lapd_core.c:1644
#3 0x44876d50 in l2_ph_data_ind (link_id=<optimized out>, chan_nr=<optimized out>,
le=<optimized out>, msg=0x92f90) at lapdm.c:637
#4 lapdm_phsap_up (oph=<optimized out>, le=<optimized out>) at lapdm.c:707
#5 0x0000c504 in handle_ph_data_ind (l1p_msg=0x97358, data_ind=0x97420, fl1=<optimized out>)
at l1_if.c:774
#6 l1if_handle_ind (fl1=<optimized out>, msg=0x97358) at l1_if.c:892
Use the lchan->rel_act_kind field for the BCCH activatiob by OML.
The lchan's should be marked as active but no event should be sent to
the BSC. This is mostly like the PCU. We can now remove the secnd
argument from lchan_activate.
There are existing deployments where the EEPROM either contains a
wrong value and/or the kernel can not be updated to support the
different EEPROM of revD. Revert to the old behavior that if no
nominal can be derived from the model_nr we assume that it is 23.
Nicolas ended up with linker issues due abis_rsl_sendmsg being
defined twice. Rename our version of the function and update the
code.
Patched with:
@i@
expression E;
@@
- abis_rsl_sendmsg(E)
+ abis_bts_rsl_sendmsg(E)
Currently it takes some time (around 30s) until it is detected that
the radio link is down after mute. Not till then the BSC is informed
and the call terminated.
This patch modifies this behaviour by sending a RSL_MT_CONN_FAIL
message with cause RSL_ERR_RADIO_LINK_FAIL for each muted and active
lchan immediately after the corresponding Change Administrative State
Request has been acknowledged.
Ticket: OW#976
Sponsored-by: On-Waves ehf
Currently only mute_state[0] (refers to ts[0]) is inspected to
determine, whether the Radio Carrier's state is set to LOCK.
This patch changes this by looking at all channels and using LOCK
if (and only if) all channels have been muted successfully.
Sponsored-by: On-Waves ehf
Currently the LEDs are being accessed directly from within the
l1_if.c file. So the handling of rf mute and activate/deactivate both
access LED_RF_ACTIVE directly. This may lead to an inconsistent LED
status.
This patch replaces these calls to sysmobts_led_set() by an abstract
equivalent bts_update_status(), that uses a set of independant status
ids. The associated values can than be combined into a visible LED
status. Currently LED_RF_ACTIVE is on iff BTS_STATUS_RF_ACTIVE is set
and BTS_STATUS_RF_MUTE is not set.
Sponsored-by: On-Waves ehf
Currently a Change Administrative State Request is just applied
unconditionally to the object's state object and then acknowledged.
This patch implements the special handling of setting the Radio
Carriers state to LOCK or UNLOCK. This is done by passing the
appropriate mute command to the L1 layer. Always all radio channels
are affected, it is not possible to lock single radio channels.
On success, an ACK is sent back to the bsc with the new state (based
on the state passed in the callback by the L1 layer). If something
went wrong or the firmware doesn't support RF mute, a NACK
(REQ_NOT_GRANTED) is sent instead.
Note that a NACK for such a request hasn't been sent by the BTS to
the BSC yet, so (albeit it's spec conformant to do so) the BSC must
be prepared to handle this correctly.
Ticket: OW#976
Sponsored-by: On-Waves ehf
This adds a new function
l1if_mute_rf(femtol1_hdl, ch_mute[8])
to set the mute state for each radio channel. On completion and iff
l1if_mute_rf() returned 0 the callback
oml_mo_rf_lock_chg(mo, ch_mute_state[8], success)
is invoked when the response from the superfemto DSP is received.
Ticket: OW#976
Sponsored-by: On-Waves ehf
This add the mappings for SuperFemto_PrimId_MuteRfReq and
SuperFemto_PrimId_MuteRfCnf to the arrays femtobts_sysprim_type,
femtobts_sysprim_names, and femtobts_sysprim_req2conf.
Sponsored-by: On-Waves ehf
Currently uninitialized elements of the femtobts_sysprim_type array
are mistaken as L1P_T_REQ (which is accidently the first element and
thus 0).
This patch adds a new element to the enum that has the value 0 to
detect uninitialized elements of the femtobts_sysprim_type array.
Those will then show up in the log as 'SYS Prim XXX is not a
Request!'.
This patch also adds missing definitions of the CalibTbl messages
in the femtobts_sysprim_type mapping so that the requests can still
be identified as such.
Sponsored-by: On-Waves ehf
The PCU is forcing the activation of a PDCH. Currently the BSC
will receive a channel act ack for a channel that was not
activated at all. Use the "release_reason" flag of the lchan
to see if we have requested a normal activation or a silent
one.
It feels a bit odd to do it in the TX function but it is the
most easy solution right now. I have added logging so it will
not be totally silent.
This is used in the sysmoBTS 2050, where the maximum power is 40 dBm
We might want to add a safeguard of some kind to prevent people from
overdriving their transmitters.
The TRX nominal output power (as seen by OML) is the aggregate power
of any gain internal to the sysmoBTS (and managed by L1) and any
external PA. This is what is used in trx->nominal_power;
fl1h->l1_power is the transmit power to which we configure the sysmoBTS
L1. This is 23 dBm (200mW) by default in the sysmoBTS 1002, and 40 dBm
(5W) in the sysmoBTS 2050. However, if sysmoBTS 2050 is used in
single-TRX configuration, it may be used with higher power, which we can
now configure in the config file / vty.
TODO: A separate, additional field that keeps track of any gain added by
an external PA, e.g. if the sysmoBTS 1002 is used with a sysmoAMP.
If the clock is provided by an external (like GPS) clock, we should not
use the calibration value. The latter is only used in context of the
OCXO or VCTCXO.
If the EEPROM tells us that a given unit doesn't support a given band,
we shouldn't try to use it, even if the BSC tells us to use an ARFCN in
such an unsupported band.
The reason is simple: The given BTS unit might have band specific
filter / duplexer / PA.
This introduces a new get_signlink_remote_ip() function whcih we also
use in the RSL code to determine the RTP remote address if the CRCX/MDCX
contains no remote IP address IE.
libosmoabis has a BTS-side implementation of the IPA protocol for years,
and osmo-bts should have used that all the time. Unfortunately it had
its own local hack, this patch is migrating to the libosmocore
implementation.
By default read the clock calibration from the EEPROM. It is
still possible to set it using the cli.
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
Coverity wants us to check that fscanf has scanned the amount of
variables we want to have. Initialize the scan result to 0/0.0f
and warn if the scan has failed.
Fixes: Coverity CID 1040774, CID 1040773
Coverity insists that we should check the return value of the
calls to fseek. In general this is a good idea.
Fixes: Coverity CID 1040770, CID 1040771, CID 1040772
Calling eeprom_write would either re-use g_file or newly open the
file and set g_file but it will close the file as well. This will
lead to other code using fseek/fread on a closed file.
On top of that the general rule for the eeprom code now is that
read and write may not be mixed (due caching and other bits).
The issue got introduced in fcdba6bfac
when moving from the uint32_t pointer to a plain int. The code
was now like this:
if (connect_ip > 0) {
if (connect_ip == 0)
lookup_ip_based_on_rsl
...
Coverity detected this as logically dead code and it was breaking
audio handling for the osmo-bsc case. Remove the tristate handling,
the RSL behavior is that leaving out port/ip is like specifying it
as zero.
Fixes: Coverity CID 1040769
The array has three elements but check was for > _NUM_TEMP_TYPES (3)
so an access at array[3] was possible. It is unlikely to have
happened due the usage of enums. Use ARRAY_SIZE and >= on the real
array to avoid this problem.
Fixes: Coverity CID 1040760
The current code has 26 fseek/fread. Only the minority really results
in a call to read. Nevertheless the time for reading during the bootstrap
can take up to 7.82 seconds. Caching the header (which is already done
by fopen/fread) will result in one call to fseek/fread and only
consumes 0.784 seconds.
Commit 5643130664 by Daniel changed
the ciphering to go through the command queue. In this commit the
direction for the ciphering got turned around and was not spotted
by review. It worked in testing due the usage of A5/0 and in that
case the direction did not matter.
sysmobts_vty.c: In function 'activate_lchan':
sysmobts_vty.c:373:3: warning: implicit declaration of function 'lchan_activate' [-Wimplicit-function-declaration]
sysmobts_vty.c:375:3: warning: implicit declaration of function 'lchan_deactivate' [-Wimplicit-function-declaration]
eeprom.c: In function 'eeprom_ReadEthAddr':
eeprom.c:305:5: warning: pointer targets in passing argument 3 of 'eeprom_read' differ in signedness [-Wpointer-sign]
eeprom.c:260:12: note: expected 'char *' but argument is of type 'uint8_t *'
Instead of calling oml_mo_state_chg() [which transmits OML STATE CHG]
during bts_init(), we use a new oml_mo_state_init() function which
simply sets the state.
This should fix:
calib_file.c: In function 'calib_eeprom_read':
calib_file.c:262: error: 'SuperFemto_SetRxCalibTblReq_t' undeclared (first use in this function)
calib_file.c:262: error: (Each undeclared identifier is reported only once
calib_file.c:262: error: for each function it appears in.)
This should fix:
calib_file.c: In function 'calib_fixup_rx':
calib_file.c:148: error: 'SuperFemto_SetRxCalibTblReq_t' undeclared (first use in this function)
calib_file.c:148: error: (Each undeclared identifier is reported only once
During development one switches from GSM900 to GSM1800 and GSM850 to
GSM1900. This commit attempts to make this switch more easy.
GSM1800 and GSM1900 have overlapping ARFCNs. This means that the
mapping from bands to arfcn is not injective. Because of that I
removed the code to deduce the band from the ARFCN. This was done
in commit 8c3d807b3f. The auto-band
option allows to move between GSM900/GSM1800 and GSM850/GSM1900.
Add a simple testcase with these auto-band configurations.
In case there is no transmitter the S counter might never be decreased.
This means that no radio link timeout will not be sent and the lchan will
remain open forever. There are several ways to resolve this.
The first would be to use the MphTimeInd and after each multiframe check
if there has been a SACCH message for the open lchan's. This could be
similar to the trx_meas_check_compute.
I decided to change fBFILevel to always receive SACCH frames and move
the code down to the PDTCH/PACCH handling and update the comment.
In most cases there are multiple messages ready to be read from
the queue and it is more efficient to read them in one go instead
of going through the select again.
Attempt to write multiple primitives at the same time instead of
the select/write, select/write that is currently done. The queue
size is big enough to hold several entries at the same time and it
is unlikely we get the -EAGAIN from the kernel driver.
The writev code works by assuming that each element in the queue
has the same size. This is not verified by the code and if this
assumption breaks at some point the code will drop primitives or
send some twice.
Make sure the l1msg is always freed in the callback. There were
several error conditions were the msgb would not have been freed,
in the case of the calib data and the system information the message
was not freed even in normal condition.
I will modify this code to __use a msgb. This allows to re-use
the allocated msgb across read operations.
The lapdm/lapd_core code needs to keep a history of messages sent.
This history is not freed when lapdm_channel_reset is called and
the init code will just allocate a new array. This means there is
a memory leak on every released channel every time it is released.
On v2D (and later) hardware, the calibration data can be read directly
from the EEPROM and doesn't have to be read from files.
If there is no trx-calib-path set in the VTY, we will read from EEPROM.
When not specifying a config path, then saving the running config
it would end up as "(null)" and then leads to an error like this:
<0006> calib_file.c:147 Failed to open '(null)/calib_rxu_850.cfg' for calibration data.
Add a NULL check to avoid this issue when writing the config file.
the armv5 can do 32bit/16bit reads only from the aligned address
use tlv.h macro to copy data to local variable
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
When not reading quick enough from the queue we will get a bogus
response which will lead to marking the lchan as broken and to
clear the sapi queue. The sapi_queue_dispatch was checking if the
queue was empty before calling the callback but not taking into
account that it might have been flushed.
Stop processing if the queue was empty before calling the callback
or if it is empty after the callback.
Backtrace:
#0 0x4eb1f1cc in raise () from /lib/libc.so.6
#1 0x4eb22f48 in abort () from /lib/libc.so.6
#2 0x4ecc2cb8 in talloc_abort (reason=<optimized out>) at talloc.c:167
#3 0x4ecbc854 in talloc_abort_unknown_value () at talloc.c:180
#4 0x4ecc6bc8 in talloc_chunk_from_ptr (ptr=0x4ec2d494) at talloc.c:192
#5 _talloc_free (ptr=0x4ec2d494) at talloc.c:517
#6 talloc_free (ptr=0x4ec2d494) at talloc.c:990
#7 0x0000f294 in sapi_queue_exeute (lchan=0x402414a0) at oml.c:528
#8 0x0000f2d4 in sapi_queue_send (lchan=0x402414a0) at oml.c:542
#9 0x0000f3e0 in sapi_queue_dispatch (lchan=0x402414a0, status=-4) at oml.c:565
#10 0x000114d0 in lchan_deact_compl_cb (trx=0x4021e038, l1_msg=0x7e690) at oml.c:1269
#11 0x0000d70c in l1if_handle_l1prim (wq=1, fl1h=0x607c8, msg=0x7e690) at l1_if.c:938
The latency to respond to a PH-READY_TO_SEND.ind may not be higher
than 18ms. Currently we are using nice to increase our priority but
for a heavily loaded cell this is not enough. Add an option to enable
realtime scheduling and use it in the screenrc.
Linux offers two realtime scheduling classes these are SCHED_FIFO
and SCHED_RR. For SCHED_FIFO the process is running as long as possible
(potentially taking all the CPU and never yielding it), for SCHED_RR
the process can still be pre-empted at the end of the timeslice.
Using SCHED_RR appears to be the more safe option as a run-a-way
sysmobts process will not be able to take all the CPU time.
For a very loaded cell we also require to use readv/writev to allow
writing multiple primitives in one syscall.
Currently msgb_free is calling talloc_free but we might introduce
a msgb pool in the future. So make sure to use the designated free
method for the msgb.
On some system (e.g. ubuntu) libosmovty must precede libosmocore
otherwise we get undefined reference errors while linking.
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
In case the channel is not active we can omit the external requests
to modify it. For the channel modification the higher level is already
acking it and for the ciphering it is probably too late to do anything.
There are three new commands. There are two markers and a deactivate
command. The markers are used to wait until all previous commands are
executed and then to decide if the SAPI needs to be released at all.
When asked to release the SACCH the marker will be queued, then on
execution of the marker the SACCH in Up-/Downlink will be released.
For the RF Channel Release we use another marker, when the marker is
executed we check all the SAPIs we want to release. It is possible that
the queue looks like this:
(SACCH_REL_MARKER is done) REL_MARKER, SACCH DEACT, SACCH DEACT
This could happen if a BSC sends SACCH Deactivate and RF Channel Release
at the same time. We deal with issue by changing the SAPI state to the
REL_REQ state and check_sapi_release will not ask for another release. So
after the execution the queue will look like this:
SACCH DEACT, FACCH DEACT, TCHF DEACT..
This code does not check that all allocated SAPIs are released. The
lchan_deactivate_sapis could be changed to go through all sapis_dl
and sapis_ul to fix that.
The normal flow should now be:
1.) lchan_deactivate
2.) Check if the queue is empty then go to 4
3.) REL_MARKER is executed and lchan_deactivate_sapis is called
4.) For all SAPIs to be released, check if they are allocated and
then schedule a CMD_DEACTIVATE. If there is an error remember
something went wrong but continue.
5.) Once all commands are executed send the channel release ack.
For the release markers we need to be careful as they might not schedule
any work. E.g. if the BSC sends two SACCH DEACTIVATE the second marker
will not generate any release requests and we should proceed with the
next command. Make sapi_queue_command return 1 in case the command has
been directly executed. So a queue like SACCH_REL_MARKER, LOGCH will
result in LOGCH, SACCH DEACT Rx, SACCH DEACT Tx but a 0 will be returned
and the sapi_queue_next will then call sapi_queue_exeute again.
NITB has been modified to trigger these corner cases more easily.
* Do not send IMM.ASSIGNMENT for some timeslots to go through the
error path
* Issue multile SACCH deactivates in the normal release mode
* Send rsl_chan_mode_modify_req before the SACCH DEACT and also when
the RLL is being released.
Put all SAPI requests into a queue and handle them one after another.
Begin with the channel activation. Once the queue is empty the channel
activate will be sent. For the BCCH activation we do not want to send
a channel activation message and this is why we set the lchan->state
to NONE.
One change is that we do not attempt to call the ciphering routines on
the BCCH anymore.
This change is necessary to fix issues with LCHANs staying open and being
marked as broken by the BSC and will help in implementing handover support
as this requires a re-configuration of the lchan on the fly.
If the shutdown timer is already running do not deactivate the RF and
do not close the trx. This is addressing another instance of the following
warning:
[ERROR] : DeviceMng_ValidateL1Handle() => Invalid layer 1 handle
In case that the counter S reached 0, it will stay 0. Subsequent received
good and bad SACCH frames must not cause to trigger radio link failure
again. Once the BSC has been indicated about link failure, it will release
channel.
The counting of S has been moved to a seperate function.
This patch will ensure that the link failure is indicated only once. But
even if the link failure would be sent multiple times, the BSC should
ignore it. The BSC releases the channel and may only reuse it after confirm
from BTS. (There cannot be any link failure indications after confirm of
channel release.)
The allowed timeout value range is 4..64, as defined in TS 05.08, so if the
BSC sends an attribute with value out of range or other failure criterion,
the Set BTS Attributes message is NACKed.
Chapter 5.2 applies to MS procedure, but 5.3 (BSS procedure) defines no
exact criterion, so I decided to use the procedure equivalent to MS.
The criterion is based on a counter S, which is initialized to a preset
RADIO_LINK_TIMEOUT, which can be configured via VTY. Whenever a received
SACCH block is bad, S is counted down by one. If SACCH block is
successfully decoded, S is counted up by two, but never above initial
RADIO_LINK_TIMEOUT value. If S reaches 0, an RSL Connection Failure
Indication with cause RF Radio Link Failure is sent to BSC, which then
aborts channel.
Use link timeout value from BSC via OML attribute.
How to test:
- Set "debug" for "meas" logging.
- Start silent call to an attached mobile.
- Remove battery from mobile or shield mobile.
- Watch S count down.
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
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.
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
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.
Right now osmo-bts requires access to one OpenBSC header file and
this requires that openbsc and osmo-bts git are in the same directory.
Begin with making the location of the OpenBSC sourcecode configurable.
This approach will allow to build osmo-bts on our Jenkins installation
but now has the risk of more code including the openbsc/*.h header files.
This may be adding bells and whistles that nobody wants to touch, but at
least for current analysis/optimiziation they are useful to have. Later
on they should probably be removed again and/or obsoleted by OML
messages for configuration of paging behaviour by the BSC.
We used to have -75 dBm as the target value for the uplink receive
level. Now this is configurable.
The parameter is used as input into the power control loop that adjusts
the MS transmit power in order to achieve the target rx value on the
BTS Rx input.
For whatever reason, the order of fields in the L1 SACCH header is
different from 04.04 (Um) and 08.58 (A-bis). Please note that it's not
just a different bit order, but actually logically re-ordering the
fields within the byte, while keeping the bit-order/-endian.
We now correctly report the L1 transmit power up the stack.
'trx-calibration-path' is the new VTY command indicating the path
name where the calibration files can be found.
Calibration is only implemented for SUPERFEMTO API version 2.4.0 or
later.
Holger Hans Peter Freyther
Harald Welte
Alexander Huemer