To allow switching a dyn TS also between TCH/H <-> TCH/F and anything else,
don't thwart RSL messages just because their chan_nr doesn't reflect the
current pchan mode. For dyn TS, leave that to message handling.
In particular, a TS switch is invoked by a Chan Activ message, in which case
the current pchan by definition mismatches the incoming chan_nr's reflected
channel type.
With this patch, I have tested successful direct TCH/H<->TCH/F switchover on
sysmoBTS, with osmo-bsc patch I72d5d833b186b1e1925d513885b405d8c19aa496 (and
'msc'/'codec-list' vty config to change TCH kinds while gprs mode was none).
Change-Id: I19e5e509101ec91204de9baff04582d99bc8dcb8
This actually should have been working since 2015, when the following
patch was merged to libosmcore:
commit f8699ca51eeb4f3d34336501abcaf071b4a95a47
Author: Max <max.suraev@fairwaves.co>
Date: Wed Mar 25 17:20:31 2015 +0100
gsm: Add A5/3-4 cipher support
however, it seems nobody so far bothered to actually enable A5/3 for
osmo-bts-trx!
Change-Id: I8192d6d07cdb87783bce997456ead673c600f7c0
Closes: OS#3253
The existign code only sent an ERROR REPORT, but it failed to actually
send a proper NACK to the related request. This is confusing, as the
operation should always be ACKed or NACKed, and not simply result in no
response.
Change-Id: Ic374a8e5e239ffe37082a54cdb94cb6ac9723e83
Closes: OS#3254
Whenever we encounter an error condition during processing of RSL CHAN
ACT or RSL MODE MODIFY, it's insufficient to simply send an RSL ERROR
INDICATION, but we also must send a proper NACK back to the BSC.
Change-Id: I4dd7ff2fd2cdbc6e892cd329c826ac1bc3b16bb9
The code actually always *wanted* to make lchan activation fail in
case we don't support the algorithm, but it failed ot do so.
The problem is encr_info2lchan() which uses bts_supports_cipher() to
determine if the cipher is supported. However, if bts_supports_cipher()
returns 0 (not supported), it uses this value as return value of
encr_info2lchan() where '0' means success (standard osmocom convention).
This results in channel activation proceeding, which it shouldn't.
Change-Id: I46275b8fc2a1a74f68b4cc60e0f64ba226b108cd
Related: OS#3254
This logging turned up while I was debugging dynamic timeslots:
- OML Set Channel Attributes logging.
- a specific dyn TS pchan error.
- show pchan and lchan types on CHAN ACT ACK and REL ACK logging.
- on RSL message Rx, log the current pchan kind in detail, using
gsm_ts_and_pchan_name(). This logs the underlying pchan as well as the
current pchan mode a dyn TS is in.
- move 2 dyn TS logging from DL1C to DRSL, where all the other dyn ts logging
is.
Change-Id: Ia89c134060e85f7065afd5642d1c541c65dd25ea
In early rsl_rx_chan_activ(), do not use rsl_tx_chan_act_acknack() to trigger
sending a NACK, instead use rsl_tx_chan_act_nack() directly.
Rationale: the previously used rsl_tx_chan_act_acknack() may decide to omit the
NACK, particularly based on the lchan->rel_act_kind. lchan->rel_act_kind
indicates whether the Chan Release or Activation was explicitly requested via
RSL, and thus whether an ACK/NACK should go back to RSL or not. This gets set
only late in rsl_rx_chan_activ(). We cannot set it on top, because we need to
first establish whether the Chan Activ is permitted or not. In case of early
rejection of the Chan Activ, we do not want to modify the lchan state, but
merely reply with a NACK, unconditionally.
Before this patch, NACKs that rsl_rx_chan_activ() wants to trigger would
possibly be not be sent out on RSL, because lchan->rel_act_kind is not
explicitly initialized until later.
Fixes: BTS_Tests.TC_dyn_ipa_pdch_act_tchf_act_nack
Change-Id: Ic981f768cc024f0acd3d7ae55846cfbc7bc089ce
When an RF CHANnel RELease request is received on an already released lchan,
there is no "REL NACK" message or similar, we just ACK the release.
When ACKing the release, make sure to reflect the same chan_nr that the release
was asked for, since the lchan state may actually reflect a different chan_nr.
Factor the actual Rel Ack message sending out of rsl_tx_rf_rel_ack(), which
makes all sorts of decisions around normal Rel Ack: add static tx_rf_rel_ack(),
with chan_nr argument instead of deriving chan_nr from the lchan.
Use this to directly ACK an unusual Chan Rel with the chan_nr that came in with
the request.
Fixes: BTS_Tests.TC_dyn_osmo_pdch_unsol_deact
(after I6b790e866ce4e66d9385b286b727ae41a83d3e67)
Change-Id: Iceaa2e87874ced42d664a2a0b01a1c59e46a19b3
Make osmo-bts send a State Changed Event Report when RF is locked
or unlocked. This behaviour isn't mentioned in the spec as far as
we know, but an ipaccess nanobts also produces these messages.
Change-Id: I37e44ef4881c41f8835428b610e7863f37397c9f
Related: OS#3161
In gsm_lchan2chan_nr(), use a switch to reflect both dyn TS kinds and enrich
with comments. Move GSM_PCHAN_TCH_F_PDCH out of gsm_pchan2chan_nr(), which is
now back to pure standard PCHAN values.
Rationale: it's easier to figure out what is going on and why.
Change-Id: I6a31b44220d97c9173c52d3567a1382541710d10
For ip.access style TCH/F_PDCH, this fixes switch-back to PDCH in case the TCH
use employed encryption.
For Osmocom style TCH/F_TCH/H_PDCH, do the same, purely out of sanity. Roughly
the same should already be happening during PDCH Chan Activ, but make sure to
clear all these fields, so they are cleared even if IEs are missing.
From both dyn TS code paths, call new clear_lchan_for_pdch_activ(), which
clears the same fields that are normally overwritten by an RSL Chan Activ.
Related: OS#3238
Change-Id: I8451039683b54bee910c97c5a3e6873e0ff1b160
When the PCU is not connected, we immediately call rsl_tx_rf_rel_ack() because
we don't need to wait for a PDCH deactivation. Fix: properly mark rel_act_kind
= LCHAN_REL_ACT_PCU to invoke identical behavior as when the PCU were involved.
(When the PCU is connected, a PDCH release on an Osmocom style dyn TS causes an
actual release of the PDCH TS, and then triggers an rsl_tx_rf_rel_ack() with
rel_act_kind == LCHAN_REL_ACT_PCU.)
Clarify the code flow: rc == 1 is the special case of no PCU being connected,
so have that in a separate if{}.
Change-Id: I654b963815b32fcbce050c2e15f3190c97bc259f
When a release of PDCH is complete, actually set the dyn.pchan_is to NONE.
Failure to do so currently caused errors on activation of an Osmocom style dyn
TS as TCH, in the shape of:
rsl.c:636 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
rsl.c:164 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH switching PDCH -> NONE) RSL rx DCHAN: mismatching chan_nr=0x12
rsl.c:2611 Rx RSL CHAN_ACTIV for unknown lchan
rsl.c:710 0x12: Sending Channel Activated NACK: cause = 0x64
The Tx RF CHAN REL ACK shows that we're through with PDCH release, but the
following line showing "chan=TCH/F_TCH/H_PDCH switching PDCH -> NONE" shows
that the state still reflects active switching. Thus the DCHAN code decides
that the chan_nr = 0x12 reflecting a TCH/H on TS 2 is a mismatch and NACKs the
TCH activation.
(For ip.access style TCH/F_PDCH, the ts->flags are cleared in
ipacc_dyn_pdch_complete()).
Related: OS#3235
Change-Id: Ic06c8f0fe82ae8a06afa5defd93a685010687965
Use a switch statement and ample comments to clarify what is done and why.
Cosmetically prepares for Ic06c8f0fe82ae8a06afa5defd93a685010687965.
Related: OS#3235
Change-Id: I8a9953b011a4516972aae468754494f57ebc0a3f
Should fix following observed run time errors:
osmo-bts-trx/scheduler_trx.c:1627:65: runtime error: signed integer overflow: -1081823 * 4615 cannot be represented in type 'int'
osmo-bts-trx/scheduler_trx.c:1627:21: runtime error: signed integer overflow: 1852394502 - -697645849 cannot be represented in type 'int'
Related: OS#3213
Change-Id: I36e0d2d0d0c6e35e963f611135453c4a4c00bc99
The caller translates errno values back into NACK codes anyway,
so lets's return NACK codes directly.
Change-Id: I2b1f79e66c778139d64101c89dd6377921807e2d
Related: OS#2295
In addition to logging an error, send a NACK if the BSC attempts
to set more than one ARFCN in Radio Carrier Attributes for a BTS
which does not support frequency hopping.
Change-Id: Ia72e23a3f08f825cf9cf0d9a55302d13cfed51d6
Related: OS#2295
src/common/sysinfo.c:147:1: warning: control reaches end of non-void function [-Wreturn-type]
}
The compiler warning is actually a false positive since we call
OSMO_ABORT on that path, but let's add a return anyway so the
compiler doesn't throw a warning.
Change-Id: I9b4e06927489a8bc20ce173279a01415a8c4295a
When a bad voice frame is received, it is replaced by
a silence frame. This may cause unpleasant audio effects.
This change implements a functionality to craft a replacement
frame from the last known good frame using ECU implementation
from libosmocodec. At the moment, only FR is supported.
Depends: libosmocore I06a21f60db01bfe1c2b838f93866fad1d53fdcd1
Change-Id: Iae9e69a9578ae305bca42f834694af96a29084e6
At the moment osmo-bts does not compile with the latest header
file release from OCTSDR-2G-02.10.00-B1837-ALPHA as there are
struct members removed and new ones added. The changes do not
affect actual functionality in the existing code. The only
affected parts are vty functions that query status information
about the clock sync manager.
- Add detection logic in configure.ac to detect if the affected
struct members are present
- Add conditional compiling to handle the different combinations
of available struct members.
Change-Id: Ic38d8dc35522205c4ffab583b4e61b5ef03cdba2
Related: SYS#4139
Patch-by: Octasic inc.
in change-id Iebd2571726d1284a7431b3f9b23ad3185e832ed1 we introduced
tighter validation on whether the requested channel number matches the
underlying physical channel configuration. Unfortunately this broke
activation of an osmocom-style dynamic PDCH as TCH/F or TCH/H
rsl_lchan_lookup already permitted a chan_nr if the dynamic PDCH was
already switched to the given TCH mode, or at least the related
switching had already been initiated.
However, in the case of the bug, the current type is NONE, which means
that the compatibility check of rsl_lchan_lookup will fail
Let's relax the checks of rsl_lchan_lookup() slightly to permit
matching for "ts->dyn.pchan_is == GSM_PCHAN_NONE" cases.
This fixes BTS_Tests.TC_dyn_osmo_pdch_tchh_act and
BTS_Tests.TC_dyn_osmo_pdch_tchf_act
Change-Id: I14ae4c4ed2aae0966e5cb5116cf024d6bd890237
Related: OS#3134
It seems that the IPA PDCH ACT ACK contains not only the channel number,
but also the frame number. Let's make sure we're as close as possible
to other implementations to ensure maximum interoperability.
Change-Id: Ibe7988e9ef374e8c7d9429777fb32322d90c2024
When writing chan_nr_is_dchan() in Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349,
I apparently only looked at TS 48.058 without considering the osmocom
extension to it for PDCH activation. The result is complete breakage
for "osmocom style dynamic PDCH" support.
This patch fixes the mistake by making the compare more specific.
Change-Id: I18e0774fdd48966bc95261e715f798464b8b681f
Related: OS#3131, OS#1853
Completely drop bts_log_init(), call osmo_init_logging2() directly instead: all
callers of bts_log_init() passed NULL as category string, so all it ever did
was call osmo_init_logging(). The bts_log_info is already declared in the .h.
Here and there also define a proper talloc root context instead of using NULL.
Change-Id: Ic049f77bef74123b95350bcae182a468e0086b9c
This commit restores ability to read write to the
SuperFemto EEPROM.
Use offsetof() instead of casts to pointers when
calculating the address to pass to
eeprom_read() and eeprom_write()
Fixes: 7cf144b27d
Change-Id: Iaa7318387ad7bb248c261b1f428019244039e7d2
This assumption used while sending the rx data to gsmtap in l1sap_up was
making osmo-bts-virtual crash, since that bts model is allocating the
l1sap in the stack rather than inside the msgb.
Instead, let's use the assumption that l2h is set correctly in msgb by
the bts model lower layer.
crash report:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
(gdb) bt
0 0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
1 0x00007ffff6dbf4c8 in gsmtap_makemsg_ex (type=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
chan_type=<optimized out>, ss=ss@entry=0 '\000', fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:179
2 0x00007ffff6dbf6d8 in gsmtap_send_ex (gti=0x555555877f10, type=type@entry=1 '\001', arfcn=arfcn@entry=17255,
ts=ts@entry=6 '\006', chan_type=<optimized out>, ss=<optimized out>, fn=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:311
3 0x00007ffff6dbf765 in gsmtap_send (gti=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
chan_type=<optimized out>, ss=<optimized out>, fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:330
4 0x0000555555573571 in to_gsmtap (trx=0x7ffff7ef8070, l1sap=0x7fffffffde80)
at osmo-bts/src/common/l1sap.c:397
5 0x0000555555573b9c in l1sap_up (trx=0x7ffff7ef8070, l1sap=l1sap@entry=0x7fffffffde80)
at osmo-bts/src/common/l1sap.c:1285
6 0x000055555555ec06 in virt_um_rcv_cb (vui=<optimized out>, msg=<optimized out>)
at osmo-bts/src/osmo-bts-virtual/l1_if.c:170
7 0x000055555555f5c6 in virt_um_fd_cb (ofd=0x55555587cc30, what=<optimized out>)
at osmo-bts/src/osmo-bts-virtual/virtual_um.c:50
8 0x00007ffff6db6991 in osmo_fd_disp_fds (_eset=0x7fffffffe090, _wset=0x7fffffffe010, _rset=0x7fffffffdf90)
at libosmocore/src/select.c:216
9 osmo_select_main (polling=polling@entry=0) at libosmocore/src/select.c:256
10 0x0000555555576fbc in bts_main (argc=5, argv=0x7fffffffe288)
at osmo-bts/src/common/main.c:364
11 0x00007ffff61b5f4a in __libc_start_main () from /usr/lib/libc.so.6
12 0x000055555555c4ca in _start ()
In the old code when the sizeof(osmo_phsap_prim) was being substracted
it resulted on a negative len which later was casted to unsigned int and
became a really big number.
Fixes: OS#3092
Change-Id: I51a880328497673a06d153bfb76c428265b8cbb8
In omldummy, we don't have a RSL link and hence any transmission
attempts to RSL should silently go to /dev/null rather than printing
error messages via libosmo-abis. So check for the OMLDUMMY variant and
silently discard any RSL message that the code may want to transmit.
Change-Id: I04a9ec7e416822cc1e45c533e6a66628689615ad
This is used only in integration testing, where in the TTCN-3 testsuite
we currently have no A-bis OML implementation, but only a RSL one.
Change-Id: Id8e5f34091e6e32621d8c8673de7ea848dfd252f
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
Rathert han have 11 direct members of gsm_bts_role_bts, group them
into a sub-struct as ew do for other parts like interference, laod, ...
Change-Id: Iefecf4b70c1b11c650913f2ae3783718ffb8a36c
What we remove here is a legacy from sharing this header file with
openbsc/osmo-bsc-sccplite, which we stopped to do quite some time ago
and hence can remove those parts that are only relevant to the BSC but
not to the BTS.
Change-Id: Icac1656da68f6a006a28c779e3b563bbdd905b3d
In order to be able to introspect not only the root application
context, but also all other contexts, e.g. allocated within
libosmocore or other libraries, let's enable tracking the
use of NULL contexts using the corresponding talloc API.
In order to obserbe all existing contexts,
use the following VTY command:
OsmoBTS# show talloc-context all ...
Example of usage:
OsmoBTS# show talloc-context all brief
talloc report on 'null_context' (total 1302808 bytes in 5185 blocks)
lapd context contains 129 bytes in 5 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct pcu_sock_state contains 120 bytes in 1 blocks
struct lookup_helper contains 24 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
abis contains 49065 bytes in 19 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
vty contains 93690 bytes in 5008 blocks
logging contains 2862 bytes in 7 blocks
OsmoBTS context contains 1156678 bytes in 137 blocks
Change-Id: I5e9381902dace7dfd37f98b657e4697b5afcff96
The existing algorithm (present since 2012!) failed to work
in the sole case that only *one* SACCH filling type was present.
So if you had your BTS configured to only broadcast SI5, but not
broadcast SI5ter, SI6 or any other SACCH filling, it would send
the SI5 message only once on a newly-established channel, and never
again.
The old code was working for more-than-one SACCH filling, as well
as for no SACCH filling at all.
Let's also add a NOTICE message if there is no SACCH filling available
at all. This is highly unusual and definitely a noticeable event.
Change-Id: Ica801f9b9c118f00d9e3dc2780b3123e925f59b4
Closes: OS#3057
Related: OS#2963
Record the mnc_3_digits flag from SI and pass on via the PCU interface.
Instead of changing to e.g. osmo_plmn_id, add the flag separately, and instead
of bool use a uint8_t, to not raise any struct packing issues and clarify the
flag's size beyond any doubt.
Bump the PCU interface version to 9.
This is one part of the three identical pcuif_proto.h patches:
- I49cd762c3c9d7ee6a82451bdf3ffa2a060767947 (osmo-bts)
- I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu)
- I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 (osmo-bsc)
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore)
Change-Id: I49cd762c3c9d7ee6a82451bdf3ffa2a060767947
When using a firmware version < 3.6, the call to l1if_mute_rf()
returned an error, which caused an OML CHG ADM STATE NACK.
Let's check if the l1if_mute_rf() call is an un-mute for all
timeslots (which apparently we do always at start-up). If it is, then
acknowledge it even if muting is not supported by earlier firmwares.
I suppose the change causing this problem was introduced in:
commit b26b8fc776
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date: Tue Mar 4 15:03:59 2014 +0100
sysmobts: Do a RF mute at initialization when the RC is locked
With the current change applied, we can run the BTS with earlier
firmware versions than 3.6.0 again. Tested with 3.1 and 2.4
Change-Id: I1a29c1031d96e65a0111bc812a90f2dbaf2a5aa3
SI1 is only required if frequency hopping is used or if NCH is used. So it's optional.
If OsmoBTS has no SI1 configured, it will transmit the empty SI1 buffer
at TC=0, and as a result no valid SI will be broadcast at TC=0.
Change-Id: I41ab885c00e943199b2e939e98f30e267ecffbee
Closes: OS#3051
Commit c2b4c668f3
I3b989580cb38082e3fd8fc50a11fedda13991092 introduces evaluation of ra_ind
members below the msgb_trim() call that actually invalidates ra_ind.
A symptom is that it breaks detection of Handover RACH, wich always ends up
with lchan == NULL and interpreting all RACH as chan_nr == 0x88.
Fix: do all evaluation of ra_ind before the msgb_trim(), for osmo-bts-sysmo,
litecell-15 and octphy.
To guard against similar mistakes in the future, set ra_ind = NULL before the
msgb_trim() call.
Related: OS#3045
Change-Id: I203021ee57f49cb963679ba8bec5943e2abb67fb
the file l1_tch.c in the octphy spcific code has its root in the
tch.c file of sysmobts. It contains some sysmobts specific ifdefs
which enclose dead code.
- Remove the sysmobts specif ifdefs and the dead code
Change-Id: I33f3e0fd293ca8387fddf5ed20f642621e9680de
In general, RACH bursts should not arrive with negative offset.
Let's limit early signal arrival up to 2 symbols, otherwise it
is most likely noise, interference or a ghost.
TTCN-3 test case: Icccc88545ed3aabd6da28a40599a8a77d1de477d
Change-Id: I662294fe3136cf7a259be13816a3e63f7db9a948
Neels Hofmeyr
Harald Welte
Pau Espin
Philipp Maier
Keith Whyte