Do not attempt to change permissions/ownership if the package gets
upgraded from a version higher than the next release.
Do not fail if the user deleted the config file.
Be verbose when changing permissions.
Related: OS#4107
Change-Id: I853097a13e27b2ebd0b940117c8f5f4b3ea49b9a
* Explicitly chown /var/lib/osmocom to osmocom:osmocom, instead of
relying on systemd to do it when the service starts up. This does not
work with the systemd versions in debian 10 and almalinux 8.
* deb: Use "useradd" instead of the interactive "adduser" perl script
from Debian. This makes it consistent with how we do it in rpm, and
avoids the dependency on "adduser".
* deb: Consistently use tabs through the file, instead of mixing tabs
and spaces.
* deb: Remove support for the "dpkg-statoverride --list" logic. This
seems to be a rather obscure feature to override permissions for
certain files or directories, for which it does not seem to be a good
idea to make the postinst script less maintainable. Something similar
can be achieved by using your own Osmocom config file in a different
path with different permissions.
Related: OS#4107
Change-Id: Ie34e7aa65e576cf1742a33530a6f44d2344c39d0
Create osmocom user & group during package installation.
Fix the configuration dir/files permission to match.
Related: OS#4107
Tweaked-By: Oliver Smith <osmith@sysmocom.de>
Change-Id: Ic64bcd8a8124fcc8c6d7ffe31d32f51b288afdcb
libosmo-netif (not yet released) stream_{cli,srv} osmo_io read_cb API was
updated to provide read result status. Hence, now API users
can account for lower layer errors and act properly, like it used to
do with the previous ofd backend.
This commit partially reverts some error code paths removed in
85687bf176 when converting code to use
osmo_io osmo_stream backend.
Change-Id: I4cce5cb6ca98bc28a67dd6e927e9cdfd2312851a
Depends: libosmo-netif.git Change-Id I395c75ff1e9904757ce1d767a9ac2f779593c4c8
This new commands show information about logical channels:
net.btsN.trxM.tsI.show-lchan.full
net.btsN.trxM.show-lchan.full
net.btsN.show-lchan.full
net.show-lchan.full
Change-Id: I23c1a7e6f6679e3964e359fb202ffe6781a07e8a
This new command shows information about a logical channel using
net.btsN.trxM.tsI.lchanL.show.full
Change-Id: I5432800eae452b6df71a151a7649f228704ed0da
I guess it must have been a mistake when introducing this file.
The entire project is under AGPLv3, it doesn't make sense to have
one single file under GPLv2.
As th entire git commit history only contains sysmocom employees,
I have the authority to re-license it even if GPLv2 was done
intentionally at the time. Let's change it.
Change-Id: I5e5385f7630b41f1c4ad9534dbb4551e597ad596
IF we say "... under the terms of the GNU Affero General Public License"
then we cannot say "see the GNU General Public license" later on, that's
misleading and likely a copy+paste error somewhere.
The project license has always been AGPLv3-or-later.
Change-Id: I6b8ad5147ca76052213809e67856dcb80bff2b93
This new command allows to control MS power level for a specific
logical channel using net.btsN.trxM.tsI.lchanL.ms-power
This patch also adds a lchan node to the ctrl interface.
Depends: libosmocore.git Ibf2786f668ee7e4f5b6a9ef43f2141cd2d79b4e2
Change-Id: I6f556b66011be6126d6bac31a14101ba37f81cc4
Besides from making the ts ctrl interface follow the convention
of being in its own file, it will be used in the next patch to add
a ctrl interface for lchan.
Change-Id: I9840bddd4eae409bc8373912d54b6bbfc9fc1c1a
clang warns us about 'len' being set, but not used: And this is
abis_nm.c:2172:10: warning: variable 'len' set but not used [-Wunused-but-set-variable]
uint8_t len = attr_len;
^
This is actually a bug, because in the case of NACK we append 2 more
bytes {NM_ATT_NACK_CAUSES, NM_NACK_OBJCLASS_NOTSUPP}, and we need to
pass the final length to fill_om_fom_hdr(), including those optional
two bytes. Passing 'attr_len' (length of 'attr') is wrong.
Change-Id: I3ca8e761fdf99dd498a979ccc9d53c6c3e03e2cc
A switch (bool) is used to enable or disable NSVC 0 or 1. It is enabled
via any "gprs nsvc 0|1" command and disabled via "no gprs nsvc 0|1"
command. If it is disabled, it is treated as unconfigured, similar when
no remote IP or port has been defined.
Related: OS#6006
Change-Id: Ia112e86aa35f6a245d98ef1b3720c18835faeda6
This line shows all BTS an their OML states in a single line.
Additionally the uptime or downtime is displayed, if there was a connect
or disconnect of the OML link.
Related: OS#6018
Change-Id: I003fd32e589ddf53b7dd42089f904cfb598e3625
Make the output more readable and split it over two lines, in
preparation to add more information in the next patch.
Before:
OsmoBSC> show mscs
0 m3ua RI=SSN_PC,PC=0.23.3,SSN=BSSAP RI=SSN_PC,PC=0.23.1,SSN=BSSAP
After:
OsmoBSC> show mscs
MSC 0: RI=SSN_PC,PC=0.23.3,SSN=BSSAP <-> RI=SSN_PC,PC=0.23.1,SSN=BSSAP
ASP protocol: m3ua
Related: OS#6741
Change-Id: I70ad1b0f44f2a923248f4e3259747cb3fec98fd2
According to Table 10.5.2.3.1 in TS 144.018, radio-link-timeout
values are between 4 to 64 in steps of 4.
Change-Id: I733591d5f72f2e4f822761ca9eda85de7a4c6c81
osmo-bsc would not start with a config written from the vty due
to incorrect identation on the pcu-socket parameters.
Change-Id: I36a66794e654989b4b8bf54bb3727ccbfc2131fa
Only check for intersecting full rate AMR codec, if the BTS has at least
one full rate or dynamic time slot configured.
Only check for intersecting half rate AMR codec, if the BTS has at least
one half rate or dynamic time slot configured.
Related: OS#5926
Change-Id: Ia4a8e7f22dc652655ee7c5458624df8ae136dd95
I believe the actual intention was to reset the 'lchan_nr' variable,
and not the 'chan_nr'. The 'lchan_nr' is used to compose the 'cbits':
cbits = 0x04;
cbits += lchan_nr;
If the value is 4, then the result is:
cbits = 0x04 + 4 = 0x08
which corresponds to SDCCH8 (not SDCCH4), and is clearly wrong.
Change-Id: Ic9c7c2e46e24dab0b721221e9adcbbae2ca56d23
Fixes: ec1b5a0e9 "gsm_ts2chan_nr(): add assertions for lchan_nr"
Fixes: CID#336586
A typical OS imposed limit is 1024 open FD, which is too low when there
are hundreds of BTS.
In systemd service file, set a super high limit of 65536.
In osmo-bsc's user manual, add section 'Configure limits' describing
this in detail.
Related: OS#6256
Change-Id: I26c4058484b11ff1d035a919bf88824c3af14e71
We already recover broken lchans where an ACTIV ACK or REL ACK arrives
late. Now add a recovery path for lchans that are broken because no
ACTIV ACK or REL ACK arrives at all.
Add a timeout of X28 = 30s to the lchan BORKEN state.
On timeout, attempt both a Channel Activation and a Channel Release. If
any of them is ACKed, we have successfully synced BTS and BSC's state.
After successful recovery, place the lchan back in the UNUSED state,
available for servicing subscribers.
If recovery is unsuccessful, just continue to attempt recovery every
further X28 seconds.
Patch-by: osmith, nhofmeyr
Related: osmo-ttcn3-hacks I9b4ddfc4a337808d9d5ec538c25fd390b1b2530f
Related: OS#5106
Related: SYS#6655
Change-Id: Ic4728b3efe843ea63e2a0b54b1ea8a925347484a
The assignment is repeated because the calling subscriber may not
receive the notification on the DCCH, during handover process. After the
assignment is complete, the calling subscriber will receive
notification.
This cannot be done automatically by the BTS, because the BTS has no
relation between the notifications and the channels.
The notification is required, so that the MS knows the channel to listen
to when leaving the uplink the first time. If no notification is
received, the MS will abort the call.
Change-Id: Ife568b8c2756be332c0b8de21111f66f6e537c4d
Title refers to the maximum length of the osmo_wqueue used for
the PCU socket connection.
Related: OS#5774
Change-Id: Ic5f19f4613bccaf582997a4d02b689adee083a0b
The lchan FSM timers were originally implemented to model earlier code
as closely as possible. Now it has come up that T3111 is used in the
wrong place:
3GPP TS 44.018 says:
T3111:
This timer is used to delay the channel deactivation after
disconnection of the main signalling link.
Its purpose is to let some time for possible repetition of the disconnection.
Its value is equal to the value of T3110.
Before this patch, we use it also to time the RF REL ACK message. That
is pretty bad, because T3111 is only 2 seconds by default, making RF
CHAN REL vulnerable for timeout. When a user increased T3111 to
alleviate the problem, the result is that each lchan also delays its
normal channel release procedure by the configured amount of time. Very
inelegant.
Instead, use the X6 timer for REL ACK, because X6 already times the CHAN
ACTIV ACK, which is semantically identical.
Compatibility / user impact: No negative impact expected.
We can assume that every user out there has X6 configured to work for
CHAN ACTIV ACK. From that logic, switching channel release ACK to the
same timer is guaranteed to be what the user intends. We could instruct
users in the release notes that they may now choose T3111 freely (as
short as 2 seconds) without jeopardising channel release anymore.
Related: SYS#6655
Change-Id: Ibd118fa23e5deb4381bc31b11a7b495f57901d6c
At the moment the PCU has no way of knowing with which BTS model it is
used with. However, some BTS models may require slightly different
behaviour by the PCU, depending on which BTS model is used. So, lets add
an additional bts_model field to struct gsm_pcu_if_info_ind in order to
convey the exact BTS model to the PCU.
Related: OS#6191
Depends: osmo-pcu.git I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
Change-Id: I4b58912ad7be3070829614853901aa19108ba2c0
Not only l_bts must be declared outside the for-loop, but also last_i.
This is a fixup of I9dbbd066075f9ccb331616a2b59b46b1b44c8b4c.
Related: CID#330311
Change-Id: Ia10c5e68cb2940d9360d78f606af25bb207ee55f
l_bts must be declared outside the for-loop. If the loop is passed with
n_bts set the first time, l_bts is set. If the loop is passed with
n_bts set next time(s), l_bts is used to encode additional neighbor
cell infos.
Related: CID#330310 and CID#330311
Change-Id: I9dbbd066075f9ccb331616a2b59b46b1b44c8b4c
There are still some remains that are related to the old PCUIF v10
protocol version. Let's clean those up.
Related: OS#5927
Depends: osmo-pcu.git I68a3f59d5c960ae3a4fbd74f9d4a894295cb9ed8
Change-Id: Iebb3a634fee680bdc3636a61f3ccaa1e97e54a64
For each BTS, an SI 10 is generated with the informations about all
neighbor BTS that have the same group/broadcast call.
The SI 10 will only define neighbor cells within the same BSC, because
it does not know about neighbor cells within other BSCs.
When multiple channels are used for a group/broadcast call, the SI 10
is generated after all channels have been activated. Subsequent channel
activations result in an update of SI 10 on all channels.
Change-Id: Icd3101e6dd935a57f003253aaef400c2cf95a0c3
The error logging message within this function is moved to the user
neigh_list_get_arfcn().
In case of an error, which results in measurement report with cell
index that does not exist in the list of neigbor cells, the measurement
report is truncated to 0 neighbor cell measurements.
Change-Id: Ia8a1dca4837536129d17e7784b892bcb75b9ca4b
System Information 2 (bis/ter) uses BA_IND of 0. This refers to
"neigh_list". System information 5 (bis/ter) uses BA_IND of 1. This may
refer to "neigh_list" or optionally "si5_neigh_list", depending on the
VTY settings.
If BA_IND of 1 is received in measurement report and if the optional
"si5_neigh_list" is used, this list is chosen to decode the measurement
report.
Change-Id: Ie9123928fb3ae6f10921ecf01d1b50330661da38
Before this patch, neighbor cells with ARFCN 955 to 974 were ignored in
the GSM 900 band. This resulted an empty 'bit map 0' list in SI2/SI5
messages.
This patch includes R-GSM ARFCN in range 955 to 974. A different encoding
is chosen, if neigboring cells fall within this range.
Change-Id: I40d024290fa4be2ba8d3149ec841b182d0cc8c1f
The PCUIF flag PCU_IF_FLAG_SYSMO was originally used by osmo-bts-sysmo
to signal to the PCU that the direct PHY access for the sysmo-bts DSP
should be enabled. With time, support for other BTS models was added and
the flag became a synonym for "direct PHY access", so it makes sense to
rename it to "PCU_IF_FLAG_DIRECT_PHY"
Related: OS#6191
Depends: osmo-pcu.git I29b7b78a3a91d062b9ea3cd72623d30618cd3f0b
Change-Id: I23df067df99b76048667131905c4448d32d80640
Before this patch, the MGW was selected at startup, and the MGCP data
was always forwarded to that same MGW.
If several MGW were configured in the MGW pool, then osmo-bsc would
select any of those from the pool, and start configured the BTS-side
connection on an endpoint in that MGW. However, when the MSC submitted
the MGCP encapsulated in IPA to the BSC, the BSC would always forward
the MGCP message to that same MGW selected at startup.
As a result, multiple MGWs configured with osmo-bsc using SCCPlite was
broken.
This commit fixes support for multiple MGWs by looking up the already
selected MGW (to setup the BTS-side conn on the endpoint), based on the
CIC (MGCP Endpoint) which was provided by the MSC upon AssignReq.
Related: OS#6189
Depends: libosmocore.git Change-Id Iee361d740845257fa62c9093e30e8079fa933827
Depends: osmo-mgw.git Change-Id I18d7bdf650c0ec87ae16ed4944aed9f495400137
Change-Id: Ia106a21b7692eb5b2ac3b5ac2b358bedbc3b9da6
The first byte is the default version, the other bytes describe the
optional other versions supported by the MO. Print them all.
Change-Id: I01da4883cf59101ddaef575979519ac48fcf54b0
Even though the Abis/OML message flow looks the way it should look
on the wire, it does not actually reflect the sequence/flow of events
and actions in the NM FSMs. For example (extracted from a PCAP):
GPRS Cell(00,00,ff) State Changed Event Report
GPRS Cell(00,00,ff) Software Activate Request
GPRS Cell(00,00,ff) Software Activate Request ACK
GPRS Cell(00,00,ff) Activate Software
GPRS Cell(00,00,ff) Activate Software ACK
[a] GPRS Cell(00,00,ff) State Changed Event Report
[b] GPRS Cell(00,00,ff) Software Activated Report
[c] GPRS Cell(00,00,ff) Get Attributes
GPRS Cell(00,00,ff) Get Attributes Response
[d] GPRS Cell(00,00,ff) IPA Set Attributes
GPRS Cell(00,00,ff) IPA Set Attributes ACK
GPRS Cell(00,00,ff) Change Administrative State
GPRS Cell(00,00,ff) Change Administrative State ACK
GPRS Cell(00,00,ff) State Changed Event Report
GPRS Cell(00,00,ff) Opstart
GPRS Cell(00,00,ff) Opstart ACK
A follow-up patch [1] changes the logic generating message [d],
so that the IPA Object Version of the GPRS Cell MO is taken into
account when adding the attributes.
The problem is that both messages [c] and [d] are generated and
queued for transmission on the receipt of message [a], but *before*
message [b] has been processed. So the IPA Object Version is not
known and assumed to be 0 at that point in time.
This patch delays configure_loop() until message [b] is received.
So far only for nanoBTS and only for those MOs, for which Figure 2
in 3GPP TS 52.021 explicitly mentions that the SW downloading and
activation procedures may be required, plus for the ip.access
specific MOs which all seem to support the SW activation.
osmo-bts does send SW Activated Report only for a subset of MOs,
which does not include Baseband Transceiver, Radio Carrier, and
Radio Channel. 3GPP TS 52.021 is not clear on whether this
message shall be sent by all MOs either, so we consider it
optional and delay configure_loop() only for nanoBTS.
Change-Id: I3953a5e41eb27165f9ff203cac7447ee9d311abf
Related: [1] Ie0fb3eaf76e1f70e5a19bb088e1674b7e553d32a
3GPP TS 52.021 does not strictly mandate that the SW Activated Report
can only be received in state DISABLED/OFFLINE. The only requirement
is that the software load procedure (if needed) and activation is to
be performed in this state.
The successful outcome of software activation procedure is indicated
by the BTS using the above-mentioned SW Activated Report message,
which may be received in ST_OP_DISABLED_{DEPENDENCY,OFFLINE} too.
The MO state changes are triggered by the State Changed Event Report
messages, and happen asynchronously with the software activation.
This patch fixes the following warnings seen with a nanoBTS:
NM_BTS_OP(bts2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_NSE_OP(nse2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_CELL_OP(gprs-cell2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_NSVC_OP(nsvc0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_NSVC_OP(nsvc1){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_BB_TRANSC_OP(bts2-trx0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts1){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts3){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts4){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts5){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts6){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts7){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_RCARRIER_OP(bts2-trx0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
The following warning is still expected to show up though:
NM_BTS_SM_OP(bts_sm){ENABLED}: Event SW_ACT_REP not permitted
but is caused by a different problem, which is to be fixed later.
Change-Id: I00a423adcde5c34977f4c4dad920874687fa493c
These functions are called from a signal handler (SS_NM), and the
signal itself is sent from the generic OML logic whenever the
Software Activated Report is received from some BTS, which is not
necessarily a nanoBTS or osmo-bts.
It would be nice if we could check the BTS type once in the signal
handler, but the signal data is not always the same and depends on
the signal type, so unfortunately it's not possible.
Change-Id: I088ff75f2048e54e4bfd926a79c1dcf27b4fb3a4
Using bts->nr on the wire is wrong because:
* bts->nr is a BTS number in the BSC's config file,
* bts->bts_nr is a BTS number within the SITE-MANAGER MO.
The problem does not show up if there exists only one BTS node
in osmo-bsc.cfg. Otherwise, the Software Load and BTS Restart
procedures are broken for nanoBTS.
Change-Id: I99d9c72752e55c4553e2e9c60df5caa8343b7be0
This is a partial revert of commit [1], which defined a limit on the
number of attributes and SW Description IEs as a constant and added
a spec. reference. The problem is that there is no such limit in the
referenced 3GPP TS 52.021. The attributes and SW Description IEs are
using TL16V encoding, so there can be as many as the Length part can
represent. It's actually the limitation of our side, since we
allocate a buffer of fixed size on the stack for parsing.
* Remove the MAX_BTS_ATTR and confusing spec. reference.
* For the SW Description IEs, define SW_DESCR_MAX locally.
* For the attributes, define the buffer size in place.
Change-Id: Idd8b971d32cf0f7a910a664d921e644b7c32d831
Related: [1] 1ebf23b7fe "Prepare for BTS attribute reporting via OML"
Related: OS#4505
* Make it easier to append the attributes conditionally.
* Remove irrelevant comments about the order of attributes.
* Request NM_ATT_IPACC_SUPP_FEATURES from Abis/IP models only.
Change-Id: Ice5bddd51481a3ef9fcffd77a4c292ea211bf179
Related: OS#4505
Since change [1], among with the other attributes we started requesting
NM_ATT_IPACC_SUPP_FEATURES from the BTS. This patch adds the logic for
parsing the response (so far only printing supported features).
Change-Id: I64cffa0bdead3617cc169c83b0f6ddf74f0866a7
Related: [1] 43440e1fc5
Depends: libosmocore.git Ia4208e10d61843dd6ae77398f6624c918dc81ea4
Related: OS#4505
This commit prepares for adding handling of additional attributes.
The parse_attr_resp_info_attr() is already quite complex, so take
a chance to simplify it a bit.
Change-Id: Ia5919a8311cd6a7fc16d02d2196276881e96f4c5
Related: OS#4505
This code is unreachable, because this file is all about Siemens BS11.
Take a chance to remove redundant BTS type check in nm_reconfig_bts().
Change-Id: I2db92fe448b1f4cd25c1e5c6e1bb9593795c9cb2
Related: OS#4505
This way it becomes a lot clearer what kind of content is expected to be
transmitted over the wire.
It is expected that in the future the nowadays hardcoded values will be fed
into struct abis_nm_ipacc_att_ns_cfg come from osmo_tdef, etc.
Change-Id: I4b4dfac9fd36378b20889fb90135be74f8968d5f
Depends: libosmocore.git Change-Id I60e17dedd1fadce0f705616e3ed96cabb318bcec
Related: OS#5335
This way it becomes a lot clearer what kind of content is expected to be
transmitted over the wire.
It is expected that in the future the bts_sm->gprs.nse.timer will
disappear and the values fed into struct abis_nm_ipacc_att_ns_cfg
come from osmo_tdef, etc.
Change-Id: I610ca34babc0b0ac9477622aa7b8360be8f3f59f
Depends: libosmocore.git Change-Id Ie477b0e6d79e6d408e0004fd60307afc5feaa3b6
Related: OS#5335
This way it becomes a lot clearer what kind of content is expected to be
transmitted over the wire.
It is expected that in the future the bts->gprs.cell.timer will
disappear and the values fed into struct abis_nm_ipacc_att_bssgp_cfg
come from osmo_tdef, etc.
Depends: libosmocore.git Change-Id Ibfd759cb8a252f801bb3a758ea7960072c96f254
Related: OS#5335
Change-Id: Ie659879c548b29a08eeb8bf3fc023bf3d7d52aa1
bts->gprs.cell.timer is initialized during BTS allocation from
bts_cell_timer_default.
Later on, during nanobts_gen_set_nse_attr(), the same default values are
applied to an internal buffer and immedately later overwritten by the
content of bts->gprs.cell.timer.
Hence, drop the temporary assignment since it gets overwritten and is
basically a NO-OP.
This is only an intermediate one-step-at-a-time commit, since anyway
that arrive has to be convertd to osmocom tdef, etc.
Change-Id: I2a170093e62f726e594d3b9c456087f47d2b4198
In PCUIF v.11 we use PCU_IF_SAPI_AGCH_2 exclusively. We use this SAPI
to transfer IMMEDIATE ASSIGNMENT messages for uplink and downlink. One
new feature of PCU_IF_SAPI_AGCH_2 is that the PCU may ask to send a
confirmation when the MAC block is sent.
CAUTION: This patch breaks compatibility to current master osmo-pcu (See
also "Depends")
Related: OS#5927
Depends: osmo-pcu.git I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292
Change-Id: I709c27adaf09a6766cfde4d76d878626d30ebb3c
Since osmo-bsc uses RSL (with a propritary Ericsson RBS specific
extension) to send a confirmed IMMEDIATE ASSIGNMENT messages via
PCH, we can not just forward the MAC blocks into the paging queue
without determining whether the MAC block is a PAGING message or an
IMMEDIATE ASSIGNMENT message. the reason for this is that RSL uses
two different message types (IMMEDIATE ASSIGNMENT COMMAND and PAGING
COMMAND) to process IMMEDIATE ASSIGNMENT and PAGING messages.
This means we have to look into the MAC block to make sure whether
the message is a PAGING message or an IMMEDIATE ASSIGNMENT message.
We also need to make sure that the confirm flag is properly executed.
In the case of the IMMEDIATE ASSIGNMENT this means we have to include
(confirm=true) or not include (confirm=false) the RSL_IE_ERIC_MOBILE_ID
into the IMMEDIATE ASSIGNMENT COMMAND message.
In the case of PAGING we directly echo a confirmation after sending
the PAGING COMMAND via RSL when a confirmation is requested.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I3d2842626b7e8325860ea3160c7d900d39e953a0
The previous amount of 10 messages may be small if the BSC is processing
lots of measurements from lots of BTS connected to it.
Increase it to 100 by default, and allow changing the write_queue length
through the VTY.
Related: SYS#6550
Change-Id: Ib2e3591498c038b8e59f3ad447ac1f65928d6da8
The previous checks had several rough edges which may end up in
unexpected behaviors, specially with fd=0 vs fd=-1.
The new code is much more robust.
Change-Id: I96b0b5c4654970ba1c3e2aecfa896e310063ab6f
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0
Change-Id: I628aaf19999a0004d0760d25ecd323cdbc0076f5
Related: OS#5927
The struct gsm_pcu_if_data_cnf_dt was added when the first experiments
mit Ericsson RBS base stations were made. It is essentially a copy of
gsm_pcu_if_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Change-Id: I37845408edd96017b50559964c82b2cdc5e143a7
Related: OS#5927
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related struct member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6
Change-Id: Ifb3f257099b52c50e525768484f9e93282089d0f
As stated in 3GPP TS 48.008, section 3.2.2.103, coding of the Speech
Codec Element for the CSData Codec Type differs from coding for the
actual speech codecs like FR/HR/AMR/etc. However, osmo-bsc currently
encodes the "Speech Codec (Choosen)" IE regardless of the channel
mode, be it GSM0808_CHAN_SPEECH or GSM0808_CHAN_DATA. This causes
failures at the establishment stage of modem-to-modem data calls.
Change-Id: I8b94c0292964f6d5f5ffa98ad8da03728f8bf6a0
Related: OS#6110, OS#4393
struct lchan_activate_info and struct lchan_modify_info use an enum to
define, if the channel type is for a normal channel, a VAMOS channel or
a VGCS/VBS channel.
Change-Id: I21167eb4192c02cd7b5e1574cddb382a3feaebe0
The assignment is triggered by the MSC by sending an ASSIGNMENT REQUEST
with a group call reference. The reference is used to find the VGCS/VBS
channel that belogs to the referenced call.
The existing VGCS/VBS channel is reactivated. This will put the channel
into a state where the MS can establish the link on it, to complete the
assignment. The old connection is released by the MSC and assignment
completion is handled by the VGCS FSM.
Change-Id: Idaa864cd5ce4df6c3193494ce12d91523c104d89
Related: OS#4852
Channel release is sent to MS that is in dedicated mode on the main
DCCH. Additionally it is sent as unit data on a VGCS/VBS to notify all
listeners that the channel has been released. All listeners return to
IDLE mode.
Change-Id: Ib777fe98c8ce2342082d88d227b796167d92cfe1
Related: OS#4852
TALKER DETECTION and LISTENER DETECTION is used when the uplink is
accessed on the VGCS channel by a talker or listener.
Change-Id: I166d6d42c04337e669307943ecbb8eea6906b385
Related: OS#4852
If an SCCP connection or channel is released or fails, send indications
towards VGCS FSM, so that it can terminate the state machines belonging
to these connections.
Change-Id: Ia74db9ba47fea11b359ac01269f714482485d464
Related: OS#4852
RLL events are forwarded to VGCS FSM. Included L3 information are not
forwarded to gsm0408_rcvmsg(), but forwarded to VGCS FSM only.
Change-Id: I5e098a20225ba11206f43281f4da519a4086bae5
Related: OS#4852
If the phone is (still) on a dedicated channel, it may release the
uplink in case of a voice group call. It depends on the MSC how to
handle the situation. Currently it releases the call.
Generally the phone is assigned to the VGCS/VBS channel before it
releases the uplink.
Change-Id: Ib91c282ed36e82b38c0e738533e3a421de81a9a8
Related: OS#4852
A VGCS channel is established, even if there is no RLL establishmnt.
RLL connection can be established or released by the talker, while
the channel is kept in established state all the time.
Change-Id: I96390924736029b92e54590157e38093be749dd9
Related: OS#4852
A VGCS channel must not release, if all SAPIs (including 0) are
released. lchan FSM will ignore this.
Change-Id: Ief1e1894362c4917f6e0092268690f68c8193750
Related: OS#4852
bssmap_handle_ass_req_ct_speech() calls select_codecs(), which requires
a bts pointer.
An extra bts pointer is added to both function and used instead of
deiving it from the conn->lchan pointer. This funcion can then be called
if no channel is assigned (yet). (conn->lchan is NULL)
This function will be used by the VGCS/VBS call control also.
(Chg-Id: Id9e94fb4f27bb438b7093c031344a3400bfa34f1)
Change-Id: Ifc1e315d5282f01f8d1bd600d62476c2ae74eca9
Related: OS#4852
Rename _gsm0808_ass_compl_extend_osmux() to gsm0808_extend_osmux().
This IE is also used for VGCS/VBS assignment command that is located in
a different file.
Change-Id: I1452cabb142f9e7a169f4ddfeac85908abaf8dfc
Related: OS#4852
"enum lchan_select_reason" gets a new selection reason: "SELECT_FOR_VGCS"
The selection "direction" can also be changed via VTY.
Change-Id: I6b96d0a1df68efa5858b98297ebe0944b1473aaf
Related: OS#4852
"struct lchan_activate_info" is expanded to support flags for VGCS and
VBS. These are used to send the correct Channel Mode to the BTS.
"enum lchan_activate_for" is expanded to indicate and activation of
VGCS/VBS calls.
Change-Id: Ic0c0597d149d0758d6766937d99660fa02e0e139
Related: OS#4852
This message will be sent to each BTS with a VGCS/VBS channel to notify
the served MSs about ongoing group/broadcast calls. It is also used to
remove the notification, if the call is terminated.
Change-Id: I96ec0ee5d1a772a45f1ebfd64210718c8bf5aa58
Related: OS#4852
Do not build these utils implicitly if libsqlite3/libpcap/libcdk are
installed. Add configure flags for explicit building and fail if
dependencies are missing.
Keep behavior in deb and rpm packaging:
* deb: build meas_vis
* rpm: build none of these (libcdk dependency for meas_vis is not
available in most rpm-based distributions we build for)
Fixes: OS#5173
Depends: docker-playground I015b6d7cb834e99ea5d04206ba5f8c519c4e6af1
Change-Id: I8b3d5efb769437a5d3036e1e627b8d477275d93e
The set of values in seconds which can be expressed in the 3-bit field
DRX_TIMER_MAX (0s, 1s, 2s, 4s,...64s) don't include the "3s" that where
being specified. Instead, libosmocore's encode_drx_timer() was
taking both upper boundary "4s" and encoding it "0b011".
Hence, better write the value actually being transmitted to MS, to avoid
users/readers confusion.
More related info can be found on TS 44.060 Table 12.24.2 and TS 45.002
6.5.6.
Related: OS#6097
Change-Id: Ibf01a50b258e197ba5e3173492513349ddffdb38
Back in Change-Id Iefde0af44a663f22462a54d68a58caa560eceb2f I
introduced indication of the NCH position in the SI1 rest octets.
However, a related ERROR messages is accidentially also printed in
case no NCH is configured at all.
Let's split the already overly-complex if clause into a separate
function which then also handles the "bts->nch.num_blocks == 0"
case as permitted.
Change-Id: Iab2120a343cb0f6553f13a821b44b3c312587579
Related: OS#5781
The message PCU_IF_MSG_DATA_CNF_DT uses SAPI PCU_IF_SAPI_PCH, which is
formally not correct. It should use SAPI PCU_IF_SAPI_PCH_DT
Depends: osmo-pcu.git I0883b51fc232ec0267f1511c3a37c0bcd0967a08
Change-Id: Id5c799e625c56e57f7b51cd4fb57f5bea9c973d2
The nanoBTS feature reporting works significantly different from what
osmo-bts implements. They have a "Supported Features" IE in potentially
each of their MOs, and within this have nested IEs expressing respective
feature sets.
Let's start by requesting those for at least those MOs where we already
implement a GET ATTRIBUTES call in the FSM.
Change-Id: I15116044fb354ec0a0682c62078fbfa907b318f3
There is no such option in the configure.ac:
configure: WARNING: unrecognized options: --enable-vty-tests
Change-Id: I04421af0b250651a598a7aeb5bed55dbacec2f7c
This adds the vty commands and respective logic to allow the user to
specify the NCH (notification channel) position in the SI1 rests octets.
Change-Id: Iefde0af44a663f22462a54d68a58caa560eceb2f
Related: OS#5781
Requires: libosmocore.git I24a0095ac6eee0197f9d9ef9895c7795df6cdc49
cat-testlogs.sh does "exit 1", so no workspace.tar.xz is created.
Call this script after archiving the workspace.
Change-Id: Ibcb842f32418e66a186d6b21bb5861cf4a0b7c4a
Fixes: d33a66b779 "contrib/jenkins: create workspace.tar.xz on error"
Related: OS#5665
The PCUIF interface implementation in osmo-bsc provides two ways to
access the paging channel (PCH).
1) Under the SAPI PCU_IF_SAPI_PCH PAGING COMMAND messages are accepted
as whole MAC block but the format is in the style that we are going
to deprecate with PCUIF v.11. Also at the moment those PAGING COMMANDs
are not confirmed towards the PCU. This is also not necessary since
osmo-pcu would silently drop such confirmations. (see pcu_rx_data_cnf
in pcu_l1_if.cpp)
2) Under the SAPI PCU_IF_SAPI_PCH_DT messages are also accepded as
MAC blocks but the SAPI will only accept IMMEDIATE ASSIGNMENT messages.
The messages are encapsulated in a struct that holds IMSI (paging group)
and TLLI (used for confirmation) as separate struct members. The
messages are also confirmed towards the PCU as it should be.
Since we want to depreacete the older V.10 version of PCUIF and there is
not much benefit in maintaining two interfaces we should use
SAPI PCU_IF_SAPI_PCH_DT for both message types. This also requires small
adjustments to osmo-pcu (see Depends).
Depends: osmo-pcu.git I99cfe373fa157cfb32b74c113ad9935347653a71
Related: OS#5927
Change-Id: I82443f2b402aa2416469c8c50b1c050323ef3b8f
In order to figure out why we sometimes get a coredump in the jenkins
master jobs, add a quick hack to get all relevant binaries on libraries
on error.
Related: OS#5665
Change-Id: I1439c06316edbe11f162c14774c2d507152b97a7
Don't explicitly mention ip.access/nanoBTS if we actually want to refer
to all BTSs implementing an IPA-style Abis/IP interface.
Also, remove some bogus "is_ipa_abisip_bts(bts) || is_osmobts(bts)".
is_ipa_abisip_bts includes osmobts.
Change-Id: I31696d9a21a799511741a561085686cfa0728f93
This function is used to check if the BTS is using the IPA Abis-IP
transport, and not whether its manufacturer/vendor is ip.access.
Let's use a less confusing name.
Change-Id: I202c58341c1536489064d2671c0842c6f70b5429
The Manufacturer ID IE is normally used to indicate the [name of] the
manufacturer. In case of ip.access nanoBTS it is, for example, "com.ipaccess".
Osmocom decided to re-pupose this IE to indicate bts-specific feature
flags. Stop interpreting the string "com.ipaccess" as feature bitmap.
In fact, nanoBTS doesn't support runtime reporting of features (at
least not in this way), so let's mark features_get_reported = false,
resulting in the copy of bts_model->features to bts->features at the
time a BTS is initialized.
Change-Id: I76cee190dc1f074464df570cdfc3d38559f04846
Closes: OS#5959
Use the proper type that can handle the entire range of MSC numbers we
allow on the VTY, we have:
#define MSC_NR_RANGE "<0-1000>"
Before this patch, MSC pool round robin would glitch around for any
'msc' numbers 'msc 256' thru 'msc 1000'.
Change-Id: I98bee022c1a78508554d2ff4a10fbce3c53f1128
In abis_rsl_rx_rll(), we do the following header length check -- quick
challenge, can you spot the two bugs hidden here?
struct abis_rsl_rll_hdr *rllh;
if (msgb_l2len(msg) >
sizeof(struct abis_rsl_common_hdr) + sizeof(*rllh))
msg->l3h = &rllh->data[3];
Fix these bugs:
- struct abis_rsl_common_hdr is already included as the first member of
abis_rsl_rll_hdr, no need to add that.
- We are going to be accessing rrlh->data[3], so we must check for at
least sizeof(*rllh) + 4.
Change-Id: Ie4aee615c8c904ae8308ec0074d8bc5208137061
... and print a proper error message instead of "not supported". We
don't know for sure whether it's supported before the BTS is connected.
Change-Id: I080aa7ef331b76918ae48d555eea6e4290c57120
Related: SYS#6435
If power saving is enabled for a BTS, it should remain enabled even
if the BTS is restarted for whatever reason. This persistence can be
achieved by re-sending the configured power reduction value whenever
the BTS NM FSM enters the ENABLED state again (i.e. reconnects).
Separate gsm_bts_send_c0_power_red() from gsm_bts_set_c0_power_red()
and call the former from st_op_enabled_on_enter(). All we need to do
is to send the value that was configured before, per-timeslot power
reduction limits remain and need not to be updated.
Take a chance to move logging from BTS specific to the generic code.
Change-Id: Ic3f8a2ab0ffd049a8ed84361a3a588c1e1b23ac6
Related: SYS#6435
The A-bis/IP RTP CSD Format IR Values need to be shifted by 4 bits
instead of 5. See OsmoBTS Abis Protocol Specification § 5.8.14
RSL_IE_IPAC_RTP_CSD_FORMAT.
Related: https://ftp.osmocom.org/docs/osmo-bts/master/osmobts-abis.pdf
Related: OS#4393
Change-Id: I9ce0b2d9b77eef61a6d4dce417efe4e853217dc5
EUTRAN neighbors can be deleted using the following command:
$ osmo_ctrl.py \
-d 127.0.0.1 -p 4249 \
-s "bts.0.si2quater-neighbor-list.del.earfcn" EARFCN
UTRAN neighbors can be deleted using the following command:
$ osmo_ctrl.py \
-d 127.0.0.1 -p 4249 \
-s "bts.0.si2quater-neighbor-list.del.uarfcn" UARFCN,SCRAMBLE
This commit implements only deletion, implementing the add command
would require slightly more effort (lots of manual string parsing),
so it's left as a TODO for later.
Change-Id: I890bffb003f2a0ee9438f6ea6e8067c092504f08
Related: SYS#6401
The BTS can immediatelly ACK the OPSTART, but that doesn't mean the TS
is already usable. It should only be used when the BTS reports it is in
Enabled state.
Related: OS#5973
Change-Id: I712aa22252d29ceea152c25a5da75542e1691faf
We don't want to have duplicate EARFCNs in the config file.
The desired behavior is modifying existing EARFCNs.
Change-Id: Ia2fd8bd86d9f093967c1b0b0135151d2d5386dc1
Related: SYS#6401
This way we print the proper message if the given UARFCN is already
added, no matter if the UTRAN neighbour list is full or not.
Change-Id: Ife83023f6a9e28d77e44e4757457d4d1c879e78f
Related: SYS#6401
Don't fall back to the legacy config if the pool is configured but no
connection to any pool member can be established.
Depends: osmo-mgw I009483ac9dfd6627e414f14d43b89f40ea4644db
Related: OS#5993
Change-Id: I3a8418fb5841c71049ec91439143e1fe5553ed40
NSVC local port 0 is actually a valid value, which tells the PCU to
pick a random port for bind()ing. It was supported before 315af2f9e,
but now osmo-bsc would simply ignore NSVCs with 'local udp port 0'
and leave the respective MOs unconfigured in the BTS.
Change-Id: I0afd83e77f3daeeb082e7db911610428b5bc587c
Fixes: 315af2f9e "bts: ipa/osmo-bts/sysmobts: MO: add support for the second NSVC"
Related: OS#5979
* osmo-bsc currently does not support adding multile EARFCNs
with different thresh/prio/qrxlv parameter values;
* adding an EARFCN which already exists creates a duplicate;
* adding an UARFCN which already exists fails;
* adding UARFCN=0 fails.
Change-Id: Iece6b9058f4eb06f8f2c19311de4f2eea01cfe82
Related: SYS#6401
The signal is already there but not being used.
Let's further split generic paging code from RSL specificites.
Change-Id: Iabc1c29908a5136501d6dc6e60f8777dab511b86
vty_read_config() returns an errno number or zero; add the appropriate error string in case of error
Change-Id: I0015824a29ebf8aaeaa996ab4d2cb2769ea48864
The old ones have been deprecated and shall not be used anymore·
Depends: libosmocore.git Change-Id I799e35dc8d4d153fa63bf50563a5482cdf4de2d7
Change-Id: Id3be8e38ec87ae39c4e1b4fab163563b24fb2cee
Add a configuration file example to illustrate how exactly EGPRS is
configured on ericsson RBS BTSs.
Related: OS#5198
Change-Id: I2fb5b4d9300b16b0fac48f33b5db81442ab25031
The example config files that illustrate how to set up GPRS/EGPRS using
a BSC co-located PCU do not have any of the general GPRS parameters set.
Lets add a gprs prameter block to both of them.
Related: OS#5198
Change-Id: Ifc538940fadca08d03a36bf6a28392f22640493d
The manual does not yet mention the possibility to configure a BSC
co-located PCU. Lets add a short description to the chapter
Running OsmoBSC, Configure primary Links that enables users to get an
idea where exactly the BSC co-located PCU has its place in the RAN
infrastructure and which links it is connected with. Also give a short
example how to setup the unix domain socket path.
A more detailed description, especially about the timeslot configuration
will be added with a follow up patch for bts.adoc
Related: OS#5198
Change-Id: I3af3cd8ef7099bb94f4cb25513e9dfdc5fcc1b5a
The built in interface switch in ericsson RBS base stations no where
explained. From the example configuration files alone it is not possible
to understand how the IS configuration works. Let's add a chapter that
explains how the IS configuration works.
Related: OS#5198
Change-Id: Ib6ebd7fdfe9063c0d8cacf53ffd27f6099d9038a
User reports a SEGV:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 send_assignment_complete (conn=conn@entry=0x557dbabb75a0) at assignment_fsm.c:188
#1 0x0000557db66aa6b0 in assignment_success (conn=0x557dbabb75a0) at assignment_fsm.c:277
#2 0x00007f6007afee82 in _osmo_fsm_inst_dispatch (fi=0x557db9615b80, event=4, data=0x0, file=0x7f6007a7dc21 "mgcp_client_endpoint_fsm.c", line=513) at fsm.c:875
#3 0x00007f6007a78c12 in ?? () from /lib/x86_64-linux-gnu/libosmo-mgcp-client.so.9
version: osmo-bsc 1.9.0.111.fc339.202212220009
The situation apparently is conn->lchan == NULL (primary lchan is gone),
but Assignment has just concluded. Apparently an unexpected / orthogonal
event has interrupted operations.
During assignment_success(), do not assume that conn->lchan is still
present. This should normally be true, but if not, fail the assignment
procedure instead of crashing osmo-bsc.
Related: SYS#6382
Change-Id: I4db25d0458f620954a1ca345282f5d8316341919
Do this by setting the minimal value for T3105 to 1 in its timer definition.
Fixes: Coverity scan CID#307389
Change-Id: I1fd0b92ab507a58fed6e9649eaa4770f1ad1cbad
The manual contains a section about a TRAU mapper / E1 sub-channel
muxer. This section seems to be copied from the OsmoNITB manual. In
OsmoNITB everything was integrated in one binary, now dealing with TRAU
frames is the task of the MGW. Let's remove the section but still leave
a word about how Speech traffic is handled/relayed by OsmoBSC.
Change-Id: If33589feb80e1b29b4f841b678fe5329b8c06a76
The co-located PCU support for Ericsson RBS E1 CCU made it necessary to
add new features to the PCU socket interface, so let's increase the
version number.
Change-Id: I8315bd67c7f3eb0d7ee71b64cd4dff889a84fcf1
Depends: osmo-pcu.git I2a78651593323e8b9627c39918d949a33497b70f
Related: OS#5198
The current PCU implementation has never been tested with multiple BTS
attached to it. This is due to the fact that it has been used
exclusively in an BTS co-located setup where naturally only one BTS is
present. The PCU sock protocol supports multiple BTSs in theory and we
should handle this correctly.
Related: OS#5198
Change-Id: I0b42c2c130106f6ffca2dd08d079e1a7bda41f0b
The flag PCU_IF_FLAG_DT is no longer needed. The PCU implementation will
distinguish by the version number instead.
Change-Id: I0dc20e351deb14906b2edffc39499bad9659cc35
Related: OS#5198
When updating the BTS information in the bsc co-located PCU, first check
if the BTS has a BSC co-located PCU at all. Also check if the BTS is E1
based since those type of BTS require extra information about the E1
connection.
Related: OS#5198
Change-Id: I8da26debc0e27f24fae4ee88f22f8875de13bc84
At the momemnt we use is_ericsson_bts() to check if the BTS uses a BSC
co-located PCU, this is a bit ambiguous, lets have a function that
explicitly checks for a BSC co-located PCU and nothing else.
Change-Id: I23ed4219e5ebd188867c17f387ca877efa9bc3b0
Related: OS#5198
The check functions that we use to distinguish between the various types
of BTSs return an integer that can be 0 or 1. Let's change the return
type to bool
Change-Id: I3de957f228452c9d3aa4fed342f73bfb17363b40
Since there were complaints about this old parsing code during recent
code review in Ifdc9e04bf1d623da65bfb8a2fddea765601f6d9b, and now also
coverity finds something odd in it, just rewrite this.
Related: CID#310912
Change-Id: I96cd5d88ec6808a2915c6bccd0c0140216f328f2
In osmo-bsc, there's currently 0..1 Lb links and 0..N A links, where N
is the number of MSC, but links can be shared in the underlaying stack
(struct osmo_sccp_instance), hence range 0..N of different
osmo_sccp_instance (identified by PC).
Even more, the Lb and A link can share the same underlaying stack, so
osmo-bsc can end up with only 1 struct osmo_sccp_instance shared by all
the above mentioned links in case all are configured under the same PC.
Total range A+Lb is 0..(1+N).
A struct gsm_subscriber_conn stores 2 struct sccp_instance*, one for
Lb (conn->lcs.lb.*)and one for A (conn->sccp.*).
They can actually point to the same sccp_instance or to different ones,
as explained above, depending on the configured setup. In any case, a
gsm_subscriber_conn needs 2 rb_nodes since it can hold
any of the 2 conn_ids independently (A or Lb).
The previous patch forgot to add that 2nd rb_node as well as some
initialization and release code for the Lb conn. This patch addresses
that.
When the 2nd rb_node, a problem when iterating the rbtree appears: how to
find out the "conn" pointer from the rb_node pointer, since the rb_node pointer
can be any of the 2 rb_nodes inside the struct at a different offsets.
In order to solve that problem, a new struct bscp_sccp_conn_node is
added, which holds all the relevant information used by the rbtree lookup code
in a generic way (rb_node and conn_id), plus a backpointer to the struct
bsc_gsm_subcriber it relates too.
Fixes: 85062ccad3
Change-Id: If42d93adee71d646766929a09bc01ae92b734ef3
Calling talloc_free() on struct llist_head is wrong and will lead
to unexpected behavior. Call it on the containing struct instead.
Change-Id: Ib5eaa328aaf6881ae9621ca14859e4e255af2b00
It was found that on a busy osmo-bsc process (>1000 concurrent calls
spead over different BTSs), a good amount of time is spent iterating the
subscribers list trying to find a subscriber based on a TMSI (1.60% of
total CPU time used by osmo-bsc).
This patch introduces a new rbtree under struct bsc_subscr_store which
allows storing all the busbs ordered by TMSI.
This way, lookup time changes O(N) -> O(log(N)), at the expense of
increased insert/deletion time O(1) -> O(log(N)).
Related: SYS#6200
Change-Id: If27429e715ef4b327177e427249e68321a6e83cc
This allows keeping the bsc_subscriber storage internals outside of main
gsm_network code, while easily allowing making the internal
implementation more complex (in order to optimize it in a follow-up
commit).
It is also nice since we get rid of uncommon procedures being used in
this code, like allocating an llist directly as a talloc context, etc.
Change-Id: I616e8872af4ac63a6985f8900909e324ba889192
The function was currently in osmo_bsc_sigtran.c but was never used
there, and it really doesn't have any relation to that file.
Let's move it to the only place where it's used so far, and mark it as
static.
Change-Id: I8a8cef45aa378421e0ac328d3b29b9d194698a55
It was found that, on a busy osmo-bsc (>1000 concurrent calls spread over
several BTS), the CPU consumption looking up for gsm_subscriber_conn
based on SCCP conn_id can take a considerable amount of time (>5% of
osmo-bsc already taking 70% of the CPU time on the core it is running on).
The huge CPU consumption happens because a linear search is done (llist)
over the entire list of SCCP connections every time an SCCP message is
handled.
In order to optimize this lookup, this patch introduces a new struct
bsc_sccp_inst which becomes associated to the libosmo-sccp
osmo_sccp_instance. Each of this strucs maintains an rbtree of
gsm_subscriber_conn ordered by conn_id.
As a result algorithmic complexity adds O(log(N)) during insert, lookup
and delete of SCCP conns, but gets rid of O(N) previous lookup.
As a plus, finding a new conn_id now takes generally O(log(N)), while
before it used to take O(N).
Related: SYS#6200
Change-Id: I667d3ec1dad0ab7bc0fa4799d9611f3a914d07e5
Refactor the double loop to check a code path matching the sccp_instance
once instead of doing so for every subscr_conn.
If for instance let's say we have 1000 concurrent calls in progress,
which means we have 1000 subscr_conn, which means we at least do the
extra check regarding SMLC vs MSC 1000 times (at least, xN times if N
conn_id already used are already found).
That overhead happens every time a new subscr_conn is created (which in
a BSC with already 1000 concurrent calls can potentially happen quite
frequently).
Change-Id: Ic32b1eeb201fc51110e1ee130110824845f81e82
Function bsc_sccp_inst_next_conn_id() allocating conn_id creates address
spaces based on sccp_instance, aka conn_id values can be reused given
the sccp_instance (MSC) is different.
Hence, when looking up a bsc_conn based on a conn_id, it must also match
the sccp_instance, otherwise a bsc_conn from another MSC could be
returned.
Change-Id: I80a54bdec3973917e88483a62bfc2e968b8c0490
The 0x00FFFFFF source local reference is reserved in M3UA/SCCP, hence
avoid allocating a conn_id with that value since later on when reused as
a source local reference it would fail to be encoded.
Change-Id: I5c62bbfa89140d754edccb4404503cb70d5fde89
Currently, the conn_id is allocated in a range 0..0xffffff by
bsc_sccp_inst_next_conn_id(), and -1 means it is unset.
This means allocation expects "int" to be at least 32 bits integer,
in order to fit 24 bits for 0..0xffffff plus the -1.
Hence, let's define the variable as uint32_t, as already done in
libosmo-sccp. Use last value 0xFFFFFFFF ((uint32_t)-1) and avoid playing
with the value being unsigned sometimes and signed only for "unset"
value.
The value is actually already handled as unsigned (printed with %u) in
most places.
Change-Id: If019bcbc1e28929fe8d981fef9103835fc6ead2e
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I37f078bdc17e128298b956f493ff5c03ef476f98
It's possible that a BTS gets disconnected, updated to a more recent
version or downgraded to an older version, and then connects to the
BSC again. That more recent or older BTS version may have a different
set of supported features, so osmo-bsc must not trust the previously
reported feature vector.
Change-Id: Ie93af849d7771b4fff3cdf647c82510cd8543975
All non ericsson BTSs we support use a BTS co-located PCU, so we must
not depend on a PCU connection in those cases.
Related: OS#5943
Fixes: ecf825dc ("pcu_sock: activate/deactivate PDCH on pcu reconnect")
Change-Id: I296dfacb451d7b9b5ef1cec940bc1a577f3c43ad
The variable rc holds the return code of accept(), which returns a file
descriptor on success. So lets call the variable "fd" to make this
clear.
Change-Id: Ic8d22c2af18477f110a3a9115434314ebca95b25
When the IMMEDIATE ASSIGNMENT is sent from the PCU to the BSC using the
"direct TLLI" method, the TLLI (and the last three digits of the IMSI)
is prepended to the MAC block. Currently we are taking the fields apart
manually using offsets. The code for this is difficult to read and the
method is error prone. Let's define a struct that we can just overlay
to access the fields directly. Let's also transfer the full IMSI.
Change-Id: Id6acbd243adf26169e5e8319dd66bb68dd6a3c22
Related: OS#5198
When the PCU is disconnected while the BSC keeps running the PDCH should
be closed. Also the PDCH should be reopened when the PCU is
reconnected.
Change-Id: I9ea0c53a5e68a51c781ef43bae71f947cdb95678
Related: OS#5198
When a data request is received from the PCU, some of the switch cases
allocate a message buffer but the message buffer is only used to pass
its data and length to other functions. The message buffer itself is not
passed anywhere and it is also not freed. Lets get rid of the message
buffer and avoid unnecessary memcopy calls.
Related: OS#5198
Change-Id: Ibfaae177585a4d42d797b6bbd90e402641620140
Omit the A-bis/IP specific RSL_IE_IPAC_SPEECH_MODE, as it doesn't make
sense for circuit switched data.
Related: OS#4393
Change-Id: I6641b713177276bcf798f08123e1dd2e88ffdce6
Use the full gsm0808_chan_indicator value throughout the lchan related
structs (assignment_fsm_data, gsm_lchan, lchan_activate_info,
lchan_modify_info) instead of reducing it to the boolean
requires_voice_stream.
This is needed so we don't lose the information whether an lchan was
requested for data or speech (both need an rtp stream).
Add a new bsc_chan_ind_requires_rtp_stream function and use it in
conditionals like the previous requires_voice_stream.
Related: OS#4393
Change-Id: I1538c1e6d5cd61559af7c1e2860afd0269dda367
Prepare to include gsm_08_08.h in more files in the following patch,
without wrapping these functions it won't build anymore. Remove the
unused stub for bsc_assign_compl() while at it.
Related: OS#4393
Change-Id: I6cb84f493204e393fd719148f54b8bbc173588a4
Replace check_requires_voice_stream, which used to iterate over
ch_mode_rate_list and verify that all entries are either for speech or
signalling. Instead verify in check_chan_mode_rate_against_ch_indctr,
that all entries of ch_mode_rate_list have a chan_mode that matches the
ch_indctr (data, speech, signalling; called "speech / data indicator" in
3GPP TS 48.008 § 3.2.2.11).
This ensures that all of them are either data, speech or signalling and
not mixed.
Related: OS#4393
Change-Id: Iee5cbfee84d7f2ad59ee2d5a19891a2b59bbafff
Remove "speech mode" from the log message, as the log message is
relevant for CSD too. According to 3GPP TS 48.008 § 3.2.1.1 note 13 the
IE shall be included for AoIP unless channel type is signalling.
Related: OS#4393
Change-Id: Idfab0b7f6e97a6b67d140f967ddfe9b29818586e
Handle assignment requests for CSD. In this initial version, the code
for non-transparent data mode is a stub.
Related: OS#5763
Depends: libosmocore Ia965cdd9f53af756e5ffaff9b8f389b5ad629969
Change-Id: I350bea15fd2158eb6edc9bc92f2dca48930736e9
It looks like the idea was to translate the CSD rate from BSSAP to
lchan_csd_mode before translating it to RSL. But instead we can just
directly translate the BSSAP value to the RSL value.
The previous code was not used yet (nothing wrote to csd_mode).
Related: OS#4393
Depends: libosmocore I25bfd02aa1428a35492b20376a31635a442e545f
Change-Id: Ice914744da3a2084e82d125848fb69404b8e8a36
gsm_pchan_ids[] exists only to compose osmo_fsm compliant IDs. We do
have osmo_fsm_inst_update_id_f_sanitize() now, rather use that.
This removes some confusion about which value_string array has an effect
on the VTY command 'ts' / 'phys_chan_config'.
Note that tests/bsc_test.ok does not change, hence the new way of
composing FSM IDs is identical to using the old gsm_pchan_ids[].
Change-Id: Ib85b7aa4ea882ae37919dd3ea0c033e949c083e5
This patch affects *only* on osmo_fsm instance IDs, which are visible on
the CTRL and VTY interfaces to identify FSM instances, and in the log.
Why bother: An upcoming patch wants to replace gsm_pchan_ids[] with
osmo_fsm_inst_update_id_f_sanitize(gsm_pchan_name(x)), this is an
explicit step to match gsm_pchan_names[].
Change-Id: I4a540744cced466f0ca4fc605db4d0ec14ee8e87
Show the timeslot_fsm, lchan_fsm, assignment_fsm fi->id strings.
The IDs include the current pchan configuration. I want to tweak the
composition of these in an upcoming patch, so the test should show
whether any FSM IDs change from that.
Change-Id: If369f23fa140b9d7792f5a511815cbbd14b371e9
Change names of stat exports to be consistent with VTY,CTRL:
- from "chan_osmo_dyn" to "chan_dynamic_osmocom"
- from "chan_tch_f_pdch" to "chan_dynamic_ipaccess"
Change-Id: I863ad05e892563442041722bcd57f7c987e1f5ab
We already use "OSMO_DYN" as C name for "fully dynamic" timeslot config,
when working with osmo-bsc.cfg I dearly miss this short name, it is a
pain / has become ridiculous to write 'tch/f_tch/h_sdcch8_pdch'.
Introduce 'dynamic/osmocom' and 'dynamic/ipaccess' as default names for
our dynamic timeslots on VTY and CTRL. The old 'tch/f_tch/h_sdcch8_pdch'
and 'tch/f_pdch' are still supported.
Change-Id: I37719edd867c777d1ce944b8e2f1efffac38f00e
Add a static assert, and comments indicating the importance of the two
value_string arrays defining pchans on the VTY matching up.
Change-Id: I8118bec35400f7f00ca9ae43b603059ed701fa25
I'm going to add a regression test that probes lchan_fsm. I noticed that
I have to call lchan_fsm_init() for osmo_fsm_register(). Let's make this
implicit as we usually do now, to not have to register FSMs in tests.
Change-Id: I58760e743c78a370aedc9720f265c0f8da5c2045
Prepare some basic tests for 'timeslot' / 'phys_chan_config', because an
upcoming patch will add the 'osmodyn' alias, and this test shall show
the changes on the VTY.
Change-Id: I2c4aab90bcbc9019ca004fb1d4945476edbb7363
*.vty tests are picked up by the Makefile.am by means of a wildcard --
they are run when they are there. So when you forget to add it to
EXTRA_DIST, it will be run in your local build tree, but it will be
silently omitted from a distribution tar, and nothing will complain
about it gone missing.
Instead, also use a *.vty wildcard in EXTRA_DIST. So any *.vty test
added to the git source will both be run *and* included in distribution
tars implicitly.
Change-Id: I47c9011b5e0e2886d221e34e6aa281d1dd0495c7
The length parameter in rsl_imm_assign_cmd_common() may cause a buffer
overflow when it is chosen larger than GSM_MACBLOCK_LEN. Lets make sure
this cannot happen.
Change-Id: I9417b35fb8c0517f2555e17059bf8ac60fa59791
A new VTY test is coming up that includes testing the default codec-list
setting. The VTY tests are using osmo-bsc-minimal.cfg, so let's not
overwrite the compile time default for codec-list.
Also, there is no need to define a codec-list, so it is actually minimal
to omit it.
Change-Id: I01bee711f21023e2eab0688f45ff68f81afe1831
Comparing an array to null is not useful, since the test will
always evaluate as true (NO_EFFECT).
Change-Id: I8a41078070119bc22d594c0dfff5d98b5d16f970
Fixes: fbead4327 utils: store more fields from meas-feed in db
Fixes: CID#310821
The PCU is able to send OML alerts via the BTS to the BSC. When the PCU
operates in co-location to the BSC we just print the alerts in the log
directly
Change-Id: Id32553556356c2affe32e47ae1c3ae6a514efdce
Related: OS#5198
Move the check for the rate into an extra function, so it can be used
for CSD without checking a speech codec at the same time.
Related: OS#4393
Change-Id: Iea8a23ef3c66ed556110038fe9f3bc7f6eef3e96
Move the translation from osmo_sockaddr_to_str_and_uint into
bssmap_handle_ass_req_tp_rtp_addr, which will be used by
bssmap_handle_ass_req_ct_data in a future patch too.
Pass pointers to variables in req, instead of duplicating variables and
filling it in later (like in bssmap_handle_ass_req_ct_sign).
Related: OS#4393
Change-Id: I6bb16b26d89056dffa50bd8296fefe9315c587ca
Allow reusing common code in an upcoming bssmap_handle_ass_req_ct_data.
It won't use _osmux for now (maybe in the future?), but splitting it
out as well makes it consistent.
Related: OS#4393
Change-Id: I4d9a4df314b1e56b9c1f90c9d7914332b70b56f8
More fields need to be captured from meas-feed
to perform meaningful analysis of data from
multi-bts and multi-trx systems.
This patch adds expands the existing db utils
to record nearly all available fields from
meas-feed.
Change-Id: I509c939524b11a4ee455bcfc3ebee6c5c35b9fba
Remove "Helper function for match_codec_pref()" at the beginning of the
descriptions of these functions, looks like a leftover from before this
was moved to its own c file. Remove a duplicated "received" in a
comment.
Change-Id: I30f0744db9aebf2f05077fef840097c332b9dafd
tall_ctr_ctx is not defined or used in osmo-bsc and apparently was only
exported by accident from libosmocore. It's not exported anymore since
libosmocore.map was introduced in I13169c00a59fb59513dfc598de5a71d094492422.
Fix for:
/usr/bin/ld: osmo_bsc_main.o: in function `main':
osmo_bsc_main.c:(.text+0x830d): undefined reference to `tall_ctr_ctx'
/usr/bin/ld: osmo_bsc_main.c:(.text+0x8331): undefined reference to `tall_ctr_ctx'
Change-Id: I558e1ec722f3b1ff1f2e89b3cb97ed1dba9063e3
We have some macros that may at times have signed arguments, and at
other times unsigned. Checking for <= 0 is not a bug in this case.
Let's typecast any unsigned arguments to signed int to work around.
Change-Id: I10e60b20c6f8092cf1ce09ebe501e739fd4a9479
Closes: CID#272993, CID#272992 (and many others)
T23042 was a placeholder for timers to be filled in later. Replace it
with timers that can be configured via VTY.
Previous timeout for the states was 5s, from using the default of 5 for
undefined timers.
* ASSIGNMENT_ST_WAIT_MGW_ENDPOINT_TO_MSC and
HO_ST_WAIT_MGW_ENDPOINT_TO_MSC:
* Runs gscon_connect_mgw_to_msc() on enter, which waits for one MGCP
CRCX or MDCX response (or changes state immediately)
* Use existing X9 ("Timeout for availability of MGW endpoint"), 5s,
which is already being used by lchan_rtp_fsm for a similar purpose
* HO_ST_WAIT_RR_HO_DETECT:
* Handover initiation as described in 3GPP TS 04.08 § 3.4.4.1:
"The network initiates the handover procedure by sending a HANDOVER
COMMAND message to the mobile station on the main DCCH. It then
starts timer T3103."
* Use existing but unused timer T3103 ("Handover"), 5s
* HO_ST_WAIT_RR_HO_COMPLETE:
* Handover completion as described in 3GPP TS 04.08 § 3.4.4.3:
"When receiving the HANDOVER COMPLETE message, the network stops
timer T3103 and releases the old channels."
* Continue using T3103 with keep_timer = true
Closes: OS#5787
Change-Id: Id0d4d0788f609f3272fc81c80a754383dde25c16
Remove placeholder timer T23042. This handover fsm state waits for both
RSL/RR and RTP/MGW to be complete. I've added TTCN-3 tests to ensure
that both cases are covered by existing timer T3101 in lchan fsm state
LCHAN_ST_WAIT_RLL_RTP_ESTABLISH, which on timeout lets the handover
fail.
Related: OS#5787
Related: osmo-ttcn3-hacks I30e1811f97406cff6ba794fcd6882e2bb0205087
Related: osmo-ttcn3-hacks I2f79e3ff988a4315fbef3538f02403b818fa7839
Change-Id: I53468766c3c5fad7d7e275c0f20b5c20677fe4e8
Remove placeholder timer T23042.
Neels wrote:
> I think the right thing here is to remove this timeout; this needs
> no timeout at all because we can rely on the lchan_fsm to either
> return HO_EV_LCHAN_ACTIVE or HO_EV_LCHAN_ERROR after the usual
> timeouts set for lchan activation. IOW since it is internal to
> osmo-bsc one of the two events is guaranteed to occur.
>
> If we superimpose a timer on top of the lchan timeouts, configuring
> larger lchan activation timeouts becomes complex, because the user
> has to take care to also allow a larger timeout for the same
> procedure during HO.
Related: OS#5787
Change-Id: Ibf740aaa9bddc2de85cf8087ad90bab47aac12c2
In classic E1 based GSM networks the audio is usually transfered through
16bkps I.460 subslots while 4 16kbps subslots are multiplexed into one
E1 timeslot. However, there may be setups where still 16kbps subslots
are used, but with 1 instead of 4 channels per timeslot. In those cases
the bit offset is 0, while the rate is still 16kbps.
Change-Id: I0d2bc44acaa8e5a28cccfdf7cfb945bf14a4ed30
Related: OS#5198
osmo-bsc requires the PCU to tag IMMEDIATE ASSIGNMENTS that shall be
sent via PCU with a TLLI. This is required to confirm the sending of the
IMMEDIATE ASSIGNMENT messages to the PCU.
Related: OS#5198
Change-Id: Ib804143a57824632e5435f7ba68f2e94f5f3fb21
The BSC has all information about the E1 line configuration of each
timeslot/channel. The PCU is responsible for opening and managing the
CCU connection. To enable the CCU to do that, we have to transfer the E1
connection information (which TS, SS, rate) to the PCU.
Change-Id: I6d44373336b41009ff4c6e459d32d0a81081676c
Related: OS#5198
The PCU needs to be aware of the current system information in order to
work properly.
Change-Id: Ibbfbfaf588a4e406804c36570010aefdfc14328b
Related: OS#5198
We have introduced the function extract_paging_group() with the previous
patch. Lets use it for PCU_IF_SAPI_PCH as well to remove code
duplication
Change-Id: If4ffe8eafd2e54e323cbc075c09d457a74ebe83f
Related: OS#5198
The IMMEDIATE ASSIGNMENT for downlink TBFs needs to be sent through the
PCH instead of the AGCH. Since this method is not specified in RSL, it
is usually a vendor specific extension.
Change-Id: I4452f4973d1ec69c96aad527b057226e8a6edf99
Related: OS#5198
The current name of PCU_IF_SAPI_AGCH_DT is a bit misleading as it
describes a method to send immediate assignment messages (normally AGCH)
via the PCH. The name in the constant should reflect that correctly
Change-Id: I78abeb62d0267baa31a4727c4bdd027b7230f137
Related: OS#5198
The struct gsm_pcu_if_e1_ccu_ind is a bit misplaced. Lets move it next
to the info indication strucht, to have it in the same order is it used
in gsm_pcu_if
Change-Id: I41237c7847ab7a14ed2cd85dd32aabb3a6124a49
Related: OS#5198
A new VTY node was added in commit [1], but bsc_vty_go_parent() was
not updated. Because of that, commands following the MGW node may
crash osmo-bsc. In the example below:
network
network country code 901
mobile network code 70
...
mgw 0
remote-ip 127.0.0.1
local-ip 127.0.0.1
periodic location update 30
the 'periodic location update 30' will trigger a segfault:
(gdb) bt
#0 0x00005555555dfc09 in cfg_net_per_loc_upd ()
#1 0x00007ffff7af6c3f in cmd_execute_command_strict () from /usr/local/lib/libosmovty.so.9
#2 0x00007ffff7af6f1c in config_from_file () from /usr/local/lib/libosmovty.so.9
#3 0x00007ffff7afd4e1 in vty_read_config_filep () from /usr/local/lib/libosmovty.so.9
#4 0x00007ffff7afe375 in vty_read_config_file () from /usr/local/lib/libosmovty.so.9
#5 0x0000555555579616 in bsc_network_configure ()
#6 0x000055555557a352 in main ()
because vty->index would be NULL after returning from the MGW node.
Fix this by adding the missing case to bsc_vty_go_parent().
Change-Id: Id3050ff7e2402c33ee76c7bf0cc83603c0cc6dfc
Fixes: [1] 8d22e68706
The intended endienaess for the remote_port member is host byte order,
while the endianess in the nsvc struct is in network byte order.
(see also pcu_sock.c in osmo-bts.git)
Change-Id: Ib62dcceb80fd500e477dd5e1a0e43de47e16eeb0
Related: OS#5198
osmo-pcu will also support GPRS via E1 timeslots in a BSC co-located
setup. To avoid duplicate configuration the BSC has to communicate the
E1 parameters (which TS, SS etc.) to the PCU. Lets add a new primitive
to do that.
Change-Id: I3a0f6ae6b98694458230d7c0ac2c89b332cfbc92
Related: OS#5198
The Ericsson RBS is a BTS that natively works with dynamic timeslots.
This colides with the current understanding of static PDCH channels
because the BTSs we support so far get thier static PDCH information on
startup and then handle everything related internally. The BSC does not
actively manage the channel in those cases. In the case of Ericsson we
have to activate the PDCH via RSL like any other channel and the timeslot
FSM has to manage it. Lets not add work arouds for this, lets just print
and error message and use the BTS in the dynamic scheme as intended by
the manufacturer.
Change-Id: Icc7c2956fc934691e3bfacb283d896a8767baf27
Related: OS#5198
Before filling in the TS in the info indication, it is checked that the
MO opstate is enabled. Also it is checked that the TS serves a PDCH.
Lets restructure this check and move the PDCH check into a helper
function as we need to check for PDCH from other location as well later.
Change-Id: Icaab52ab73c38889dfadb523b89bb54cafacc99a
Related: OS#5198
We send the TS_EV_OML_READY event early, even though the TRX is not
fully done with all OML initialization steps. Lets complete the TRX
initialization first and then notify each timeslot FSM with
TS_EV_OML_READY.
Change-Id: If5251b102c8aa45dfc8cc4ee4e0223d7dc438938
Make sure that the TRX MO state is enabled and unlocked before filling
in any TRX information into the info indication
Change-Id: I7a93826e6b0df187425310cb82854e7d7fb47e72
Related: OS#5198
Make 'apply-config-file' check the neighbor config, just as is done after config parsing on startup
Related: OS#5866
Change-Id: I24ae8cd7e5e0d15eab9fd04b1858072bf0bad36a
The function pcu_tx_info_ind() fills the trx information in the info
indication. Since the function is already quite long, move the trx
related part into a sperate helper function.
Change-Id: Ic30185c9364adcc61d0a9d3483b0550ac1cdf894
Related: OS#5198
The pcuif only supports a limited but sufficient number of TRXs. When
filling in the TRX array in info_ind, we must guard against overflowing
the maximum number of TRXs
Change-Id: I351080a112f3d3fdf833ee7fa0d77c4cd1d13e42
Related: OS#5198
The formula that is used to recover the (relative) frame number from the
T1, T2, T3 parameters matches the definition in the spec, but since the
partial term t3-t2 can be negative special precaution is required when
performing the MOD 26 operation. This is due to the truncated modulo
implementation in C/C++, which has a very specific understanding on how
to deal with negative input parameters.
The libosmocore gsm_gsmtime2fn(() offers a correct implementation, so
lets use it.
Change-Id: I5fb2b0ada8d409730ac22963741fb4ab0026abdd
Related: OS#5198
The function trx_get_hlayer1() is defined as a prototype but it is not
used anywhere and there is also no implementation, lets drop it.
Related: OS#5198
Change-Id: I91ead9379140e971ccabc83cbf2b62b8aa1fc8a2
The (relative) frame number that is forwarded to the PCU is an
important parameter which is computed from t1,t3,t2.
Change-Id: I83d20ba9e0ce6488d458ccf4a85c8445c30e3a89
When a CHAN RQD is received via RSL, we show ra and other parameters.
Lets also show T1, T3 and T2.
Change-Id: I78499b49ae176b736e384e193fadc0bdd669dffa
The frame number calculation in rsl_rx_pchan_rqd() is done using a
specific formula. Lets add a spec reference and also restructure the
code a bit.
Change-Id: I60500c8694dbc2e6e2c4bbffd4ff7057bbc324e6
TTCN3 have been improved in osmo-ttcn3-hacks.git Change-Id
I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54 to use valid l3 data.
Related: SYS#6280
Change-Id: I4918f1741d465abf8b06a9c65199a44b09778299
IMEI may be used as MobileIdentity during MO emergency call
establishment if the MS has no valid IMSI assigned.
Related: OS#5849
Change-Id: I586b1ee30cbb26ddf58788168d56c962e03ccd5c
The second NSVC MO has been explicit skipped and never been interacted with.
osmo-bts is already supporting it for a long time as well the PCU is
supporting it at least since the NS2 code migration.
Fixes the ttcn3 test case BTS_Tests.TC_pcu_socket_two_nsvc.
Closes: OS#5835
Change-Id: I3486a7cc9a424602b73f8adc2fefce169213e46b
It was found in a BSC on the field that an MS sending an incorrect
MobileIdentity IE (wrong length) in PagingResponse was generating a
crash on the BSC.
When the MobileIdentity cannot be parsed right now we keep on instead of
rejecting the conn. This should change in the future, but it needs
further improvements in our TTCN3 tests. For now let's simply validate
the subscriber is not NULL; since recently paging optimizations made
paging_request_stop() require the subscriber to be non-null.
Fixes: 27cb5d3e24
Related: SYS#6280
Change-Id: If8b439ff74c5dd690d637d3e3278c75d6cd6b928
In send_assignment_complete(), obviously return the current channel
configuration from lchan->current_ch_mode_rate, which is the proper
place to get the channel mode after RSL Chan Activ Ack.
It is interesting to look at the history of this line of code.
lchan->current_ch_mode_rate was added later, so now the mistake is very
obvious.
Related: SYS#6229
Change-Id: I3bf8f5ea9ae2a3c12fc5b483818d550a069fe66e
The array of trx in gsm_pcu_if_info_ind can hold trx 8 items. Lets use a
define constant to specify the size of that array.
Change-Id: I25a9233e7be2d7cda8eb45a4cb9dddd3511d03c9
This patch caches the counts of initial paging requests for each paging
group. This count is needed to estimate T3113 when a new incoming paging
request is received and it has to be inserted into the queue.
With this there's no need to traverse the whole initial_req_list every
time a new incoming paging request is receiving, potentially saving lots
of iteration and hence lots of CPU when the queue is long.
Related: SYS#6200
Change-Id: I6994127827d120a0b4dd3de51e1ddde39f2fe531
If queue size (in transmit delay of requests) is too long (above
threshold) when a new initial incoming request arrives, instead of
directly discarding it, see if we can drop a pending retransmission and
insert the new one instead, in order to avoid losing initial requests.
This is done under the assumption that it is more important to transmit
intial requests than to retransmit already transmitted ones. The
rationale is that there's lower chances that an MS which didn't answer
lately will answer now (aka being reachable at the cell), so it's better
to allocate resources for new requests (new MS) which may be available
in the cell.
Change-Id: Idfd93254ae456b1ee08416e05479488299dd063d
Related: OS#5552
Initial requests: paging requests which haven't been yet transmitted
Retrans requests: paging requests which have already been transmitted at
least once.
Until now one queue was used (llist) to store both. The initial requests
were stored at the start of the queue in FIFO order. After the last
initial requests, the retrans requests followed also in FIFO.
This ordering was used in order to prioritze scheduling of initial
paging requests over retransmit paging requests.
In the end, having both types in the same list only make code handling
the list more complex.
Hence, this patch splits the shared llist into 2 llists.
Related: SYS#6200
Change-Id: Ib68f2169e3790aea4ac77ec20ad79f242b7c2747
When adding a new incoming request (aka "initial_req"), if the queue is
full only of retransmis (no not-yet-ever-transmitted initial requests
queued), then the new incoming request is inserted at the start of the
queue, in order to take scheduling priority over retransmits.
This was already fine before this patch, but the counting of requests
before it (used to calculate its T3113) was wrong, because it counted all
the retransmissions. This patch fixes it to end up with
reqs_before(_same_group)=0.
Change-Id: Ib2e810b0bcc51eac117713584310272462c58867
This allows configuring the maximum delay of paging requests to be
queued according to other parameters, such as MSC paging request
timeouts, etc.
Related: OS#5552
Change-Id: Ia556ef4e474e6a2d0d1618bab680a3330a3c062b
The default is to have a dynamic T3113. However, if the user wished to
set it statically, it would show up when writing the current VTY config.
Change-Id: If121a97bbb4a0234a0c162ef37c3692d6408404d
The BTS can be obtained easily from the backpointer in req->bts. Having
the extra param can only lead to confusion and introduction of bugs, as
happened in bug fixed by Change-Id
I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679.
Related: SYS#6200
Change-Id: I545fd853fdffce7f23f0d99203c66c3b39144e4b
When rewriting the loop, the pointer passed all the time to
paging_remove_request() was the one of the BTS which answered the
request, not the one actually handling the related unanwared still
active paging request.
Fixes: 70a1d60a83
Related: SYS#6200
Change-Id: I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679
This allows tracking each BTS active paging request queue length over
time, and evaluate CPU load based on the number of active paging
requests queued.
Related: SYS#6200
Change-Id: I6d296cdeba1392ef95fc31f6c04210c73f1b23e5
This way all paging related stats can be grouped (more will be added in
follow-up commits).
Related: SYS#6200
Change-Id: Iede1b6f68df468c7a3b3bf5fce7f68bb08b78832
Use spaces around equals signs inside structs, as expected from the
kernel coding style we mostly follow.
Neels wrote:
> IIUC "T=123" without spaces is my personal favorite that goes against
> the accepted linter standard, i guess rather than everyone else
> adapting to my weird style, i should start adding spaces in my
> patches.
Change-Id: I01ce986a1b0cdd74d945a04ae62a07f2850d366f
Neels wrote:
> i guess we can drop this comment now, it is a remnant from separating
> osmo-nitb -> osmo-bsc + osmo-ms
Change-Id: I2ce4d691715c1ea5c7c7896693a03b0aefbdb5b9
Prior to this patch the whole paging queue of each BTS was iterated.
After the patch only the active paging_req for a given subscriber are
iterated.
Related: SYS#6200
Change-Id: I225d5e08427c6bb9d92ce6a1dccb6ce36053eab5
This is triggered by BSC_Tests.TC_lcs_loc_req_no_subscriber.
Before, the NULL ptr was not a problem because paging_request_cancel()
only used the pointer to compare it against other pointers, but never
accessing it. A follow-up patch is, however, changing the implementation
to optimize the lookup by using the subscriber pointer, which generates
a crash.
Related: SYS#6200
Change-Id: Id0de43ac5bde0f52f258de6c9bf58b173301c8db
Before this patch, the entire queue of paging_request had to be iterated
in order to find if the subscriber already had an active paging request
(discarding duplicates).
Now that bsc_subscriber holds a list of its active paging requests, it's
easier to look at its list to find out if it is already active on that
BTS.
As a result, there's no need to unconditionally iterate the whole list
and we can optimize the loop finding the spot to insert the new queue:
- First the potentially way smaller loop over
bsub->active_paging_requests is done
- Second, only if the first loop allowed, the bts->pending_requests is
iterated and potentially early terminated.
Related: SYS#6200
Change-Id: I7912275026c4d4983269c8870aa5565c93277c5a
This allows havily decreasing the algorithmic cost of removing all
pending active paging requests for a given subscriber once it answers
on a given BTS.
Beforehand, the whole paging queue of all BTS were iterated. Now, only
the active requests for that subscriber are iterated.
Related: SYS#6200
Change-Id: I831d0fe01d7812c34500362b90f47cd65645b666
This saves the BSC from iterating twice the whole paging list of the BTS
which received the paging response.
Related: SYS#6200
Change-Id: I5f9215f31428ce0249cd9ece6d2d4e93155f429f
Prevent BSC overloading in the event of too many BTS try to connect.
E.g. a network outage between the BSC and BTS.
The BSC will accept incoming OML connection, but will delay sending
any BSC originated messages.
Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
Unfortunately "-std=c99" is not sufficient to make gcc ignore cold that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: Ic92aa70d569778a776f4c5d24c455f71fd50b61b
The number of NSVCs is fixed but lets not use magic numbers to define
the sizes of the arrays that hold the config values. In osmo-pcu there
is already a define constant, so lets use a define here as well.
Change-Id: Ic94dadd3374c6db9323baca83b6b07b89e96768c
The function rsl_ericsson_imm_assign_cmd has a comment "Chapter 8.5.6"
above it. However, thats only half true. The function implements
ericsson vendor specific RSL IEs, so lets be more clear about this in
the spec reference.
Change-Id: Id27662e208ca8ac0a48851583c11fbacf85f988c
When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't
treat the BCCH channel list as one list sorted by ascending ARFCN.
Instead, treat it as two sub lists, one for the same band, and one for
channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20.
This fixes getting the wrong ARFCN from measurement reports in
multi-band BSS, which leads to failing handovers.
Fixes: OS#5717
Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286
Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
Add a test that shows that the ARFCN of neighbors from the measurement
report is not parsed correctly for multi-band BSS. A follow-up patch
fixes it.
Related: OS#5717
Change-Id: Ie18e341f236bab5cf60d3a342c15c96cc848a7c2
In SCCPlite, the BSC receives the CN-side MGCP from the MSC through an
IPA conn, and it then forwards those messages to its co-located MGW
through a rawUDP socket created at startup.
This forwarding UDP socket still relied exclusively on the "mgw.conf"
struct which was filled only by the old VTY interface which was been
deprecated lately.
This patch moves the mgw-pool setup before the msc setup so that if the
VTY config file still uses the old VTY, the single MGW is added to the
MGW pool through mgcp_client_pool_register_single(). It then simply
picks the first available MGW from the pool when creating the raw UDP
MGCP-forwarding socket.
This means SCCPLite is still left with supporting only 1 MGW. If more
than one MGW is defined in the pool, then when the call is being set up
a different MGW could be picked from the pool while the CN-side MGCP
would still be sent to the MGW pool selected at osm-bsc startup.
This limitation coul be removed later on by adding a new VTY command
under the "msc" to pin calls for an MSC to an MGW with a given "mgw_nr"
from the pool, and that same MGW be looked for in the pool every time a
new call is being established.
Another possibility would be to avoid creating the "connected" UDP
socket at osmo-bsc startup, and rather use it in non-connected mode and
transmit (sendto) using the mgcp_client remote address during call
establishment.
In any case, this is left as future excercise since so far there hasn't
been any need for multiple MGWs in SCCPLite setups.
Related: SYS#5987
Change-Id: If105dee52b8d36161c759f979eaef4579b47d365
Commit 53b23c252e introduced a weird line
duplication that instead should have been the way this patch does it.
Change-Id: I5a9a983bb6135059ec01edf054ea3f7165bb6a6f
The adoc file has been moved to osmo-gsm-manuals.git so that it can be
included by other apps supporting MGW pooling from libosmo-mgcp-client,
such as osmo-msc and osmo-hnbgw.
Related: SYS#5987
Depends: osmo-gsm-manuals.git Change-Id Ieda0d4bfe6fc90da6e19c791d8ec2da89427ba3b
Change-Id: Icaee61905fbefe4632b562603fce393b70a114b1
This is a preparation commit before moving mgwpool.adoc to a share place
(osmo-gsm-manuals.adoc) so that other apps like osmo-msc and osmo-hnbgw
can also include this section.
Related: SYS#5987
Change-Id: Id0d292506e8b2a888c8d7a682a38db80e9d0933a
New VTY commands have been added recently to the "mgw" node which drop
the redundant "mgw" prefix on each fo them.
Depends: osmo-mgw.git Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484
Related: SYS#5987
Change-Id: I71e49cb4d6c2fe54a895aab0b0ba5acc4e57c253
Let's avoid guiding users towards the old deprecated VTY interface.
Line "mgw endpoint-range" is removed since it's nowadays deprected and
implemented as a NOOP.
Related: SYS#5987
Change-Id: Iff74a9efca2a0a2c38d5ac39df704b2b211fd906
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Change-Id: Ib2f04d96ca846d2d61af0b0c0ea1924609004952
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5
This feature allows pinning each BTS to a specific MGW from the
configured pool. The pinning can be soft or hard (strict). If strict
pinning is not set, the configured MGW is selected with priority, but
other MGWs can still be selected during each call setup if the
preferred MGW is found not available at that time, hence avoiding denial
of service for the entire BTS if that MGW goes down.
If strict mode is selected, the call will be refused if the configured
preferred MGW is not available at the time the call is set up.
It is useful to use this feature when Osmux is configured between
the BTS and the BSC and an MGW pool is in use. This way the BSC is
capable of grouping all the calls of a BTS towards one MGW, hence taking
advantage of the Osmux trunking optimizations to reduce link data usage
(AMR payload of several concurrent calls ending up sharing the same
underlaying UPD packet).
Furthermore, this allows the operator to intelligently spread load over
the MGW pool in order to avoid ending up with more than 256 concurrent
Osmux circuits on any of the co-located MGWs in the pool (maximum supported
at the moment).
Related: SYS#5987
Depends: osmo-mgw.git 5d8b5b093595e1203e288c3175c163c0994b1102
Change-Id: I9a7a5af72795faed0d12d9d73b59951b6a0e9c7d
The CHAN REQ entry is not deleted after its information was passed on to
the PCU. This causes the same entry to be used over and over again while
blocking other incoming CHAN RQD.
Change-Id: Ia4abc55fc6fcb1c00991cc84d09529131d014910
Related: OS#5198
There's no need to fail, simply make it a noop in that case,
everything's fine and everybody is happy (specially when using CTRL
command "apply-config-file" to load a .cfg file containing
modifications.
Related: SYS#6138
Change-Id: Ia4e70d20d48a28c46a21dd10358577e5c798744c
Current organization is totally mess, there's actually no organization
at all for lots of commands.
Let's organize most commands based on CTRL node where they are applied:
global, bts, trx, etc.
Specific set of commands such as neighbor-related, rf-related, etc.
are left in separate files as subsections inside the same node, so the
hierarchy is still clear.
Change-Id: I51a9b31780a4a8026aafb2d732369cdc10c8bb70
There exists a VTY command for sending default power control params,
but so far there was no CTRL counterpart for it. This patch adds a
SET command 'send-power-control-defaults':
$ osmo_ctrl.py \
--host 127.0.0.1 -p 4249 \
--set "bts.0.send-power-control-defaults" 1
Similar to 'send-new-system-informations', this command takes an
arbitrary dummy value (required for SET), which is simply ignored.
Change-Id: Ib370bd97ee2d9f72f8bec553550b1792d1345387
Related: SYS#6138
in osmo-pcu, the message buffer in pcu_sock_read is allocated with 1000
bytes in addition to the true size of the pcu_prim struct. Presumably
this is to avoid compatibility problems in case the primitives slightly
grow due to appending new struct members. Lets do the same in osmo-bts.
Change-Id: I99f5204b0563f72f9da427bb7aa5451552d8c5b5
Related: OS#5198
The pcu_sock interface in osmo-bts does check the size of the primitives
it receives. Lets do the same in osmo-bsc as well.
Change-Id: I247c6f4b5a7a22d17a060a558c4ceb9221ca7351
Related: OS#5198
We expect osmo-bts to provide us with a remote CID in order to be able
to set up MGW to send Osmux frames to it.
Related: SYS#5987
Change-Id: Ia90e8e0d18193d64c0fa0788dbd0eb242a359b61
the shared code in libbsc checks for sane config being set, but this
doesn't really apply to ipaccess-config, wihich doesn't set such config
fields internally.
Change-Id: I22ff0d22d6dcf9b0f715bfa4e0daeb52c4028308
Until now Osmux was selected unconditionally in bss-side CRCX, without
checking if the codec was AMR or not. If Osmux use policy is "on", we
only want to request Osmux use if AMR codec is selected.
Change-Id: I3f53555dd9608f1337365e4f82b492bdf1da05bb
ipaccess-config sets up the entire line in a fake way.
That requires also setting the fd of each TS used to -1 in order to
avoid library code interacting with it during tear down if an error
occurs.
Change-Id: I19eb23a46f89b96dd8d63742ca2078ecd5c9ab6b
Since this is created by osmo-bsc, it is also expected to be there by
ipaccess_drop_oml() in the shared libbsc code. But ipaccess-config was
not creating it, so let's do so.
Let's explicitly assert this condition in the code path expecting the
pointer to be instantiated in shared code, to easily track related
issues in the future.
Change-Id: I3f63f6827f7c5d7a21ac125b7ca6b35244efbb65
nanoBTS waits until receiving OPSTART in order to establish the RSL
connection socket against BSC, hence we cannot wait until the socket is
established at the BSC in order to send the OPSTART.
Still this way we make sure the RSL CONNECT is acked before attempting
an OPSTART at the BSC.
Change-Id: Ief46bad5075b656c13d1f09a0724e33283148236
The LAC value currently configured is now printed as hexadecimal value
too.
It can still be entered as a decimal value in order to keep backward
compatibility, though the hexadecimal one is now preferred.
Related: OS#5631
Depends: libosmocore.git Ia2b7fbbf5502c28374c21dbff548232680da27d4
Change-Id: I9090d73ae9d39244b79b9dbafa1b164faebabc52
It makes no sense to have duplicate signals. Let's simply clean up
S_NM_IPACC_ACK and pass the required info for higher layers to do
whatever is needed based on the information.
This allows reusing same signal infrastructure for different types of
messages instead of having to implement new signals for each message
(which can be done at a higher point in the stack).
Change-Id: I18ae3d320d00077fc13bb9903903de2a17767302
pcu_sock_read() may not free the message buffer in case the recv
returned errno EAGAIN. This is already fixed in osmo-bts, lets fix it in
osmo-bsc as well.
Related: OS#5198
Change-Id: I49eda447fc1912c1f7f25ba07331cb84decf4548
By default systemd will execute service with root directory (or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it to 'osmocom' subdir of state directory (/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I5bf2991d8b6507337b864f4d3c43448e54633f37
There seems to be no way for this function to be called with NULL parameter despite unreproducible crash observed in the
past. Let's add assert to show this explicitly.
Fixes: OS#5551
Change-Id: I235bdd42ea82e7b5a1a40f437ca34c49ad239c48
This way it is a lot easier to find out how and when is an lchan
initialized, simply by looking at the lchan.h header, then seeing the
init function and grepping for it.
Change-Id: I043d1c2ee75d4d2a8b323b7960ee490e567f3865
It is really difficult right now to find out where all the different
stuff relative to operation and lifecycle of an lchan is. Let's move
everything to its own file to have all the related defines and logic
together.
Change-Id: Idd855d126c43ac6576c5f3ba7e0b8014127a65e1
This API has been available since 1.0.0, and we actually require
libosmocore >= 1.7.0 nowadays, so it's totally fine using the
libosmocore API and drops the local duplicate.
Change-Id: I95c59b31cf1b08e1d513b589ef386d2dd55f09a2
The OM2000 model does not have a separate bb_transc MO, however for
compatibilty reasons we have a virtual MO that just mirrors the state of
the TRX mo. We should mark it as [Virtual] in show trx to reflect this
to the user.
Change-Id: I0f5501f6fbc7ce6d5457676b16c7f93f70db5763
Related: OS#5101
In OM2000 a separate bb_trxc MO does not exist to archive better
compatibilty towards classic ABIS and its MOs. Let's mirror the nmstate of
the BB_TRANSC MO to the RCARRIER MO in order to make it look like if it
were present.
Change-Id: I4611d8af16a30725308bd527098b12a356bfde9f
Related: OS#5634
the function om2k_trx_s_done_onenter() updates the administrative state
of the TRX oml MO but it does not notify the update to other entities
using S_NM_STATECHG
Change-Id: Iabf9f3a1a345c5d53d9a4d02fa2d6d13ddfd86ae
Related: OS#5634
Thanks to manawyrm for pointing out that the comments of the file
actually contained the numeric codes for the CBCH variants, but the
cases in the switch statements were missing.
Change-Id: Id5b4da6838f9a34db39fff5c23ad18822cd3347b
The function update_op_state() updates the OML MO, but it does not
notify the update to other entities using S_NM_STATECHG
Change-Id: Id19c6beb2bc79c4db0ec07ef593aacb57fff8b75
Related: OS#5634
The switch-case in update_op_state() and update_mo_state() can be split
off into functions. This makes to code better readable.
Change-Id: I41f0d9d0d498f6f698c2c959baac50424f5ac317
Related: OS#5634
The om2k mo that is put into the nsd as reference to notify other
entities about the signal change can be const. Its only accessed
read-only (if at all) and also the API in abis_om2000.h suggests that
the om2k mo should be const.
Change-Id: Id0969d44855506af18974de1ea81105653920d2f
Related: OS#5634
The normal abis nm FSMs are sending S_NM_RUNNING_CHG signals that
include an object class to notify other entities about state changes.
This also includes paging.c, which only starts paging services when it
sees NM_OC_RADIO_CARRIER becoming enabled.
Change-Id: I305df5b2f962473e33e32484c42a79ff96e53e1a
Fixes: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
Related: OS#5634
In cases where the MGCP client endpoint FSM is terminating early the bsc
sbscr conn FSM receives the signal GSCON_EV_FORGET_MGW_ENDPOINT, which
then calls gscon_forget_mgw_endpoint(). However, this only nulls the
conn->user_plane->mgw_endpoint_ci_msc struct pointer, not the others.
This causes the assignment FSM to access
conn->assignment.created_ci_for_msc whle trying to initiate a DLCX. We
must make sure that when the MGCP client endpoint FSM dies, that all
other CI pointers that reference the same CI are also set to NULL.
Change-Id: Ia857e3af6c17282b7e8178b6d249eb0f99ed98e3
Related: OS#5572
It's of no use for the test. Furthemore, it was being created outside
the build direcory, being left there.
Change-Id: Iaeee14a01badb8439bc8893ba8be06b13e4318f3
As described in 3GPP TS 48.049:
7.8.2: "The RESTART message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
7.9.2: "The FAILURE message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
Related: SYS#5910
Change-Id: I6668b55868cf534a3b59da5e11542abb8131d604
Let's use CGI instead of LAC+CI, which contains only a subset of the
information.
Furthermore, It was noted that some third party (non-osmocom, non
open source) CBCs don't support/like receiving LAC+CI,
and expect to receive CGI instead.
Related: SYS#5910
Change-Id: I33a6216f89496484cbb3921609fcd3ab90761c69
When trying to build osmo-bsc using clang 14, I am getting this error:
make[3]: Entering directory 'src/osmo-bsc'
CCLD osmo-bsc
/usr/bin/ld: ./.libs/libbsc.a(handover_decision_2.o): undefined reference to symbol 'pow@@GLIBC_2.29'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [Makefile:656: osmo-bsc] Error 1
We need to link with the math library to resolve this.
Change-Id: I4137cad07a3343882ca77d5ebd5137083941dc11
GCC 12.1.0 emits -Wmaybe-uninitialized when building with '-O2'.
In function 'populate_ts_list',
inlined from 'lchan_avail_by_type' at src/osmo-bsc/lchan_select.c:356:2:
src/osmo-bsc/lchan_select.c:248:12: warning: 'chan_alloc_reverse' may be used
uninitialized [-Wmaybe-uninitialized]
248 | if (chan_alloc_reverse) {
| ^
src/osmo-bsc/lchan_select.c: In function 'lchan_avail_by_type':
src/osmo-bsc/lchan_select.c:326:14: note: 'chan_alloc_reverse' was declared here
326 | bool chan_alloc_reverse;
| ^~~~~~~~~~~~~~~~~~
This could only happen if in 'enum lchan_select_reason' we had items
that are not handled in lchan_avail_by_type(), but this is not the
case. Make GCC happy by initializing chan_alloc_reverse to false.
Change-Id: I3956621a6ec14ca5ff0ba0b11d2c956e2538efd8
This change implements an additional channel allocation mode, which
can be employed during a TCH channel allocation for assignment.
Selection between ascending and descending order is performed
depending on pre-configured parameters:
* Uplink RxLev threshold and number of samples for averaging,
* C0 (BCCH carrier) channel load threshold.
This is useful in setups where Tx power of the RF carriers cannot be
adjusted +dynamically at run-time and thus BS Power Control cannot
be performed. In such setups the BCCH carrier is transmitting at
relatively higher power than the other RF carriers. The key idea
is to allocate channels in a smarter way, so that UEs with poor signal
would get channels on carriers with high Tx power, while UEs with good
signal could use carriers with lower Tx power.
Change-Id: I1b7a0d706976b73cc5c30a8714b830811addfe8d
Related: osmo-ttcn3-hacks.git Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
A follow-up patch implements a special channel allocation mode, which is
only working for assignment (basically TCH selection for a voice call).
This mode cannot be employed for initial CHANNEL REQUEST or handover due
to the absence of an already established lchan.
Adding this mode to the existing VTY command syntax would be confusing:
channel allocator (ascending|desscending|dynamic)
^^^^^^^
so this patch extends the VTY syntax in a way that it becomes possible
to configure different channel allocator modes for different cases:
OsmoBSC(config-net-bts)# channel allocator mode ?
set-all Set a single mode for all variants
chan-req Channel allocation for CHANNEL REQUEST (RACH)
assignment Channel allocation for assignment
handover Channel allocation for handover
The old command syntax, which is basically 'set-all', is kept for
backwards compatibility, but marked as deprecated.
Change-Id: I3ae73b36ee9433cc768376b56f0765e5f416162f
Related: SYS#5460
The lchan_avail_by_type() attempts to find an unused lchan for the
given GSM_LCHAN_* value: TCH/F, TCH/H, or SDCCH. This is achieved
by looking up timeslots with compatible GSM_PCHAN_* values.
For instance, finding an unused SDCCH lchan may involve:
* attempt to find a timeslot with pchan=GSM_PCHAN_CCCH_SDCCH4,
* attempt to find a timeslot with pchan=GSM_PCHAN_CCCH_SDCCH4_CBCH,
* attempt to find a timeslot with pchan=GSM_PCHAN_SDCCH8_SACCH8C,
* attempt to find a timeslot with pchan=GSM_PCHAN_SDCCH8_SACCH8C_CBCH,
* attempt to find a timeslot with pchan=GSM_PCHAN_OSMO_DYN (switched),
* attempt to find a timeslot with pchan=GSM_PCHAN_OSMO_DYN (not switched).
Each attempt involves iterating over all timeslots of each TRX,
either in ascending or in descending order (see _lc_dyn_find_bts()
and _lc_find_trx()).
This patch simplifies the lookup logic by preparing a monolithic
array of timeslot pointers once, and then using that array for
each GSM_PCHAN_* lookup attempt. This change is required for the
upcoming dynamic channel allocation mode, which is fa more complex
than the existing ascending/descending ones.
A side effect of this change is that the interference aware mode
of allocation is not limited by the scope of a single TRX anymore.
Interference levels are now compared within the scope of the whole
BTS, so that lchans on the other TRXes may be picked if they are
better according to the interference reports from the BTS.
Change-Id: I7ccc56856bfd40fd7c63b7437736de60c2b516ff
Related: SYS#5460
Let's decrease the logging since it's fine simply discarding the message
if the link is down. This way all code sending messages doesn't need to
care about the link state.
Change-Id: I64356ec6a7b3a4e11a0e66b17efab2788b1ca5cc
osmo_bssap_le_dec() dereferences value of the given pointer and
checks it against NULL. The caller must always initialize it.
Change-Id: Idb0e6565e362ce383c833d6bfec4fb39d2985a6b
Fixes: CID#272982, CID#272944
Found by clang:
warning: implicit conversion from enumeration type
'enum lchan_activate_for' to different enumeration type
'enum assign_for' [-Wenum-conversion]
This is indeed a bug, because both enum items have different values:
* ACTIVATE_FOR_VTY (from enum lchan_activate_for) is 4,
* ASSIGN_FOR_VTY (from enum assign_for) is 3.
Change-Id: I44544d4577833e0aed62b07d0c7c1c2821b05dd4
Fault Reports are commonly oberved with a TLV id 0xd2
as are reports with up to 20 TLVs.
Let's not have these cause logging at level ERROR.
Closes: OS#5593
Change-Id: Ibe0b38835362c59d1576a206b2f64cea4427295f
Current regex 'handover' is way too restrictive because it completely
forbids the use of word 'handover'. Adding new VTY commands with this
word in the syntax makes this VTY test fail.
Use regex '^\s+handover', which only matches lines starting with
some whitespace and the word 'handover'. Lines simply containing
the word 'handover' will be ignored.
Change-Id: I8a1550c6c97437832e05b6b4bebbcc33c2fa3d46
Related: SYS#5460
This brings our README in line with the various other osmo-*
projects such as osmo-bts:
* use markdown formatting
* links to mailing list, documentation, git repo, ...
* reference the method of contribution + code review
Change-Id: I201bf47550a8fea500925205e0de1060d58d6136
This way the CBSP peers knows the state of specific cells and can avoid
sending messages to unoperative ones, etc.
Related: SYS#5910
Change-Id: I94f0a1ac3c59cffe5af57f972d5d96fc92281d34
When calculating average lchan duration based on the new stats for
BTS_CTR_CHAN_{TCH,SDCCH}_ACTIVE_MILLISECONDS_TOTAL there are
discrepancies which emerge. Specificially in bandwidth-constrained
environments, there are still-unknown failure states which can
occur that cause the TCH or SDCCH activity count to increment but
zero milliseconds of activity on the lchan to accumulate. This
portrays a failure as a success.
These new fully-established stats are intended to provide a more
accurate denominator when calculating average lchan duration as
they are incremented in proximity to the duration timestamp
initialization.
Change-Id: I417940ad9479719f5324fb12d45883cd3cb2c578
This allows running CBCH/ETWS related procedures only when the CBCH
towards MS under that cell is operative.
This also allows providing awarness of per-cell status to the CBSP peer
as required per specs.
Related: SYS#5910
Change-Id: Ia93919be94132fc010acb5bbfef0a6fd51c42981
For statistical clarity and site tuning, it is sometimes
desirable to completely disable the use of TCH for signaling.
In the existing version of this VTY command, there is no way to
accomplish this. We can only restrict TCH for signaling non-voice
related actions.
This patch deprecates 'allow-tch-for-signalling (0|1)' and
adds 'tch-signalling-policy (never|emergency|voice|always)' to
provide more options.
Change-Id: I4459941ddad4e4a3bec8409b180d9a23a735e640
This way we separate all the VTY boilerplate from the actual logic, as
we usually do in all other subsystems.
Change-Id: Ifc7d1693d745dd2a3c31e3ee9610d8c634b50812
Drop "to this MSC" from the NRI_STR, as it is not only used for MSC
specific configuration, but also in cfg_net_nri_* which affect all MSCs.
Drop "for this MSC" from the description of cfg_net_nri_null_del, it
affects all MSCs (unlike cfg_msc_nri_del).
Change-Id: Ic8888775a965b6d607af51b9359bd8ffc2834e16
The all_allocated_update_bsc() does inefficient iterating to count
active/inactive lchans, which scales badly for high numbers of TRX
managed by osmo-bsc.
We need to update the all_allocated flags immediately (periodic counting
alone would suffer from undersampling), so, until now, we are calling
this inefficient function every time a channel state changes.
Instead of iterating all channels for any chan state changes anywhere,
keep global state of the current channel counts, and on channel state
change only update those ts, trx, bts counts that actually change.
A desirable side effect: for connection stats and handover decision 2,
we can now also use the globally updated channel counts and save a bunch
of inefficient iterations.
To get accurate channel counts at all times, spread around some
chan_counts_ts_update() calls in pivotal places. It re-counts the given
timeslot and cascades counter changes, iff required.
Just in case I missed some channel accounting, still run an inefficient
iterating count regularly that detects errors, logs them and fixes them.
No real harm done if such error appears. None show in ttcn3 BSC_Tests.
It is fine to do the inefficient iteration once per second; channel
state changes can realistically happen hundreds of times per second.
Related: SYS#5976
Change-Id: I580bfae329aac8d4552723164741536af6512011
Reduce some code dup in all_allocated accounting and cosmetically
prepare for upcoming performance fix.
Have a struct all_allocated, allow easy re-use of function
all_allocated_update().
Rename function to all_allocated_update_bsc(). Upcoming patch will also
add all_allocated_update_bts().
Related: SYS#5976
Change-Id: Id7a82c65d56a87818fc35bbeedf67e2af2f89f11
ts_is_usable() returns the current state; logging is the job of calling
functions. An upcoming patch adds some calls to ts_is_usable(), this
avoids the log flaring up with useless messages.
Related: SYS#5976
Change-Id: I0635c47609fd7c7d0195b6658b7da231d6527b4b
It was described in [1] that the NM FSM failed to trigger the
S_NM_RUNNNG_CHG signal when locking/unlocking the TRX.
That's because current osmo-bts doesn't fully conform to TS 52.021 and
it doesn't go back to Op=Disabled Avail=Dependency when becoming
Admin=Locked. It's true though that TS 52.021 sec 5.3.1 is not really
helpful since it doesn't explicitly state that specific object should go
into Disabled Dependency, despite saying it for most of the other ones.
Hence, let's account for both possibilities at the BSC side.
[1] https://gerrit.osmocom.org/c/osmo-bsc/+/28205
Related: OS#5576
Change-Id: Ifbdc066fd88bdbf826800d14524e74416815b625
Since b7ef6884f9, the state is updated
before triggering the signal S_NM_STATECHG, so the warning does no
longer hold true.
Change-Id: I7b7dd30b4fcdc92febca42e3e6a75e6f98e184ff
Add missing conn->assignment.created_ci_for_msc to
gscon_forget_mgw_endpoint_ci().
Before this patch, when assignment.created_ci_for_msc lingers after a
DLCX, it can cause a use-after-free on assignment_reset(). Possible
scenario is rx BSSMAP Clear Cmd during ongoing Assignment.
In assignment_reset(), locally cache the ci pointer, because
gscon_forget_mgw_endpoint_ci() now NULLs created_ci_for_msc.
Related: OS#5572
Change-Id: If89610020f47fd6517081dd11b83911b043bd0f1
VAMOS lchans are behind the primary ones in the ts->lchan[] array.
For example, for TCH/F, there is a primary ts->lchan[0] and a VAMOS
ts->lchan[1]. We should print 'ss 0' for both of them.
Change-Id: I8e7a5a2ecc9b9a33e3ddb76cb1bc04d7802fd320
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: Ie3771233ecbd4bc24a24fb22c1064a18e7b8b2b0
As per TS 48.049 Table 8.1.3.1.1 the WRITE-REPLACE message always
has a Warning Security Information IE if it relates to ETWS. This
is also implemented in the libosmocore CBSP parser.
As the previous Change Id369bb3676ba279bafc234378fbe21dbc7b0614b has
pointed out, the CBSP parser structure doesn't even permit any way
of handing a decoded message to us without the warning_sec_info
static struct member.
So as a result, there's also no need to dynamically allocate
bts_etws_state.input.sec_info via talloc. We can have it in-line
as a static struct member and reduce code complexity and runtime
memory allocations.
Change-Id: Ib1b8e4af37b1f9f9398b81dad29942e82218c70b
The proper way to fix this is having a use count on the SCCP conn, one
each for a busy lchan and a busy Location Request. That would require a
bunch more work and testing.
This patch is the least-effort way to avoid the following scenario:
Emergency call is started;
Location Request is started to locate the emergency;
lchan releases early for any reason;
Perfectly fine Location Request gets canceled by Clear Request;
The information was there, but we did not forward the location;
No help at emergency because of my code.
Allow Location Request to complete for these cases:
- rx RLL REL IND (or any other reason for gscon_lchan_releasing())
- rx RSL CONN FAIL
Related: SYS#5912
Related: Idea690a4aa4aecbe4642a16e96d086cc0538564a (osmo-ttcn3-hacks)
Change-Id: Ib44dd05b0adee84234f671313b156ff6625357cc
ACC used to be stared/stopped based on operational/administrative state
changes. The new S_NM_RUNNING_CHG triggers a single boolean based on the
same logic, so we can now simplify the mechanism.
Change-Id: I2e09bcb18a6c3bb2e88bba98579fb4854a6b0699
This way we avoid triggering timers and doing extra poll loops for each
BTS which is configured but not up. It also has the effect of removing
logging about estimating paging buffers for BTS which are down, which
can be confusing.
Furthermore, since work is delayed until the TRX and cell in general is
configured, the first estimation is properly done now since the correct
configuration is in place at that time.
Related: SYS#5922
Change-Id: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
This allows different parts of the code to hook to some signals which
allow start/stopping processes based, for instance, on whether C0 is
available or not.
This can be later used by paging or CBSP code. Also ACC code can be
ported to this new system (acc_ramp_nm_sig_cb()).
Same signal can be used for other NM objects, but is left unimplemented
until there's use for them.
Change-Id: I206d4c7863a77fbab6a600126742a6a6b8fc3614
This way code triggered through signal has an updated view of the object
tree when running generic code which queries the current state of
objects.
This way for instance one can use APIs like trx_is_usable() or alike.
Change-Id: Ib46234e3f3e446e866d27b0dfee65edf4af4d2ba
Found by GCC 12.1.0:
smscb.c: In function 'etws_primary_to_bts':
smscb.c:537:13: warning: the comparison will always evaluate as 'true'
for the address of 'warning_sec_info'
will never be NULL [-Waddress]
537 | if (wrepl->u.emergency.warning_sec_info) {
| ^~~~~
In file included from smscb.c:31:
/usr/local/include/osmocom/gsm/cbsp.h:99:33: note: 'warning_sec_info' declared here
99 | uint8_t warning_sec_info[50];
| ^~~~~~~~~~~~~~~~
Indeed, address of &warning_sec_info[0] is always not NULL.
Change-Id: Id369bb3676ba279bafc234378fbe21dbc7b0614b
Don't wait until RSL link goes up to check the reported features against
the config. Do it in the OML bring up right after the features are
reported.
Related: SYS#5922, OS#5538
Change-Id: I6b1b4ef3e163528ed186050d848ec089a4315a7c
Especially during emergencies / natural disasters, it is particularly
likely that networks become unreliable and BTSs disconnect and
reconnect. If upon reconnect there still is an active ETWS/PWS
emergency message active for this BTS, send it to the BTS to ensure
it re-starts broadcasting that message until disabled.
Change-Id: I175c33297c08e65bdbf38447e697e37f8a64d527
This reverts commit 5e2ac29703.
This patch was found to be a troublemaker regarding osmo-bsc
performance, since it's scheduling one timer every 100ms for each
channel. On a BSC with dozens of BTS, each with several TRX, this ends
up in a huge amount of timers scheduled in a tight timeframe, which ends
up in osmo-bsc spending CPU time getting in and out of the poll() main
loop.
Related: SYS#5922
Change-Id: Ibd5123e7f04ae8f4eb8f08b63525527f526f0b2c
This allows external monitoring to see where the T3113 timer has been
adjusted to, in case it is set dynamically.
Change-Id: I533f2ca3c8e66c143154cbf03b827c9cbbacccdf
Reaching this point will only make system load (CPU, mem) grow, making
it hard for the process to keep up with work to do, with no benefit
since the requests will anyway be scheduled too late.
Related: SYS#5922
Change-Id: I6523c6816a4d16b71084d004e979be40cf0aeeb0
In lchan_fsm_cleanup(), ensure that the time_cc timer is actually inactive
before deallocating. Do so via lchan_reset(), to also make sure the
timer is stopped in all other situations where the lchan is deactivated.
This fixes an infinite-loop deadlock as described in OS#5554:
- run BSC_Tests.TC_chan_act_ack_est_ind_noreply
- restart the BTS process after the test is done
- osmo-bsc enters infinite loop in osmo_timer_del()
The reason is that lchan_fsm_cleanup() fails to stop a running active_cc
timer upon lchan deallocation. TC_chan_act_ack_est_ind_noreply
incidentally terminates OML while the timer is still active.
Related: OS#5554
Change-Id: I901bb86a78d7d021c8efe751fd9d93e5956ac0e0
We have seen an increased CPU load in osmo-bsc recently since the paging
improvements where merged, centered round poll() calls.
It is expected most of them will be fixed with previous patch. In any
case, let's avoid unnecessary poll() calls being called for no reason.
Related: OS#5922
Change-Id: Ie767bdc8d4353aafe375a424e02d698ef7fd3dea
We want to recalculate the timer based on last time the work_timer was
triggered (that is, the time when the worker re-armed the pag req to
retransmit). We don't want to recalculate based on the last time the pag
ret tro retransmit was scheduled.
In loaded paging queue, there's lots of retrans (let's say 200) and it
may take more than 500ms to actually retransmit them. That means in most
cases we could end up in a situation where only pag req to retrans where
in the queue, hitting this recalculate path. Since the 500ms were for
sure elapsed, that would most probably schedule the work_timer at {0,0}
for each new paging request that arrived. As a result, the worker would
be scheduled lots of times per second (once for each new req arriving)
and only submitting 1 pag req (the new one) plus potentially 1 or
serveral pag req to retransmit.
In summary, there was not throthling applied in the scenario where only
pag req to retransmit where in the queue and new pag reqs kept arriving.
This incurrs into augmented paging throughput and also augmented
frequency of polls().
Related: OS#5922
Fixes: 4821c9f4df
Change-Id: I7ce6f436286b50dc31331d218ff256cf7be3f619
There's no need to use pointers there, it is only asking for errors from
code handling the data structe from the signal by attempting to change
them. Even for mem size point of view it doesn't make sense, since it's
3 byte vs a 4 byte pointer.
Furthermore, this is a preparation for new commit, where the NM object
current state will be updated before emitting the signal. This patch
eases a lot the follow up mentioned patch.
Change-Id: I9b648dfd8392b7b40bfe2b38f3345017481f5129
One callback function was being registered for each BTS.
That means, when a C0 RCARRIER of one specific BTS changed NM state,
the outcome on whether to trigger/abort ramping would end up being
applied to all BTS.
Change-Id: I56c4dd1809fdcf8441a69bf77ad173e1ccc8eea7
This makes sure code accessing those fields is not changing its values,
since it would make no sense to change those. Follow up commit will make
convert those pointers to be full structs instead, as there's no need to
have pointers there.
Change-Id: I9979e62eac861e25bbe2161ab187ddb2b40fd097
Having 2 signals makes all code handling them more complex, specially
because S_NM_STATE_CHG_OPER could actually provide any change in
admin/oper/availability.
Both signals already provided the same kind of data (the whole
admin/oper/avail state change), so let's simply merge the signals
themselves. Current code really doesn't act differently for those 2
signals anyway.
Change-Id: Ia86d20a42b859063d0327b940ba528ec1438b04a
This code is not used currently. Furthemore, it makes little sense to
transmit an OPSTART if the BTS already told us it is enabled (because
OPSTART is what moves the BTS into operational enabled state).
Change-Id: I2c65e0803fbde7de9497089b562275baad58936a
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347
So far we only calculated the expiration time based on the amount of
requests of the same paging group in the BSC queue.
However, also extra time has to be taken into account regarding requests
of other paging groups. This is important because requests of all paging
groups are mixed in the BSC queue, meaning having a lot of requests from
other groups before a certain req will anyway delay transmit of that
req to some extend.
Related: OS#5537
Change-Id: Ib55f947c5d3490b27e1d08d39392992919512f9a
This was so far workarounded in tests by manually freeing the fields.
However, in follow-up patch the paging queue will also be properly
freed, so free of the counters needs to be previously fixed too so that
counters are freed at the right point of time.
Otherwise, during paging queue flush, counters are used and would crash
because they were freed before the BTS object in each test's bts_del().
Change-Id: Id213e21cf9bfc5439021e459c22ba4704d8cae2b
Use the same one as used to decode the message in osmo-bts.
This patch doesn't cause a change in logic since both headers are binary
identical.
Change-Id: Ideb863fdaedf77caac1a320de6696ba4f507a398
* Don't copy features for osmo-bts and nanobts initially, wait until
BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
(not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again
Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
As pointed out in code review, for nanobts we need to be able to combine
the reported features with a list of features we assume that the bts
model supports. This is because the enum of features is based on what
nanobts is able to report, but was extended for osmo-bts.
Related: SYS#5922, OS#5538
Change-Id: I7bdbf28c148877275048e070dce7f503ca5e6226
If the queue is only holding requests in retransmition state, when we
add a new one, we have to re-calculate the work timer to a lower value
instead of letting it wait for the first retransmit to be ready.
Change-Id: Ibd4f8921c92f7481f0b9943041c141640ab812c8
There's no need to keep the timer running, since anyway upon next
trigger it will simply early exit in paging_handle_pending_requests()
becuase there's no more work to do.
Change-Id: I096ab7231f52c741c5fded37acd5b309e1de06e3
Before this patch, on each BTS a 500ms timer was used to schedule some
work, sending up to 20 paging requests verytime.
This means, however, for an initial paging request it may take up to
500ms delay to be scheduled to the BTS, which is huge.
While we still want to maintain this 500ms interval for retransmits, it
doesn't make sense to wait that much for other cases. It's far better
sending less requests (10 instead of 20) every half time (250ms instead
of 500ms), since it will spread the load and paging more over time,
allowing for other work to be done in the middle.
Change-Id: I7a1297452cc4734b6ee8c38fb94cf32f38d57c3d
PAging happens over C0 RSL link, not over OML, so let's actually
validate that the C0 RSL link is up before paging instead of the OML
one.
Change-Id: I11e5bb6f952534763935aa01470e514d4af247ed
Decouple credit_timer from event "available_slots became 0".
Let's actually relate credit_timer to the fact of not receiving CCCH
Load Indication: If no CCCH Load Indication is received (cch_load_ind_period * 2),
then assume we are below CCH Load Indication threshold (10% load) and
start estimating the available_slots in a cch_load_ind_period*2 time
frame.
Moreover, in paging_schedule_if_needed(), there's no use in delaying
start of processing work if the work_timer is not already doing work.
Related: OS#5537
Change-Id: I6a0da03c408270044079e81d431f6641527c00cd
From 3GPP TS 48.018:
If only the New Serial Number IE, and not the Old Serial Number IE, is
included in the WRITE-REPLACE message,then the BSC shall interpret the
message as a write request, i.e. a broadcast request of a new emergency
message without replacing an ongoing emergency message broadcast.
Only one emergency message at the time can be broadcasted in a cell. If
a write request is received for a cell where an emergency message
broadcast is currently ongoing, the write request is considered as
failed.
Change-Id: I376c9e796f3a2d26b22d0451f15ef1debbd7f656
Closes: OS#5539
Related: SYS#5906
So far, we only implemented KILL for CBS, but not for Emergency
broadcasts. This patch adds KILL support for Emergency, by which
a CBC can terminate broadcast of a previously-started Emergency
message before its scheduled period ends.
Change-Id: Ie91939b93de6847eeb5d00c97a137c43721c2711
Closes: OS#5540
Related: SYS#5906
ETWS is sent over both dedicated channels and broadcast channels.
Some BTS models may not support the latter, but it is still useful
to start the related timer to ensure bts->etws.active gets set to
false after the emergency period has concluded.
Change-Id: I448be9fd75b87c1f7333a5bfa4f6ba238569fdc3
Only if we store data like the CBSP message_id and serial_number
we are able to later (in a subsequent patch) match a CBSP KILL
for ETWS/PWS and stop emergency broadcast.
Change-Id: Ide74638880d7e3c6a7c774bf6320d3dce4b11c74
Related: OS#5540
TS 48.049 states the following rules for the KILL COMPLETE / FAILURE
messages:
The Number of Broadcasts Completed List IE, if present, contains for
each cell the total number of broadcasts of the killed CBS message.
The Cell List IE, if present, contains the cells in which the emergency
message is successfully terminated.
As any message can only be either emergency or CBS, this means that
we can (at maximum) have only one of those two IEs in the message.
As there is no explicit indication in the KILL whether it relates
to CBS or Emergency, we use the "Channel Indicator" IE, which is
specified as "only included if the message refers to a CBS message".
Related: SYS#5906
Closes: OS#5541
Change-Id: I9a43d386da01f085663d231a555b8b5acc99faca
With previous patch Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, the
features get copied from the BTS model to the BTS. For rbs2000, bs11 and
nokia_site, an empty feature set was copied because the features weren't
set at this point. Fix this by moving the set_feature calls to _init().
Notably the set_feature calls had been moved for osmo-bts and nanobts
from _start to _init already in 2013 in the patch e84dd98d
("sysmobts: Avoid a crash when trying to look-up a BTS").
Fixes: 2d818b9f ("Always use reported features if available")
Related: SYS#5922, OS#5538
Change-Id: I43389ae48d5e0f01381602751f6bad902011b158
When building with CFLAGS="-flto -Wall", I get the following:
meas_pcap2db.c: In function ‘pcap_cb’:
meas_pcap2db.c:64:27: warning: pointer targets in initialization of
‘const char *’ from ‘const u_char *’
{aka ‘const unsigned char *’} differ
in signedness [-Wpointer-sign]
64 | const char *cur = bytes;
Change-Id: I84d8e6f290bda0f03476f182f292ecc7a9e520f2
When building with CFLAGS="-flto -Wall", I get the following:
meas_db.c: In function ‘_insert_ud’:
meas_db.c:62:23: warning: unused variable ‘rowid’ [-Wunused-variable]
62 | unsigned long rowid;
meas_db.c: In function ‘meas_db_insert’:
meas_db.c:89:13: warning: unused variable ‘rc’ [-Wunused-variable]
89 | int rc;
meas_db.c: In function ‘check_create_tbl’:
meas_db.c:260:16: warning: unused variable ‘rc’ [-Wunused-variable]
260 | int i, rc;
Change-Id: Id12958f67a47b6b3ebece7252e4f7c0835d4bb96
Make sure we don't check against bts->model->features instead of
bts->features by accident.
Related: SYS#5922, OS#5538
Change-Id: I47eef4978aaf9e20fc00a3ca029568671bd09d8d
Instead of sometimes checking against hardcoded BTS model features, and
sometimes against features reported at runtime (which only some BTS
models do):
* copy the hardcoded BTS model features to BTS features initially
* do all checks against BTS features
Related: SYS#5922, OS#5538
Change-Id: Idf2d933aa8b03b1f708e56a08707fe6c620a97aa
Let all changes of the bts model go through this function, so we can in
a future patch copy over the bts model's features to the bts.
Related: SYS#5922, OS#5538
Change-Id: I8475c8c20eb72411e8ca820181d1c8603c22a56d
Just log all reported features, instead of comparing them against an
expected set of features and logging mismatches. The point of reporting
features from the BTS at runtime is that the BSC can support various BTS
versions with various feature sets.
Related: SYS#5922, OS#5538
Change-Id: Ibd79bc7ef802d8e95e05d746df182ff974b78e29
After the lchan release, the gscon would go into the Clear dance with an
arbitrary cause value. Instead, explicitly ask for a Clear upon
pre-emption, with the proper cause value.
Related: OS#5535
Change-Id: I20108f7b4769400b89b7b0d65c8dab883bf87c46
So far the we indicated pre-emption in the release cause of denying an
emergency setup, instead indicate protocol error.
When emergency calls are disallowed, it is not pre-emption (making room
for an emergency call) but a protocol error (MS asks for emergency call
when the network does not allow it).
Related: OS#5534
Change-Id: Ia195621165cb7bbe33e6c2e915abc42ab16a2a4f
The range used for this variable is 0-100, so no need to use a signed
integer. Morever, uint8_it is enough for the range.
Change-Id: I863d9531baf5308b45a2ebe60266ba02d1041cc3
Its name is totally misleading, since they seem to be related to
GetAttributes messages rather than SetAttributes.
Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
Currently, the Tx paging_req queue at the BSC always has new paging
requests adding at the end (as long as the subscriber is not already in
the queue).
That means, if the queue is full of retransmitions, it will take a long
time until the first paging_req is sent towards that subscriber.
The rationale here is that it makes sense to attempt the first paging
ASAP, and give lower prio to paging_req retransmitions, since it may
well be that those other subsribers are not available/reachable and
won't answer.
Related: SYS#5922
Change-Id: I1ae6d97152c458247bc538233b97c2d245196359
Having one paging request being sent every PAGING_TIMER (500msec) is too
slow in case BSC is serving lots of subscribers on a BTS. Hence, we want
to send many paging requests at once while still trying not to fill the
BTS buffer.
Morever, we don't want to send tons of paging requests at once, hence we
limit the amount of paging requests sent in one timer iteration
(MAX_PAGE_REQ_PER_ITER) in order to avoid the BSC doing lots of work
there at once, keeping it busy from processing other tasks.
Related: SYS#5922
Change-Id: I609fa67834b426456f48f6fb2acb601c5905f178
The variables are unsigned, so -1 gets actually translated to UNIT16_MAX
when the value is casted to uint16_t. Let's do that explicitly so that
readers don't think those are signed variables.
Change-Id: I02ad80e5d10f1a47cdf712f7f7c576a2e20fe607
If an lchan needs to be released to make room for an emergency call,
send the proper release cause ("pre-emption").
Related: OS#5534
Change-Id: I0423621d15ace11a53ae1653e5e7f5cb93605edb
Order the features and add a comment that reminds of updating OsmoBTS
to actually report the new features that are assumed to be supported
here.
Related: SYS#5922, OS#5538
Change-Id: I6f041648990db4ae479538cf3970c826bc6703ed
pcu_sock.c: In function ‘pcu_tx_info_ind’:
pcu_sock.c:197:2: error: #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
197 | #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
pcu_sock.c:199:2: error: #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
199 | #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
they made it here from osmo-bts.git
(b4999b60d4 states that the PCUIF support
was copied from there). The gitlog shows that these warnings were added
in 744f745d7a508605254afa8f78412ad410d153b0 by jolly (in 2012!)
together with the PCUIF support, and before
c1368d4ebe49f8e01f1f5fff3bc3583cb5960c1d these warnings were in German:
"ist dl_tbf_ext nicht falsch?"
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: I9ef7e18f56aa86b48f0ffeec58406260736170f3
From Vadim in https://gerrit.osmocom.org/c/osmo-bsc/+/27818
By checking !(link_id & 0xc0) we actually make sure that this is not
SACCH. So the comment "but not if the link_id contains a TCH flag" is
wrong, there is simply no such thing like "a TCH flag".
Change-Id: I8f0f6d7bf952426fd2f27802f1499d6ee8981982
If the BTS tells us SAPI=0 is gone, there is no point in trying to keep
the lchan around for SAPI=3, as it is not possible to operate GSM with
SAPI=0 gone.
This occurred with RBS6000, which don't seem to send RLL REL IND for
SAPI3 after doing so for SAPI0. However, rather than an
ericsson-specific hack, let's make this the general rule: If SAPI=0
is gone, don't stop the lchan from being released.
Change-Id: Ia9caa5b0a5efdc459d94621367376927959a6e65
Related: OS#5530
If we receive something unexpected, log it (and free the msgb!)
Change-Id: I43fab6a3a1c5e7a6545d6ef848636f5ba1be1576
Related: OS#5530 (only tangentially related)
The penalty timer low_rxqual_as() is only supposed to apply on an
intra-cell re-assignment. However, a segfault has been reported that
apparently applies it to inter-BSC handover.
Make sure that this timer applies only to re-assignment. In effect this
makes sure that the target bts is non-NULL and avoids the segfault.
Related: OS#5525
Change-Id: Ifdb9891fbe7e3f3423a96371def4fcbf2fc0bc0d
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I030c88545cdc71b3ad9e83f9c2ba7b27177c2ac8
When responding to a CBSP KILL with a CBSP KILL COMPLETE, make sure
we include the optional "Number of Broadcasts Completed List" IE
in order to inform the CBC about how many times the just-killed
message had been broadcast before it was killed.
It seems some CBCs expect this IE to be present, while 3GPP TS 48.049
lists it as optional. Since we alrady have code to encode it, let's
just always add it - it certainly won't hurt.
Change-Id: I47aebd613dfc6dd9261ea9019a51aff0cd6470d8
Closes: SYS#5906
This is cosmetic change making the default multi-rate configuration
easier to read/understand and modify.
Change-Id: I3d03c2188d007a60a86961a346744400bc81d4e6
Related: SYS#5917, OS#4984
* Always say 'codec mode', not just 'codec'.
* Suggest proper modes in AMR_{TH,HY}_HELP_STR.
* Use 3GPP's definition of threshold and hysteresis.
* Clarify that threshold and hysteresis values are in 0.5 dB steps.
Change-Id: I996eae8aafeb2850e5e1a6f5a7764d745e1289b5
Related: SYS#5917, OS#4984
Now that we have separate header/code files for the power control,
let's move the related definitions there. This change makes the
code consistent with osmo-bts, where it's already done this way.
Change-Id: I1cb3f6bfba0306e8f371dcd5162d1813beb3a088
For the sake of consistency and code readability, initialize the
power loop control interval (P_Con_INTERVAL) for both Uplink and
Downlink directions in the same function.
Change-Id: Ie3d4b481cbfacf27004787616e22b6f8a863b47b
When the assignment succeeds, the assignment_request has taken effect
and whatever it requested should now be in effect.
Hence copy the new RTP information from the assignment_request to the
conn's storage indicating what is currently used, always, not only when
lchan_changed == true. The RTP information may have changed also from a
Mode Modify where the lchan stays the same but changes its mode of use,
e.g. from signalling to voice.
When there is no RTP involved, this data is zero or empty, so there is
no harm in copying it, always.
Related: SYS#5916
Change-Id: I0788d1f013b8f820f559b6ed58a5f9bb8a02e0b4
When the assignment fails, we roll back the MSC side RTP endpoint at the
MGW that may have been created before the failure occured. On success,
we clear the mgcp_ci pointer so it is not rolled back.
Always clear this, not only when lchan_changed == true. That is because
a channel Mode Modify may also have added a voice stream that should
retain the newly created RTP endpoint at the MGW.
If no voice stream is involved, the pointer should already be NULL.
There is no reason to have a condition for clearing this pointer.
Just always clear it.
This fixes all voice calls that modify a TCH lchan from signalling-only
to voice mode. Before this patch, their MSC side RTP endpoint was DLCX'd
right on assignment success.
In particular, this fixes Emergency Calls (which usually get a TCH lchan
assigned right from the start, and hence do a Mode Modify to add voice).
Related: SYS#5916
Change-Id: I5ab10ee7fd9c5d7608e8a06893881d990943feed
The paths were wrong in my previous attempt, add the proper paths now.
I've verified that this file builds, and adjusted the current nightly
rpm spec uploaded to OBS with this change manually this time so it
doesn't block.
Fix for:
File not found: /home/abuild/rpmbuild/BUILDROOT/osmo-bsc-1.8.0.90.e0187.202204061142-1.1.x86_64/etc/osmocom/osmo-bsc-4trx-fh.confmerge
File not found: /home/abuild/rpmbuild/BUILDROOT/osmo-bsc-1.8.0.90.e0187.202204061142-1.1.x86_64/etc/osmocom/osmo-bsc-4trx.cfg
Fixes: e0187bc3 ("contrib/osmo-bsc.spec.in: add new config files")
Change-Id: I92a7d85b64a9659db7ef71af5b00110b582dc4d9
This file was taken from docker-playground.git, and this is basically
what we use when running the ttcn3-bts-test with hopping enabled.
Change-Id: I205eb53901e06ee52dc64e050cfe2374cb9c771e
So far we had no multi-trx config examples at all. Let's add one.
Use unique 'RSL TEI' for each TRX, as this simplifies analyzing the
Abis protocol traces. Also use the new 'TCH/F_TCH/H_SDCCH8_PDCH'.
Change-Id: I20f86fa74dc4bd71538627ec59c5d2cd3678a089
Fixes: OS#4748
According to 3GPP TS 45.002, table 3, unlike the CCCH+SDCCH/4+CBCH
combination, which can only be allocated on C0/TS0, the SDCCH/8+CBCH
can be allocated on C0..n/TS0..3. In other words, having CBCH on
e.g. TRX1/C1 is perfectly legal. This is why in gsm_bts_get_cbch()
we should check all transceivers, not just the C0.
Change-Id: Ie79ccff4f8f0f1134757ec0c35e18b58081cc158
Related: SYS#5905
When bad RxQual causes handover to a cell with weaker RxLev, then
handover oscillation *will* happen, as shown in test_rxqual.ho_vty.
Introduce a penalty timer for a cell where we had bad RxQual.
This delays handover back to the cell with stronger RxLev by the penalty
timeout; hopefully the interference is gone after the timeout.
Usually, we set new configuration elements so that osmo-bsc behaves the
same as before the config item was added. In this instance, this makes
no sense, because no-one ever wants handover oscillation from bad
RxQual, which is guaranteed to happen without the new penalty timer. Set
it to 60 seconds by default, same as other penalty timers.
Related: SYS#5911
Change-Id: I057b156604a104a26a7ce45d1c7adadbf452c932
This add support for handling inbound MESSAGE STATUS QUERY from the CBC,
and responding with MESSAGE STATUS QUERY COMPLETE or MESSAGE STATUS
QUERY FAILURE, as applicable.
Change-Id: I3b738dc29d0ead4f735abeeb6960d3675cb05ae2
Related: SYS#5909
I find it weird that we store the A5 algorithm ID in a format that
is used on the wire: N + 1 (valid for both A-bis and A interfaces).
What confused me even more is that in some functions we print it
as if it was in a normal, human-readable format. And this is
also why one can see weird constructions like:
if (lchan->encr.alg_id > ALG_A5_NR_TO_RSL(0)) { ... }
Let's ensure that our internal structures use the A5/N format:
alg_id=0: A5/0 (0x01 on the A-bis/A interface)
alg_id=1: A5/1 (0x02 on the A-bis/A interface)
alg_id=2: A5/2 (0x03 on the A-bis/A interface)
...
alg_id=7: A5/7 (0x08 on the A-bis/A interface)
so that we can print and compare the value of alg_id without using
additional arithmetics. Let's also rename 'alg_id' to 'alg_a5_n'
as it most clearly indicates which representation it is storing.
This is how the above code snippet would look like:
if (lchan->encr.alg_a5_n > 0) { ... }
Change-Id: Ieb50c9a352cfa5481aebac2379e0a461663543ec
When copying the CBS page content from CBSP to RSL data structures, we
use the User Information Length as length argument in the memcpy. The
logic for that is that only this part of the message contains valid
data.
However, as the user information length is not passed on via RSL or
transmitted over the air, the receiving MS will get a page with
zero-initialized padding, rather than whatever the originator of the
message has specified. As zero bytes in the 8bit domain might get
translated into @-characters in the 7bit domain, this creates problems.
So instead, let's always copy the entire page (82 bytes) to ensure
transparency when passing on information from CBSP to RSL.
Change-Id: Iffcf1f6a7d41a08a2feffc6f2ac5634d940b63aa
Closes: SYS#5904
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the abovementioned IEs are present
in the original message, they must be delivered to the SMLC too.
Change-Id: Ifeb359b0468845da0b4fed9e2e4b79256067fa81
Depends: libosmocore.git I8775a93cf4089b1752d040e43d2cba6b8997f955
Related: SYS#5891
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the LCS Client Type IE is present
in the original message, it must be delivered to the SMLC too.
Change-Id: Id3262e67c3dc25cb93fbd52a40689c5529ca2d41
Related: SYS#5891
It's really confusing having a "default" struct whose inner values are
changing based on previous state. Furthermore, it's only used in
generate_si13() so there's no need to keep it outside the function.
Let's move it inside the function and rename it to avoid confusion.
Change-Id: I3ae4dd017dd4dad10c0365d21727666dd8e9fd41
It makes no sense to enable that field if the ext_info.egprs_supported
field marks EGPRS as disabled.
From TS 44.060 11.2.5a:
"""
This message may be sent by an EGPRS capable mobile station
*in a cell supporting EGPRS* and where the EGPRS_PACKET_CHANNEL_REQUEST
parameter indicates that this message shall be used.
"""
Related: SYS#5891
Change-Id: I5ac173116f8681d7340b75b2baff110158fab9fd
If "bts->gprs.mode" was changed dynamically at runtime (VTY or CTRL), it
could happen that the egprs_supported was kept as "1" if the dynamic
change was EGPRS->GPRS.
In summary, if EGPRS support was set, it couldn't be unset until BSC was
restarted.
Related: SYS#5894
Change-Id: Id2c2319044da474642c4cc710baa27cfee4fb592
Values in ext_info are modified in several places, so it's difficult
validating whether we deviate from default. Let's always send it so that
we always have a clear view on what the MS uses.
This fixes a bug where paging_coordination or ccn_active would not be
announced if GPRS was not enabled.
Related: SYS#5894
Change-Id: If96de3e0d77503cf6344dfbc611f9260ac3281aa
The value in bts->si_common.chan_desc may get out of sync with the
actual value in net->T_defs (e.g. after changing it via the VTY),
so we need to sync it in generate_si3().
Note that synchronizing the values in cfg_net_per_loc_upd_cmd is
a bad idea, because the value of T3212 may also be changed using
generic timer management commands.
Change-Id: Iee291623c2825505eeb5175adcedadfe35375b9e
Related: SYS#5888
This was overlooked during the code review. GCC does not complain
because internally both 'enum handover_scope' and 'bool' are
interpreted as 'int'. Found this while running my WIP testcase
TC_srvcc_eutran_to_geran_a5_3. This change makes it pass.
Change-Id: I807fd4a0e700e54c67ca3547d9c0c1b442dd1c54
Fixes: I4e5b1163a71443d706f14ce4bfd5c2294c320432
Related: SYS#5838
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
Change-Id: I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
When running a multi-trx setup, upon stopping osmo-bts one can see:
DCHAN ERROR lchan_fsm.c:80 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN ERROR lchan_fsm.c:144 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan activation failed
(lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR)
These messages show up when the following conditions are met:
* BTS model speaks A-bis over IP (ip.access, e.g. nanoBTS), and
* BTS has more than one transceiver configured.
The problem is that unlike traditional E1 based BTS models, ip.access
ones have a single global A-bis/OML link for all transceivers. Thus
when it goes down, in inp_sig_cb() we need to notify all timeslots
*of all TRXes*, not just TRX0.
Change-Id: I3dc657ac5a2c5334747bd4f4db1a658acb323942
Fixes: OS#5479
Historically, we first only had
BSS_MAP_MSG_ASSIGMENT_RQST
^
with missing N. libosmocore has this renamed a long time ago and
provides a shim #define that makes the typo version still work.
Having the typo is bad for grepping, so rather use the non-typo name.
Also rename the constant for the ass req counter which so far has a
similar typo, and fix the same typo in the counter description.
The counter name exposed on CTRL luckily doesn't have this typo in it.
Change-Id: Ieaa4f4e6e6f7e1563b1bd15a83f0c1a9112d2312
The ho_fail() macro includes a newline, so the callers should not add
one. Fix these cases where the extra '\n' fragments the logged message.
Related: SYS#5839
Change-Id: Ifdbce98be70c1aa127ae008d7a77b9795fd250d3
So far we completely ignore the codec list from the MSC in Handover
Request messages. This leads to error messages in subsequent handovers
because there is no Codec List stored on the conn:
DHODEC ERROR handover_decision_2.c:390 [...] No Speech Codec List present, accepting all codecs
Besides the error log, in hodec2 we may subsequently take bogus or
unexpected codec decisions, ignoring the MSC's choice of codecs, or in
the worst case picking an unsupported codec.
This also has implications on what type of lchan we choose for handover
target in hodec2: say, if no half rate codec is supported as per the
MSC's request, we normally avoid handover to a TCH/H, etc.
Intra-BSC HO after an Inter-BSC incoming HO is the only case where this
problem occurs, in every other scenario there is an Assignment Request
from the MSC, from which we properly store the MSC's codec list.
3GPP TS 48.008 does indicate that on AoIP this codec list shall be
included. So reject HO Request with missing Codec List, as we already do
for Assignment Request on AoIP.
This makes TTCN3 BSC_Tests for inter-BSC incoming HO fail, because our
tests so far omit the Codec List (MSC Preferred) on AoIP. The related
fix of the tests is If06de9c9b43d79f749447a4e2a340176eef75c79.
Related: SYS#5839
Depends: If06de9c9b43d79f749447a4e2a340176eef75c79 (osmo-ttcn3-hacks)
Change-Id: I117cc29d6d11db77d160de654f43f5993db6ee21
"inter-BSC MT" was the terminology of an early development stage of
inter-BSC handover, code review requested "incoming" instead. This one
was missed when applying code review.
Same in a code comment.
Related: SYS#5864
Change-Id: I1ca810542e89980ffda11876fd30626467e452d1
Teach osmo-bsc to handle empty N-Connect. So far we were always
expecting user data in an SCCP N-Connect from an MSC. However, it is
perfectly valid for an initial BSSMAP request to follow later.
This is relevant for:
- Handover Request (incoming inter-BSC handover)
- Perform Location Request (query physical location of the MS)
Add state WAIT_INITIAL_USER_DATA with new timeout net X25. Always enter
this state so that we don't have two separate code paths for handling
initial user data.
Related: SYS#5864
Change-Id: I535c791fa01e99a2226392eb05f676ba6c3cc16e
Also increment message counter for the case that a Perform Location
Request came in the initial SCCP N-Connect message.
Related: SYS#5864
Change-Id: I3f78ce73eb16fdff1f19359963405b2235000fc4
During inter-BSC incoming handover, there is no previous lchan to be
switched, so this event always comes in the READY state of
lchan_rtp_fsm. No need to complain about that and confuse log readers.
Related: SYS#5864
Change-Id: I96fd53b8c8da621a40bd65f85070eabd030cc875
According to 3GPP TS 44.018, section 10.5.2.1b.2, only ARFCN values
in range 1..124 can be encoded using the 'bit map 0' format. Before
this patch, ARFCN values belonging to E-GSM band (0, 975..1023) were
ignored in bitvec2freq_list(), and thus not present in the resulting
Cell Channel Description IE.
Change-Id: I17739e6845cd84e2a81bc406dd532541f7c52cb6
Related: SYS#5854
I find it cleaner to relay on the counter ('arfcns' in this case) to
check if the set is empty, rather than checking one of the resulting
values ('max'). There is just a cosmetic change.
Change-Id: I29ca51461beec053bcb8b8210f0ad24bb8c7765f
Related: SYS#5854
This commit demonstrates what happens when a cell has channels in
both P-GSM and E-GSM bands (case 'c'). As can be seen from:
Case a) only the BCCH carrier: 10
Case b) more carriers from P-GSM band: 1 3 10 64 99 124
Case c) more carriers from E-GSM band: 1 3 10 64 99 124
in both cases 'b' and 'c' we have the same set of ARFCNs. Carriers
from the E-GSM band are not present at all. This is wrong and will
be fixed in the follow up change(s).
Change-Id: Ied0519c70501f105673a9b36657101063d275058
Related: SYS#5854
The callers of this function do pass different mask values, which
should be passed to gsm48_decode_freq_list(). Instead, 0xce was
passed regardless of the given mask value.
Change-Id: I47f2eab54ef8487b14992fd7a69d5c9ccbb3f5cf
As the comment above the fix suggest, the encoding is in 10ms units.
osmo-bts is also doing the proper:
"""
uint8_t t3105 = *TLVP_VAL(&tp, NM_ATT_BTS_AIR_TIMER);
bts->t3105_ms = t3105 * 10;
"""
Related: SYS#5838
Change-Id: Ie190514ee35d1ca81b70e9180bf7393b973d3504
Improve the function doc. Remove a comment at a caller, because that
information is what the function doc is for.
Rename the array to codec_by_strength, because it is not the codec
strength but the codec number listed in the array.
Related: SYS#5839
Change-Id: Iaed6b97c31e4ccb1f28ca7e64596d5e20563b392
In the field we saw Handover Requests without any Chosen Encryption
Algorithm IE, and osmo-bsc completely failed on those. This made me
understand my mistake from when I wrote this handover code.
So far, from a BSSMAP Handover Request, we (I) used only the Chosen
Encryption Algorithm IE to pick the encryption to use on the target
lchan. That is very wrong.
Instead, figure out the intersection of permitted algorithms MSC & BSC,
and pick the best of those. Which means, actually, completely ignore the
Chosen Encryption Algorithm IE.
In the message, the permitted algorithms are passed as a bitmask. The
current code using gsm0808_dec_encrypt_info() passes this on as an
array. In order to select_best_cipher(), I could convert that array back
to a bitmask. Instead pass the bitmask on from message decoding
alongside the struct gsm0808_encrypt_info in req->ei_as_bitmask.
In handover_end(), change the condition so that we can also pass
HO_RESULT_FAIL_RR_HO_FAIL to emit a Handover Failure.
Related: SYS#5839
Change-Id: Iffedc981b60d309ed2e5decd5efedee07a757b53
The naming confused me so that I wrote buggy code again. Hopefully this
clarifies which representations the code paths are using.
In the macro code, highlight the error case of n <= -1 explicitly.
Also add ALG_A5_NR_TO_PERM_ALG_BITS. I need the 1<<n case in an
upcoming patch.
Related: SYS#5839
Change-Id: I7557ae97764bba09c906748a18e9031dfb362611
This patch imposes no logical change in the code on itself, but makes
sure people compiling osmo-bsc uses an old enough libosmocore
implementing Cell Identifier SAI. This is important since adding the SAI
ID (CELL_IDENT_SAI) displaced CELL_IDENT_WHOLE_GLOBAL_PS to a new
number outside of the 3GPP range for cell IDS (4 bits, this way we
garantee we won't have the same problem again).
This means there was an ABI breakage (see Depends below).
As a result, using an osmo-bsc compiled against an older libosmocore
, and then using at runtime against a newer version of libosmocore, will
most probably provoke some RIM features to not work properly, since
libosmocore will handle CGI-PS cell ids sent by osmo-bsc as SAI ones,
and most probably do wrong comparisons when matching (they only match up
to LAI included).
ABI break analysis:
osmo-bsc uses CELL_IDENT_WHOLE_GLOBAL_PS in:
* gsm0808_dec_cell_id_list2() -> this is called on stuff received from the
network, so it's actually fine handling it
correctly as CELL_IDENT_UTRAN_SAI instead
of CGI_PS.
* gsm0808_cell_id_list_add
same_cell_id_list_entries
gsm0808_enc_cell_id_list2
cell_id_to_cgi-> On old osmo-bsc, When
CELL_IDENT_WHOLE_GLOBAL_PS is passed
to be encoded as CGI, RAC byte is
taken for encoding instead of 2nd CI byte.
* gsm0808_cell_ids_match
gsm0808_cell_id_u_match
cell_id_to_cgi -> If CELL_IDENT_WHOLE_GLOBAL_PS as 0x11
(CELL_IDENT_UTRAN_SAI), 1 byte offset when
comparing (1 byte of RAC is taken converting to
CGI instead of the 2nd byte of CI). That means
match would be wrong if 2nd byte of CI differs.
Related: SYS#5838
Depends: libosmocore.git Change-Id Id25e563febdb7640174540136225f399515a0089
Change-Id: I70972efffefd57fd36332fab539683696c32f4a5
The timer (T4) that controls the re-sending of the BSSMAP RESET can not
be changed via the VTY, althrough it is defined via a tdef struct. Lets
add a description along with default values to make it configurable via
the VTY.
Change-Id: I1fb5699220ab8a643a168567a89c6f381fe433a7
Related: SYS#5796
An earlier patch version had that typedef, the merged version switched
to the struct containing the array.
Change-Id: Id8ca7b298436feb98f4a563ad3cdea510b9362b0
The SAPI "n" REJECT messages were being sent with DLCI keeping the RSL
LINK ID format, which is not the same for CC bits.
With this patch, TTCN3 test BSC_Tests.TC_rll_sapi_n_reject_dlci_cc
passes again.
Related: OS#4728
Related: SYS#5047
Change-Id: Icc187f594743040a3d9b8beff7d9cfc21dd6eb08
Skip the BSSMAP Clear and SCCP RLSD parts and immediately deallocate the
gscon when there is no SCCP connection present. Before this patch, such
conn would stick around for a minute before a timeout deallocates it.
Related: OS#5337
Change-Id: I8c8537acf6b47b121903197608636c43ae601a57
Properly implement the separate conn release stages in separate FSM
states:
x) sent Clear Request, wait for a Clear Command from the MSC.
Timeout after a configurable 60s.
y) after a Clear Command and sending a Clear Complete, wait for the SCCP
RLSD. Timeout after a configurable 60s.
z) terminate after the RLSD is received / after timeout.
handover_test.c needs a little tweak to make the MGCP release work with
its fake MGCP client, because cleanup now ensures to invoke
gscon_forget_mgw_endpoint() in all cases.
Related: I680ec4ed866aa5f0b1ff29e7e98322615cfb288d (osmo-ttcn3-hacks)
Related: OS#5337
Change-Id: Ie975117d37f38ba853589dc7f8d3e94f8f9586b2
The way the ST_CLEARING is entered before this patch has various
symptoms of how I / we used osmo_fsm when we were still FSM amateurs in
Osmocom. Patch that up:
- In gscon_bssmap_clear(), ask for a state transition to ST_CLEARING
first. Go ahead only if it is allowed.
- move the Clear Request messaging to ST_CLEARING's onenter function.
- Fix the timeout behavior: by using conn_fsm_state_chg(), use the
actual proper X4 timer value for ST_CLEARING from VTY configuration
instead of hardcoded magic numbers.
Related: OS#5337
Change-Id: I234b2a754d0c98031056981823cdbc187e977741
Allow returning a context sensitive cause instead of a hardcoded one in
gscon pre_term().
Also, the conn->cause is needed to move message dispatch to an "onenter"
function in patch I234b2a754d0c98031056981823cdbc187e977741. I Split
this part off as a separate patch for better readability.
Related: OS#5337
Change-Id: Ib6432746040899129d1d73ae8dc59add2d88a915
In lcs_ta_req_wait_ta_onenter(), fix use count leak of 'start-paging':
get() the use count only after the early exits.
osmo-ttcn3-hacks patch I69d4c5c6f8d499bb7f0b96a48af045361433c57b
introduces testing against this leak in various LCS tests (e.g.
BSC_Tests.TC_lcs_loc_req_for_active_ms_ta_req).
Related: OS#5355
Change-Id: Ibbfbfe766eafe42c78048ec5b3b503a11ef5535d
During specific release scenarios, it became clear that an lchan still
pointed at a conn even after it had been deallocated. That was due to
setting conn->lchan = NULL but not lchan->conn = NULL. Fix that.
Do lchan_forget_conn() first, because during gscon_forget_lchan() we may
enter the gscon clearing dance, which in case of no SCCP conn being
present will soon / should immediately deallocate the conn.
Related: OS#5337
Related: I8c8537acf6b47b121903197608636c43ae601a57 (osmo-bsc)
Change-Id: Idbfe4672233ba8105eff5ba77ee07fd871358255
Before:
state_chg to ACTIVE
state_chg to WAIT_RLL_RTP_RELEASED
state_chg to WAIT_SCCP_RLSD
After:
State change to ACTIVE (no timeout)
State change to WAIT_RLL_RTP_RELEASED (T3109, 5s)
State change to WAIT_SCCP_RLSD (X4, 60s)
Change-Id: I94b7dc4d9e5e45dc731bcb3a843ede9fb6cc0839
The checks that make sure that an ARFCN falls in the correct range do
not return with -EINVAL as they should, instead nothing happens. (Only
the check for GSM1800 is corrct)
Change-Id: Iddadafe3fbc47e2f980d8e4ab4f320998cb454ff
Related: SYS#5369
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ifbbafe185931c0f508ff8148ef244f25a9620fd8
At the moment the BTS configuration is checked, but the check does not
have much consequence other than that some initialization that is not
executed. The BTS will go into the OML bootstrap phase anyway and most
likely fail at some later point due to the invalid configuration. To
reduce noise and unexpected behaviour of the BTS lets make sure that the
OML boostrap phase can only proceed when the BSC conciders the
configuration as valid.
Change-Id: I42c1c26a9b800600787b1266a871f95f2114c26e
Related: SYS#5369
The manual lacks an example on how to set up an E1 connected BTS.
Especially the relation between trunk number and E1 line number is not
obvious.
Change-Id: I02f5d4fe059e5cc9c3ffc2e3636d812532c09239
Related: OS#5308
Counting the Assignment success after osmo_fsm_inst_term() meant that we
were counting a cleared out channel mode, which always yielded
signalling mode.
Count the Assignment success *before* terminating, so that we correctly
count the successful assignment as speech mode.
Related: SYS#4878
Related: Icb1386ec2ccd70eb3c026301b9b08ad7177278f7 (osmo-ttcn3-hacks)
Change-Id: Ie9fcd1e86f27ecb2f11e2e8813faac365cb470b8
Similar to paging:attempted, count paging:expired not only per BTS, but
also for the whole BSC. Add active_paging_requests to struct bsc_subscr,
to increase the counter only once if paging expires, and not once per
BTS where paging expired.
Related: SYS#4878
Change-Id: I9c118e7e3d61ed8c9f1951111255b196905eba4d
osmo-trx-uhd with a B200 has proven to provide bad (lower than usually
considered good) C/I values due to high noise (even with band filters in
place). Hence, default thresholds (gathered from literature on the topic)
are too high and end up in bad algorithm output decisions.
Furthermore, most users of Osmocom don't use it in densely populated
areas, hence RXLEV based algorithm used when C/I based one is disabled
is good enough.
Let's disable C/I based one by default, and let advanced users which
specific needs to enable and confiure thresholds specifically for their
needs (hardware, cell surrounding conditions, etc.).
Related: SYS#4917
Change-Id: If1a73c60695379bcfcd0f44c6ec6dd659563e279
abis_nm locally declares its own struct for the ipaccess firmware
header, even though libosmocore defines it as well. Lets use the
definition from libosmocore.
Change-Id: I69cb45fc40bd20ea2533cc8cd6a68363b59cc408
The function generate_ma_for_bts() is called when the OML TEI comes up.
In the same code path boostrap_bts() is called as well. It would be more
logical to call generate_ma_for_bts() from boostrap_bts() since it is
also part of the bootstrapping process.
Change-Id: Ib2ed5b1eac3701cfb3a3e8dd478488ba5404d1fd
Related: SYS#5369
At the moment check_bts and bootstrap_bts is called only once on startup.
When a new BTS is set up during runtime bootstrap_bts, nor check_bts is
called. This means that some parameters of the BTS stay uninitalized
until osmo-bsc is restarted. Lets rather call check_bts() and then
bootstrap_bts() when the OML TEI of the BTS comes up.
Change-Id: Ie599f809623efd6ea4ab3f39294195fc1ef84b85
Related: SYS#5369
Let's have a short and consistent naming for both ACCH repetition
and temporary ACCH overpower structures, like it's done in osmo-bts.
Change-Id: I39b98dcd14219402959646524315d5afea7c08cf
Related: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07
Let's have a short and consistent naming for both ACCH repetition
and temporary ACCH overpower structures, like it's done in osmo-bts.
Change-Id: Ia12c83ad1af4744ce28ba655ac806784f746e88a
Related: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07
The linter (executed by Jenkins) complains:
src/osmo-bsc/bts_vty.c:653: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:654: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:656: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:657: ERROR:CODE_INDENT: code indent should use tabs where possible
and blocks changes, adding V-1 when I am changing the related code.
Change-Id: If3c8c09ddff7cb945425e74344ceb4da989ddffc
The linter (executed by Jenkins) complains:
src/osmo-bsc/abis_rsl.c:543: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
and blocks changes, adding V-1 when I am changing the related code.
Change-Id: I0cf00ff898e69734850659e8ba0e2ff023f9b2dd
In the case of ts->pchan_from_config=GSM_PCHAN_OSMO_DYN,
ts->max_primary_lchans will be 8 due to SDCCH8 support, and we don't
want to set lchan->vamos.is_secondary=true for lchans at the end of the
array.
Related: OS#5278
Change-Id: If86af5fafe059d5e830c1f6d37034f7325d9a96c
The function set_bts_loc does not check the string pointers resturned by
strtok_r. In this particular case this is not a problem because the
function set_bts_lock will only see verfied input. However, lets check
the results anyway to avoid creating false positives in coverity scan.
Change-Id: Ie21c392e0405fc45811c6d55bf5508e9eb6784de
Fixes: CID#240849
In order to be able to call check_bts() and bootstrap_bts() from
inp_sig_cb(), we must move it below bootstrap_bts.
Change-Id: I1a365bc2278368ec1f5c0db3f3e466b124b16e83
Related: SYS#5369
The function bootstrap_bts does a few checks before it does the actual
initialization. To make the code more modular, lets split the function
into two functions, check_bts and bootstrap_bts. Also be sure that we
print the BTS number when the check failes.
Change-Id: Id2b26f147d2f35e156e2da8ee58d2bbbb93de4ac
Related: SYS#5369
The function bootstrap_bts verifies that the ARFCN number is within the
valid range of the current band. In case of error it prints that the
ARFCN is out of range, but it does not print the BTS number, nor the
ARFCN number.
Change-Id: I432448b4bd5ea1a209838a6c5105cc1e9f7d80ee
Same as all_allocated:{sdcch,tch}, but already trigger when all
non-dynamic timeslots are allocated.
Related: SYS#4878
Related: Ib3997a827c9cc43d1361bb0cf3bfab9f6d91bf82 (osmo-ttcn3-hacks)
Change-Id: I2fa14531f16d3f07085620f1c50eb839c420da6a
This is a candidate for adding to libosmocore (as osmo_time_cc), but
let's first use this in osmo-bsc to make sure that it works as intended.
I started out expecting to be done with this in half an hour, but I
found out that accumulating elapsed time to an integer counter has a
staggering amount of complexity to it, and a million pitfalls.
The intended use is to report allAvailableSDCCHAllocated and
allAvailableTCHAllocated performance indicators in OsmoBSC. Hopefully
this will also be generally useful elsewhere, to be worth the effort.
Related: SYS#4878
Change-Id: Icdd36f27cb54b2e1b940c9e6404ba9dd3692a310
Add chan_counts_for_trx() and chan_counts_for_bts(). Drop
bts_count_free_ts() and trx_count_free_ts().
Rationale:
The bts_count_free_ts() and trx_count_free_ts() always returned the
number of free lchans, not timeslots. Hence, passing the pchan type as
argument never really matched the semantics.
Especially, when looking for free SDCCH, there is no clear match on a
gsm_phys_chan_config enum value: SDCCH8_SACCH8C, CCCH_SDCCH4,
CCCH_SDCCH4_CBCH, SDCCH8_SACCH8C_CBCH? -- GSM_LCHAN_SDCCH is clear.
==> Rather count free lchans by enum gsm_chan_t.
Counting lchans of distinct types required separate iterations for each
lchan type.
==> Rather compose an array of counts for all types, in one go.
I need to count the amount of free SDCCH lchans in an upcoming patch to
implement the performance indicator allAvailableAllocatedSDCCH (cumulate
time for which no SDCCH are available).
To implement allAvailableAllocated{SDCCH,TCH}, I need a count of both
the used as well as the total lchans for a type: it does not make sense
to flag "all available allocated" if none are ever available.
To properly count dynamic ts, I need the maximum total that can be
possible at any time. And to count currently free lchans, I need the
current total. This may seem counter intuitive, but consider, e.g.:
- Obviously, if a cell has only static TCH/F timeslots, it does not make
sense to flag that all available TCH/H are occupied, because no TCH/H
are available ever. Just stating this as contrast to dyn TS.
- If a cell has OSMO_DYN timeslots, I *do* want to flag that all TCH/H
are occupied when all dyn timeslots are fully occupied.
- If those OSMO_DYN however are all used as TCH/F, the current total of
TCH/H becomes zero, and it seems like TCH/H should not be considered.
- To count the nr of currently free lchans, I need the currently
possible total of lchans and the nr of occupied lchans.
So return both a maximum total and a current total of lchans. In above
example, the maximum total shows that there would be TCH/H possible.
BTW, it would be nice to keep a chan_counts array on trx, bts and bsc
level and update as channels are allocated and released, instead of
counting them all over periodically. But it's less error prone this way.
Related: SYS#4878
Change-Id: I2fb48c549186db812b1e9d6b735a92e80f27b8d3
It's more logical to have the boundaries sorted in ascending order:
* band 1 represents lowest interference levels,
* band 5 represents highest interference levels.
Change-Id: Ie9bf4bf0c89418685b8ea5096332d22cfba7c521
Related: SYS#5313
As stated in "GSM/EDGE Evolution and Performance", section 12.3,
both features *can* be enabled simultaneously.
Change-Id: I2189f01bd78625dab3d642597240338ee581fc98
Related: SYS#5319
We have lots of counters for intra-BSC handover *away from* a given BTS,
but still missing are counters indicating how many handovers *targeted*
a given BTS. Also count incoming HO.
Related: SYS#4878
Related: Iba229313d73fa20266f6d4eac5820579fb14c604 (osmo-ttcn3-hacks)
Change-Id: Id9f2c6e2865ebe680879018fff08d283ce24c983
I was a bit confused that grep did not find HO counters being used, so
let's add some comments to better explain and provide a grep hook.
Related: SYS#4878
Change-Id: I242de13e657286e09428a8ca6e583d8b5155faa2
nanoBTS would NACK a CHANnel ACTIVation message for an 'intra cell
channel change' if it does not contain the Timing Advance IE. And
this is right, because according to 3GPP TS 48.058, section 8.4.1,
point '4)', it *must* be included.
Indeed, the actual Timing Advance value is not known during the
manual channel activation triggered from the VTY interface. So
let's merely indicate 0 if it's not known.
Change-Id: Iee7ddb4cf1a9a7bb9b34e6c9f6f9899da480fbd0
Do not turn some compiler warnings into errors by default. This patch
was added before --enable-werror was available.
We build with --enable-werror during development and in CI. If the code
is built with a different compiler that throws additional warnings, it
should not stop the build.
This reverts commit 34f012639d.
Related: OS#5289
Change-Id: I6b143b803349b97e783c586615d7f2ed4e1ff058
The fixme note:
"FIXME: add variables defined in src/ctrl/control_if.c?"
is not directed at the reader of the manual. It should stay in the
source, but it should not be visible in the pdf. Lets comment it out.
Change-Id: Id68f53d18f0873af3c07a0ae52cd12bc94bc0b96
It is possible to change the neighbor-list mode via the VTY from
automatic mode to manual neighbor-list configuration. In the manual
mode, the user can add ARFCN values manually. This command can be found
under the bts node. Lets add pendant of this command on the control
interface as well.
Change-Id: Id97bc0d31a358db6221c385761773fb48670c921
Related: SYS#5641
The VTY allows flexible control over the neighbor cell information via
the neighbor command, which can be found in the configure terminal under
the bts node. Lets add pendant of this command on the control interface
as well.
Change-Id: I343a40e18fa9b91e6c381912c0426a002841e079
Related: SYS#5641
An upcoming patch would rather pass a const struct gsm_lchan*.
See I2fb48c549186db812b1e9d6b735a92e80f27b8d3.
Related: OS#4878
Change-Id: I523cbf04e77f43924c3f09094d56f815d3de640d
The Neighbor Address Resolution Service is using the control interface
API as well. Lets add a comment to indicate that this service is not
related to the normal control interface.
Change-Id: Iec86f72548bfc54a2c86dadec69dd1c64813d852
When the gsm_subscr_conn_fsm (GSCO) terminates abormally it might not go
through the forget-mgw-endpoint mechanism. It might be terminated
forcefully, which means only the pre_term callback runs. The pre_term
callback clears the endpoint, but it does not put the mgcp_client
reference back into the pool. This results into a wrong ref-count in the
mgw-pool.
Change-Id: I5a7ce6a1880a1060df74d03dd4eb38b51fd85c69
Related: SYS#5675
The option -t --testmode is defined, but not evaluated. It seems that
the code of this option was removed long ago. Lets remove it now.
Change-Id: Ie11173f5a7aab568b9a25102ad7dcf37fd49f318
VAMOS secondary lchans are to be used specifically when the osmocom dyn
TS is set to pchan_is=TCH_{F,H}. Setting secondary subslots for
OSMO_DYN TS is not needed since it's only used to initialize the TS, and
OSMO DYN already initializes 8 subslots
(subslots_per_pchan[GSM_PCHAN_OSMO_DYN]=8). Otherwise, ts_setup_lchans()
will try to initialize 8+2 lchans on the TS, which is more than needed
and will access out of bounds in the array.
Related: OS#5278
Change-Id: I8727d5b446179c0ebcd8738507efe5a50afaf1e2
Since a while ago, osmocom types dynamic TS supports being configured as
SDCCH8, hence the maximum subslots is 8. This fixes issue where only up
to 2 subslots where being used on those TS.
Related: OS#5278
Related: SYS#5309
Fixes: 52b9912ef9
Change-Id: I50e6530284ef49cfd77d1944d4a183c5df345820
It is not possible to operate a cell that has secondary TRXs in
different bands. Especially considering that DCS1800 and PCS1900 have
overlapping ARFCN numbers it would be hard for the MS to tell to which
band it should switch. Also the ImmAss. message only contains the ARFCN
number. It is impractical to have TRXs in different bands and probably
this also violates the sepec.
Change-Id: Icc2af9e2a9bca3897dbbb34d7b2c0fe6f843bedd
The value ncc_permitted is preset in osmo_bsc_main.c from
bootstrap_bts(). It is a constant value that also cannot be changed via
the VTY. Therefore it should be set from bts_alloc(). This also fixes
the problem that when the BTS is added at runtime from the VTY. BTSs
added at runtime would have an all zero ncc_permitted until the next
restart of osmo_bsc.
Change-Id: I9f02277d7b4b4bcb383e749435416a0b22efd5e8
Related: SYS#5369
The index counter bts->chan_load_samples_idx is initialized to 0 in
bootstrap_bts. Since the bts object is allocated using talloc it is
already guaranteed that everything is set to zero. So we do not need to
initalize chan_load_samples_idx.
Change-Id: Ia75e59c44c3ccd653a2614c2cda7519faf999f09
The acs value is currently set from bootstrap_bts() in osmo_bsc_main.c.
The value is set to 0. Since the BTS object is allocated using
talloc it is guaranteed to be 0 from the beginning. Lets set it from
bts_alloc anyway so that we have a place holder that is easy to find.
Change-Id: Idc4e08c471e15c36b4ea7eb3981254e179115765
The pwrc value is currently set from bootstrap_bts() in osmo_bsc_main.c.
The value is set to 0. Since the BTS object is allocated using
talloc it is guaranteed to be 0 from the beginning. Lets set it from
bts_alloc anyway so that we have a place holder that is easy to find.
Change-Id: Id76879a94cf8cf8c07e8fc7e8aa399cd50e04e9a
At the moment we set the R99 flag from bootstrap_bts() in
osmo_bsc_main.c. However this constant flag should be set together
with the many preinitalized chan_desc values in bts_alloc
Change-Id: I5b78c4e25616ab552c37ba8b7c9948cf7052bad4
The function gsm_set_bts_type() already takes care of setting the
model->started flag to true. There is no need to do this in
bootstrap_bts() again.
Change-Id: Ia70943d96d466ab506fe368ef178a2ccc7483adc
Controversy: this duplicates bts.N.rsl_connected. I would like to add
this duplication for consistency, since we now have these counters:
bsc.0.num_trx:rsl_connected
bsc.0.num_trx:total
bts.N.num_trx:total
and the old
bts.N.rsl_connected
which does not fit well with above naming scheme. Any user will be
justified to expect a stat named bts.N.num_trx:rsl_connected as well.
Determine bts.N.num_trx:rsl_connected in the new function
bsc_update_connection_stats(), where the other num_trx:* are set.
Related: SYS#5542
Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks)
Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore)
Change-Id: I55b55159fe13d937e441d8c2ed915734463e1154
This is similar to bsc.0.num_trx:total but per single BTS.
Related: SYS#5542
Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks)
Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore)
Change-Id: I283d38e7a8c032e274a5bd2fa150ec2c9a7157b4
If an RF Resource Indication message includes interference band(s)
for 'pure' PDCH (i.e. not dynamic) timeslot(s), osmo-bsc logs:
DRSL DEBUG abis_rsl.c:1515 (bts=0,trx=0) Rx Resource Indication
DRSL ERROR bts_trx.c:236 (bts=0,trx=0) chan_nr 0xc7 cbits 0x18:
(bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED) is not GSM_PCHAN_OSMO_DYN
DRSL ERROR abis_rsl.c:141 (bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED)
Abis RSL Rx Resource Indication: mismatching chan_nr=0xc7
Let's better check if a timeslot is capable of GSM_PCHAN_PDCH,
rather than checking if it's GSM_PCHAN_OSMO_DYN.
Change-Id: I2cac4acd4c5145c5c525c9952fdc754477ce0942
Related: SYS#5313
Now that we solved all the interdependency symbol mess, we can finally
enable call to this function.
Change-Id: Id4c724ef17beae4bb0918ebd1a809665b59e4861
These are not needed anymore since we re-introduced libbsc, specially to
avoid all this churn.
Some specific methods are explicitly required to be overwritten by
tests, so we specificially mark those with __attribute__((weak)) in
order to be able to overwrite them.
This is the last step towards fixing interdependency mess of symbols and
stubs, and requires previous patches in order to have tests apssing
fine.
Change-Id: Ic7401b8a6eb903882e30fda1cf091ac99a254ef0
This allows having it initialized automatically, as we usually do with
this type of code. As a result, tests or other apps importing libbsc
don't need to take care of calling it.
NOTE: This fix is required by follow-up patches where some stubs are removed
and hence some tests start using FSMs internally. Since tests were not
using those FSMs before, there was no need to call ts_fsm_init().
This is one further step towards fixing interdependency mess of symbols
and stubs.
Change-Id: I0e4b95b5e73fbb3844d83ba33e66786831088e1f
This is used inside group of files forming libbsc (shared files used by
several apps). Let's instantie only once inside a file from libbsc
instead of doing so on each binary.
This is one further step towards fixing interdependency mess of symbols
and stubs.
Change-Id: I9b287aa492ca6aae5fc56133e1510aff3146fe25
osmo_fsm_inst_free() must be called explicitly, otherwise the instance
is kept in the llist of instances and produces heap-use-after-free.
Note: This fix is required by follow-up patches where some stubs are removed
and hence some tests start using FSMs internally. Due to this bug, tests
will crash due to reason explain in previous paragraph.
This patch itself may introduced failures to build due to some new
interdependencies being introduced in same follow-up patches mentioned
above, which are in turn fixed by this present patch.
So they are expected to be merged together.
Change-Id: Ib0e5560efe518833f76f846d7269e82d85c186a1
Increase the reaction time at the expense of more stable loop with less
temporary oscillations.
See updated user manual documentation in this commit for a larger
description.
Related: SYS#5371
Change-Id: I46be244a5e01a74086e3a977ec3ea139742a0074
* Adds vty option dyn-bsc for ms-power-control -> mode
* Imports power_control.c from osmo-bts project
[at commit 2f3cd4b697972d8484f9a9d3b7ef634086f65fa5]
* Removes unused C/I code from osmo-bts's power_control.c
This patch then calls the power loop on receipt of measurement
reports and updates the MS Power Level accordingly.
Change-Id: Ibc307e758697eb5ca3fb86622f35709d6077db9e
From the nature of the lchan_activate_info.tsc_set and .tsc, it is easy
to forget to set tsc_set,tsc = -1 to use default TSC Set and TSC values.
Handover code is one such instance that forgets to set -1.
Change the semantics of tsc_set and tsc so that this kind of error can
not happen again as easily: use a separate bool to flag whether to use
the default config or explicit values.
Implicitly fix the lchan_activate_infos "launched" in handover_fsm.c as
well as abis_rsl_chan_rqd_queue_poll().
Related: OS#5244 SYS#4895
Related: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af (osmo-ttcn3-hacks)
Change-Id: Iae20df4387c3d75752301bd5daeeea7508966393
When the SDCCH gets released while the TCH still beeing activated, then
the ChanActivACK that is received after the TCH is activated will trigger
a segmentation fault in the assignment_fsm. The reason for this is that
conn->lchan, which holds the SDCCH at that point in time, is now NULL.
To prevent osmo-bsc from crashing, the FSM should check for the presence
of conn->lchan first. If it does not exist, the FSM should terminate.
(Assignment failed)
Change-Id: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a
Related: SYS#5627
Improve the current VTY support to allow enabling/disabling C/I logic
independent from value setting. This way C/I support can be quickly
disabled & enabled.
Reminder: changing power parameters still require VTY Command "bts NR
resend-power-control-defaults" to be excuted prior to new parameters
being applied on the BTS.
Related: SYS#4917
Change-Id: Id1224c2d9a52db2ed805c49e048d3086ed0167f5
assignment_fsm_allstate_action is only used in module assignment_fsm.c,
so lets decalare it as static
Change-Id: I90d6c11bd485e3be80efc7f146e0129d93e18458
This fixes call setup issues when more than ~1km from the tower.
NOTE: We use the last reported TA from the UE in the CHANnel ACTIVation.
When the UE is more than 1km from the tower, (unshifted) TA in the
measurement report can be 8 or greater. Once we send TA of 8 in the
CHAN ACTIV message, the lchan is unrecoverable.
Change-Id: I1c9bd5bf2fd126e62bcbec419f3499d2e0465559
Setting LOWER_CMP_N and UPPER_CMP_N for all channel types can be quite
cumbersome and end up in lengthy config files. Let's instead add a
placeholder command to apply it to all channel types of a BTS at once.
This is useful specially since a user disabling C/I capabilities
probably does so because it may require a fair amount of fine-tuning
parameters to have it working perfectly. Hence, a user not willing to
spend time configuring those parameters correctly (and for which default
ones doesn't work properly) will require quick way to get rid of C/I
based MS Power Control Loop. By disabling C/I comparison, osmo-bts will
rely on RxLev only when applying the MS Power Control Loop, which is
fine for non noisy environments.
Related: SYS#4917
Change-Id: I0e1a1a9228a15e9ec9c41b7952b03e1d25309706
Completely describe the 'rf_states' string elements (in one place), and
fix the missing <rsl_status> item in bsc_ctrl_commands.c comments.
Related: SYS#5542
Change-Id: Ifc3610c344b3e270111e2f6c5155a6fb90d8f2ac
The mgw-pool now allows to set a decription for each MGW /MGCP client
instance. Update the documentation so that it reflects the current
state.
Change-Id: I3026e027bba1a9a12ceca64e96df993b5957cb1d
Related: SYS#5091
Add per-TRX command to lock/unlock single TRX.
(Besides the global root-node rf_locked command setting the global RF
policy.)
Corresponds to VTY command: 'bts N' / 'trx N' / 'rf_locked (0|1)'.
Related: SYS#5542
Related: I2bb5096732f75a7341c7e83951e63c5a2038b469 (osmo-ttcn3-hacks)
Depends: I4dac826aab00bc1780a5258b6b55d34ce7d50c60 (libosmocore)
Change-Id: Ie46fd730797b64fb185d705c3507e36f5f23ef4b
These commands return a listing of OML state, RF policy as well as RSL
connection status for each TRX in the form:
<bts_nr>,<trx_nr>,<opstate>,<adminstate>,<rf_policy>,<rsl_status>;<bts_nr>,<trx_nr>,...
For example, the root node 'rf_states' may return:
0,0,operational,unlocked,on,rsl-up;1,0,operational,unlocked,on,rsl-down;2,0,inoperational,locked,on,rsl-down;
A 'bts.N.rf_states' returns the same form of string, but lists only the
TRX for the given BTS nr.
Note, there is already a CTRL command 'bts.N.rf_state' (singular
'rf_state', not plural 'rf_states'), which only reflects the overall
status of all TRX combined. This new command has per-TRX resolution.
The rf-policy is so far always looked up in the global gsm_network flag,
as does the old 'rf_state' command; see osmo_bsc_rf_get_policy_by_bts()
which does not depend on the specific BTS at all. This may be worth
revisiting in the future, so I am already including the rf-policy in the
rf_state string for each TRX, even though it is globally identical.
Related: SYS#5542
Related: I01e6f391a5e71b0606c42be9b57f8a1687d59bcb (osmo-ttcn3-hacks)
Change-Id: I14fa2678fc8f2c11a879c5e9615ac552782c5b7e
TS 45.008 section 4.7.1:
"""
Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS
shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a
range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to
the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a
time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes
place or not.
"""
Since the reported MS_PWR in L1 SACCH Header is, according to specs, the
one used for the last block of the previous SACCH period, it becomes
clear the first SACCH block after a requested MS Power Level change by
the network may contain mismatches between the announced MS_PWR by the
MS and the measured Rxlev/RxQual. Hence, let's better use a
P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second
SACCH block.
Related: SYS#5371
Change-Id: Iade5b597e0e56b07c6d78995fcec7c641e4e643f
While NACC was initially developed, it became clear there was need for
a way to interact PCU<->BSC in order resolve ARFCN+BSIC into CGI-PS
for later RIM usage.
Hence, this resolution was first (until today) implemented using an out
of bands RPC system using the CTRL interface, which required specific
config to be written and matches in osmo-pcu and osmo-bsc VTY (ip+port
of the CTRL interface to use).
However, this has several shortcomings:
* As explained above, specific configuration is required
* Since recently, we do support BSC redundancy in osmo-bts. Hence the BTS
may switch to a BSC other than first one. If that happened, that'd mean
the CTRL interface would still point to the initially configured one,
which may not be the same currently serving the PCU.
During recent development of ANR related features, a similar need for
PCU<->BSC was required, but this time it was decided to extend the IPA
multiplex of the Abis OML connection to pass PCUIF messages,
transparently forwarded to each side by the BTS.
This has the advantage that connection PCU<->BTS is handled by BTS and
both sides send messages transparently.
Let's switch by default to using this new interface, while still
maintaing the old way for a while (announcing them as deprecated) to
avoid breaking existing deployments until they are upgraded to new
versions of osmo-pcu and osmo-bsc.
Change-Id: I9073a121564503f483c84263ac72476041e47c03
Related: SYS#4971
So far we were inherting the bs_power in used when activating an lchan
for an MS for which we already had previous lchan. For instance, when an
MS is first assigned an SDCCH, and later on, it is assigned a TCH to
place a voice call.
Doing so is, however, not correct because current and old lchans may be
placed on different TS or even on different TRX, which means they will
have different BS Power restrictions. In the scenario described above,
for instance, an SDCCH could have been assigned on C0 and hence have
a bs_power of 0, and later on, whenever the TCH lchan as created, it
would have inherited the C0 bs_power despite it may have been possible
to use a different (lower) max bs power.
Furthermore, the lchan->bs_power_db basically stores the *maximum* bs
power reduction. Hence it makes not sense at all to copy over the value,
since it is anyway not updated from MS measurement reports so far
anyway.
Fixes: 997a257f8d
Related: SYS#4919
Change-Id: I4a7736aa9a1395e0cc118b98b69896bd0f1e94e6
A previous commit (Feb 05 2021) moved copy of TA value to some other
place to fix some related issues, but forgot to update the comment.
Fixes: b03e73f27b
Change-Id: Ia10038919b6650dff45b7233f58fea94e9808712
Testing has shown that the Training Sequence Code in pre-chan-ack mode
is inaccurate (only worked with a BSIC that incidentally yielded the
same TSC value as the wrong TSC value sent in the IMM ASS msg).
Move the code setting the correct TSC and TSC-Set to the first stage of
channel activation (lchan_fsm_wait_ts_ready_onenter()) so that it is
available for both pre-chan-ack and pre-ts-ack Early-IA modes.
Have a separate function for setting the preliminary values requested in
Channel Activation (lchan->activate.*) into the accepted operative
places (lchan->*). Call this early for early-IA modes.
Hence the TSC and TSC-Set used in the early IMM ASS message is now the
correct one, and the same as sent during Channel Activation.
There shouldn't be any, but if there are other values besides TSC
suffering from the same problem, they are now also set to the right
values before sending IMM ASS early.
Related: SYS#5559
Related: I4479244b0c53648e62e84e1ebf986f51d659484f (osmo-ttcn3-hacks)
Change-Id: I9f26074154600d854a0b3baee2f38a6666f4cb56
bs_power_db, as its name suggests (also check vty code and
rsl_tx_chan_activ()) contains value in dB, not in 2dB steps.
Change-Id: I76bd6bb1b307ab75ba1292865747419228e0687a
This commit extends existing VTY and RSL infrastructure to configure and
manage MS Power Parameters used in MS Power Control loop, by adding
support to set up Carrier-to-Interference (CI) parameters.
Using C/I instead of existing RxQual is preferred due to extended
granularity of C/I (bigger range than RxQual's 0-7).
Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance"
Table 10.3) provides detailed information about expected target values,
even different values for different channel types. Hence, it was decided
to support setting different MS Power Parameters for different channel
types.
These MS Power Parameters are Osmocom specific, ie. supported only by
newish versions of osmo-bts. Older versions of osmo-bts should ignore
the new IEs added just fine. The new IEs containing the MS POwer
Parameters are not send for non osmo-bts BTSs, hence this commit is
secure with regards to running osmo-bsc against an ip.access BTS such
as nanoBTS.
Related: SYS#4917
Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca
Change-Id: I7e76ec47b323d469f777624b74b08752d1f5584f
So far we have stat items per BTS. Add stat items summing overall BTS
status.
Add stat items:
- num_bts:oml_connected
- num_bts:all_trx_rsl_connected
- num_bts:total
- num_trx:rsl_connected
- num_trx:total
Related: SYS#5542
Related: Ic1b35b7406547f92818afe399a2383d154576409 (osmo-ttcn3-hacks)
Change-Id: I2057a798e681a169cc03243a09b3d6449734c010
The MGCP proxy which is built into osmo-bsc is used to tunnel MGCP
messages through an SCCP-lite link. This is an SCCP-lite specific
implementation detail that is not present in SCCP/AoIP.
Change-Id: Id3a8c45ae38d6b9d9c106a9e83b3cbfff919650d
Related: SYS#5091
Since the libosmo-mgcp-client now supports MGW pooling, lets use this
feature in osmo-bsc. Large RAN installations may benefit from
distributing the RTP voice stream load on multiple media gateways.
Depends: osmo-mgw Icaaba0e470e916eefddfee750b83f5f65291a6b0
Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d
Related: SYS#5091
To configure temporary overpower, new VTY commands are added. This patch
also addes the logic needed to attach the temporary overpower IE to the
RSL CHANNEL ACTIVATE message.
Change-Id: I488a91bb4ed86f630db56564a0cd293f39f0f690
Related: SYS#5319
TSC was initially set to -1 (to be picked by callee), but erased when
using designated initializers later on in the function, hence TSC being
set to 0. As a result, TSC 0 would be requested to the BTS, which may
have configured a different BSIC containing BCC!=0.
Related: OS#5219
Change-Id: I26813561ee9e7783a4004f32225f19296bd6319c
We already have MSC connection stat items, but for hysterical raisins
there are separate such stats for each MSC. Hence we have N connection
counters, each being either 0 or 1, for a single MSC.
Add a new stat counting the *overall* MSCs that are connected,
and one indicating the total number of configured MSCs.
Related: SYS#5542
Related: I178dcf4516606aa561d47b06061b8a416d3c40cf (osmo-ttcn3-hacks)
Change-Id: If76bbf9b3adb64c68d5c31c6b526fa71a99996ae
Instead of having static const structs in header files (which end up
duplicated in each and every compile unit!), have one .c file with the
rate_ctr and stat_item descriptions.
Related: SYS#5542
Change-Id: I8fd6380b5ae8ed2d3347e7cfbf674c30b6841ed9
Allow resetting the BSSMAP link from VTY, for BSC_Tests.ttcn.
In the field, detecting that an MSC is lost is done by getting three
connection failures in a row. For the BSC_Tests, it is easier to just
provide a VTY command to reset an MSC's link status.
I want to add tests that verify the stat items reflecting the MSC
connection status. To be able to run a test expecting fewer connected
MSC after a test that launched more MSCs requires the links to be reset.
Related: SYS#5542
Related: Ice3056dc46c94f9399f8379db7aeb7193782f2f2 (osmo-ttcn3-hacks)
Change-Id: I1975941b790d2b30d0904d41e456220cba26ecff
Some UMTS capable phones (such as SE K800i) send this message
together with the 'normal' RR Classmark Change, what makes
osmo-bsc log the following warning:
DCHAN NOTICE gsm_04_08_rr.c:1037
lchan(0-0-1-SDCCH8-0)[0x562ea76d3ab0]{ESTABLISHED}:
(type=SDCCH) Unknown RR message: UTRAN Classmark Change
We don't handle it, so just ignore without logging anything.
Change-Id: Icb8e44c9a06519ead9c3dc9308788c23505d4bb1
Add explicit indexes like [BSC_STAT_NUM_BTS_TOTAL] = { ...
BSC_STAT_NUM_BTS_TOTAL == 0 and the first item of bsc_stat_desc of
course has index 0, but when grepping the code, it looks like
BSC_STAT_NUM_BTS_TOTAL is missing a name definition.
Same for MSC_STAT_MSC_LINKS_ACTIVE and MSC_STAT_MSC_LINKS_TOTAL.
Related: SYS#5542
Change-Id: Ie47e0857c41d517a9b37be96f6669d1825d24a6d
Commit below added support for ACC ramping based on channel load, but
documentation was not updated with it.
Fixes: 1e5e7004dc
Change-Id: I8701386b35ccdebfc843fd00535091648e52f739
Add experimental 'pre-ts-ack' to the 'immediate-assignment' options:
send the IMM ASS even before a dynamic timeslot is switched. This
possibly saves an Abis roundtrip, but may be racy.
When pre-ts-ack is chosen, already do the IMM ASS before the dyn TS
pchan switch is ACKed.
In Immediate Assignment, in case the dyn TS is not ready yet, get the
pchan kind from lchan->type, which already reflects the target type, and
not from ts->pchan_is, which still reflects the previous pchan type.
Related test is in I2ae28cd92910d4bc341a88571599347a64a18fe5
Related: SYS#5559
Change-Id: I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74
When 'immediate-assignment pre-chan-ack' is set, send the Immediate
Assignment directly after the Channel Activation, not waiting for the
Activation ACK, to save an Abis roundtrip.
Related test is in If71f4562d532b6c5faf55f5fd073449a8a137ebf
Related: SYS#5559
Change-Id: I56c25cde152040fb66bdba44399bd37671ae3df2
This patch adds only the VTY config option without any effect, to ease
patch review.
The implementation follows in I56c25cde152040fb66bdba44399bd37671ae3df2
The new config option is written so that further variants of Immediate
Assignment sequencing may be added easily.
See also I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74.
Related: SYS#5559
Change-Id: I710343d1728153faf3db9758ff5a1ef26bb8d3d4
Looking for a bug, I spread this logging to understand what was
happening. Might as well keep it.
Related: SYS#5559
Change-Id: I46b660cd51a41e561712a0bd849ce0ee8d1a9588
The function gsm48_lchan2chan_desc_as_configured() dups
gsm48_lchan2chan_desc() with merely a different pchan type
(ts->pchan_from_config instead of ts->pchan_is).
In an upcoming patch, I would like to do the same, just with yet another
pchan value (derived from lchan->type, because that reflects the channel
type even before a dynamic timeslot switched its pchan type).
So replace gsm48_lchan2chan_desc_as_configured() by
gsm48_lchan_and_pchan2chan_desc() with explicit pchan arg;
also call this from gsm48_lchan2chan_desc(), reducing code dup.
gsm48_lchan2chan_desc_as_configured() had more concise error logging.
Absorb that into the new gsm48_lchan_and_pchan2chan_desc().
Add gsm_lchan_and_pchan2chan_nr(), like gsm_lchan2chan_nr() just with
explicit pchan arg, to be able to pass the pchan down from the new
functions mentioned above.
Related: SYS#5559
Change-Id: I67f178c8160cdda1f2ab5513ac4f65c027d4012f
The bottom of the function changes the lchan state. If a failure branch
is reached, that should no longer happen. Change 'break' to 'return' in
four places to not mix up the channel release.
Related: SYS#5559
Change-Id: I4674752ab4f1c8e8147ef3366f90e9ea2abd5aec
The option -l ("The local address of the MGCP") is still present in the
commandline help and the manual, but it is used nowhere and osmo-bsc
exists when it is used. Lets remove it.
Change-Id: Ia295f4414e0d6e78b388c0c72f1a5b8df8bc3d7e
When OsmoBSC is restarted, it does not automatically clear the calls on
the MGW. However, this is an important part of the configuration to
avoid trouble with resource leakage on the MGW, so lets make (especially
novice) users aware of that option.
Change-Id: I19c499c6ac83d7f9437b18b372977f6f2d518adf
Depends: osmo-mgw I47e7ff858d5067b46d52329be5f362ff61c0dff8
Related: SYS#5535
The if conditions for logging an lchan change made it look like
new_lchan might actually be NULL, which it never is. So rather pin
new_lchan as non-NULL with an assert and simplify the logic.
Related: CID#237146
Related: b0d854556d
Change-Id: I8859c6cb9b3b15287e339ce4b6815b946965d0d9
The previous naming was confusing since when appearing on log files it
seemed to mean the reason was mainly only call reestablishment, when it
actually means either call establishment (the usual reason) OR call
re-establishment (should happen seldomly).
Let's add some parenthesis to make it clearer.
Related: SYS#5548
Change-Id: Id2dccd71803335c284a5ba271fa7f7890d253c27
In the command
bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> deactivate fr
the final argument indicating the channel type does not make sense and
is not actually used. Define a separate vty command for 'deactivate', so
that it doesn't require arguments only used for 'activate'.
Change-Id: Ibdeca3b1d75b9f6092f566544e9d5f4da67fffce
For a call re-establishment, the MS shows up on a different cell and
requests CM Re-Establishment (3GPP TS 24.008 9.2.4). As soon as the
Layer 3 is established, the MSC will clear the first A-connection; the
re-establishment *has* to happen on a new separate A-connection. So for
a brief moment we must allow two distinct A-interface connections to be
used for the same subscriber.
Tested by BSC_Tests.TC_cm_reestablishment
added in I1e7d446644f46b8a0a94688e618ffb4f23a8900e
Related: SYS#5130
Change-Id: I2da9a971dd36c4289a78040adfe85704c8282c59
Usual allocation mechansim, when some signalling channel is needed,
first tries to reserve an SDCCH, and if all of them are exhausted, then
attempts to reserve a TCH as a last resort.
This, however, may cause TCH starvation under certain situations, for
instance if there high load on other services (LU, SMS, etc.).
Hence, it may be desirable for the operator to forbid reservation
of TCH slots once SDCCH become exhausted. This commit is thus adding a
VTY command which allows forbidding it. The default behavior (allow using
TCH timeslots when SDCCHs are exhausted) is kept as before.
The above mentioned prohibition is applied only to non-voicecall related
signalling services. That's because voicecall services will end up
requiring a TCH anyway, and forbidding reservation of TCH straighaway
when SDCCHs are exhausted would mean no voice calls could be initiated
while still TCHs would be available.
Related: SYS#5548
Change-Id: Ib08027125145df26602069bfb51847063b0ccc0c
Every time a new file is added in osmo-bsc, it ends up being a pain
because its .o file has to be included to other tests/util binaries, or
stubs need to be added.
Let's instead bundle all .o files together in an .la file and pass that
around.
Change-Id: If91dc589ea1e476da105b58846d1c3e720a439e1
Adds gsm_bts_stats_reset() to clear the stats and calls it from the
different models.
Change-Id: Ic42687cd73e3546edaa99fb1268a5960ffa43b12
Related: SYS#5541
If the RES IND message is invalid, let's not return ENOENT which
translates to "No such file or directory", instead return EINVAL.
Related: SYS#5313
Change-Id: Ifd700e90c881874d428f2860603a4ddbf13d705e
If all channels of a BTS are in use and there are no interference
ratings to be reported, the Resource Information IE may be empty. Do not
log this as an error, it is not something that needs operator attention.
Related: SYS#5313
Change-Id: I75b851ef1269674f43db3fb3a48518e76182d7f0
As seen in osmo-bsc log:
DCHAN ERROR abis_rsl.c:2287 lchan(12-0-2-TCH_H-1){BORKEN}: Event LCHAN_EV_RLL_REL_IND not permitted
Related: SYS#5523
Change-Id: Idc7796d41f3483c89559746d9a00fdf32bf67c57
We already looked it up, it's not necessary to look it up again by
calling lchan_select_by_type(). Let's instead call
lchan_select_set_type() directly on the lchan pointer.
Related: SYS#5309
Change-Id: I1054c18f58c9e249f263e3e97a365a1fd8b03a93
It's an easy helper, but it helps in standarizing and finding similar
places in code.
Morevoer, it will be used in follow-up commit where we first use
lchan_avail_by_type and finally we select it in a later stage.
Change-Id: I025a40962a5e5d40543b297a0760e47618fb525c
The VTY handover_vtc.c offers a large number of handover specific
settings. Those settings are (with one exception) auto generated using
macros. Lets add an equivalent for the control interface that uses the
same auto generation mechanisms.
Change-Id: I12f143906818fd6b16e8783157cbb1eb51e49ffc
Depends: libosmocore I53fc207677f52b1dc748b01d58424839cdba807c
Related: SYS#5369
Clarify that filling half-used TCH/H first only happens on dynamic
timeslots, not static ones.
Related: SYS#5313
Change-Id: I5213459fb7fb201361ce0d6198fc0c2c745deee1
In a discussion about the effect of interference levels, I noticed that
there is not sufficient clarity about how strongly the preference of
static timeslots is ranked. This test helps to show what we have.
Related: SYS#5313
Change-Id: I0911cd74613045d9fbe29d04eaef036d32049b92
The VTY defun already indicates BSC_VTY_ATTR_RESTART_ABIS_OML_LINK
correctly, but so far we would immediately start using the new values
internally, and wrongly interpret interference levels. Fix that.
Have bts->interf_meas_params twice: interf_meas_params_cfg for the VTY
configured values, and interf_meas_params_used for the values that the
BTS actually knows about, after they were sent via OML.
In a running BSC, when changing the interference level boundaries on the
telnet VTY, the BTS is not immediately told about the change. That would
require a BTS restart. Hence store the cfg values separately in
interf_meas_params_cfg. For comparing/printing interference levels in a
running BTS, only employ the values that were actually sent via OML and
placed in interf_meas_params_used.
Related: SYS#5313
Change-Id: Iad8cf4151ff7f86dc0549158ed5d91d788d40b1f
This commit improves some cosmetic and logical aspects from recent
commit (see "Fixes" below).
* Fix typo s/free_tcch/free_tchh/"
* Improve some comments
Fixes: fdb87343d7
Change-Id: Id6217c929068b0182cb2d4a9922bfbf544c8c75d
Hold off re-assignment after an intra-cell re-assignment due to low
rxqual.
Adjust test_amr_tch_h_to_f_rxqual.ho_vty to show the changed behaviour.
Related: SYS#5198
Change-Id: Id00a07313fe04eec509b336c0637b59c707760e0
First add a handover test script that shows the behavior without the
low-rxqual-assignment penalty timer implemented. When implemented, the
changes to this test script will show the change in behavior.
Related: SYS#5198
Change-Id: I799fce709c86401546ccfe41b9f57fd579bcd987
With recent addition of fake time in handover_test ('wait cmd'), show
how a penalty timeout in handover decision 2 passes and allows a
handover again after due time.
Related: SYS#5198
Change-Id: I65e59cc7309778cf9d71612669ce84d101c8135e
Use recently added fake-time 'wait' command to show how the lchan in
LCHAN_ST_WAIT_AFTER_ERROR recovers as soon as timer X3111 has passed.
This prepares for also waiting for the penalty timeout to pass.
Related: SYS#5198
Change-Id: I8f7668b6d08a0dac9e90d2358955f9d5099d39fa
Add a 'wait' cmd that lets (fake) time pass.
An ucoming patch will show the
first use of this: "test_penalty_timer.ho_vty: show lchan recovery"
I8f7668b6d08a0dac9e90d2358955f9d5099d39fa
My actual original reason to add this follows in patches
- "handover tests: test passing of penalty timeout"
I65e59cc7309778cf9d71612669ce84d101c8135e
- "hodec2: add low-rxqual-assignment penalty timer (2/2)"
Id00a07313fe04eec509b336c0637b59c707760e0
Related: SYS#5198
Change-Id: Ia6b5696adef7e7bf649473b4d79b96acf3aa59e3
To be able to add a fake time to handover tests, the penalty timers need
to use an osmo_* time source.
There already is a fixme comment rightfully asking for a monotonic
clock, so this change is overdue anyway.
An upcoming patch will prove that this works:
"handover tests: test passing of penalty timeout"
I65e59cc7309778cf9d71612669ce84d101c8135e
Related: SYS#5198
Change-Id: Ifb1ab3165db50511aed4f65aa445798367d7e19e
In expect-ts-use, indicate a busy lchan with letter '!'.
The code is a bit complex because of the choice made earlier to show two
TCH/H subslots as "TCH/HH", "TCH/H-" or "TCH/-H" depending on the
subslot states:
- show "-" as a shorthand for "all subslots UNUSED"
- show a "TCH/" prefix only when there is any "H" or "F" following, i.e.
when any subslot is actually established
- if a subslot is busy (any other state besides ESTABLISHED and UNUSED),
indicate the subslot as '!'.
The spectrum of reported state strings for TCH/F is:
TCH/F ! -
For TCH/H:
TCH/HH TCH/H- TCH/-H TCH/H! TCH/!H !- -! -
The only current test affected is test_penalty_timer.ho_vty, where a
failed handover leaves an lchan in LCHAN_ST_WAIT_AFTER_ERROR. Adjust
that test.
Rationale: I will soon add tests to verify the accurate timeout of a
handover2 penalty timer. While implementing, I noticed that immediate
retry of the handover ends up in timeslot 2, because timeslot 1 is still
in WAIT_AFTER_ERROR. Instead of working around that, I would like to
explicitly show the error state in the test -- it is an important
aspect.
Related: SYS#5198
Change-Id: I735ce7e2c3e0e450d3f76047d7e47691fe889cad
In an upcoming patch, handover_decision_2.c will use this indicator to
decide whether to start a penalty timer:
"hodec2: add low-rxqual-assignment penalty timer (2/2)"
Id00a07313fe04eec509b336c0637b59c707760e0
Related: SYS#5198
Change-Id: I5de385e0666f716184a62e6e70d656545ac5d2ee
In case an MS requests a channel to establish a voice call, we usuually
try to assign an SDCCH to negotiate the call and finally make the MS
switch to a TCH. However, it doesn't make much sense to provoke a switch
of a dynamic TS into SDCCH8 if that would mean we end up with no TS
available for TCH at the next step close in time. In that case, we are
better assigning the TCH directly so that the full call can be
established successfully.
Related: SYS#5309
Change-Id: I3b32968949a7bdcbebf5a823359295bac51d8e08
The rach control parameter value that controls the usage of
call-reestablishment is currently hardcoded. Lets add a VTY option for
this so that we are able to configure call-reestablishment
Change-Id: Ia18c1dde4c001cb4d423f694f8bc146adfd77daf
Related: SYS#5130
Fix for:
handover_test.c: In function 'res_ind':
handover_test.c:1094:30: error: 'ts_str' may be used uninitialized in this function [-Werror=maybe-uninitialized]
char subslot_val = ts_str[lchan->nr];
Fixes: f76424 ("RES IND: add test_resource_indication.ho_vty")
Change-Id: I398ba24b945bad96896eeb5ddbaff9c48bacf8ab
In lchan_select, do not return on the first available lchan, but iterate
through all available lchans. Among those that would match, pick the one
with the lowest interference level as indicated by earlier RES IND.
Lchans that have no interference ratings are picked last.
This feature is off by default, enable per BTS with
network
bts N
channel allocator avoid-interference 1
osmo-bsc still does the same ascending/descending lchan allocation as
before this patch with the default setting of:
channel allocator avoid-interference 0
Related: SYS#5313
Change-Id: I844494092193811dfd9fa4d52983cbaed0fc9248
Show that osmo-bsc does not yet take Resource Indication's reported
interference levels into account. (An upcoming patch will change that.)
This test is not actually doing any handover, but it is using the
handover/*.ho_vty scripting that was intended for handover testing.
(Like test_dyn_ts_favor_half_used_tch_h_as_target.ho_vty does.)
Related: SYS#5313
Change-Id: I56ec61196a1e103f0b4caf18d25d8222bb82cf87
Store the config option whether the channel allocator should try to
avoid lchans with higher interference levels reported in RES IND.
The actual implementation of avoiding interference follows in
I844494092193811dfd9fa4d52983cbaed0fc9248
Related: SYS#5313
Change-Id: I8b62d0b41ad9e908b27713db9219e3dbc1ebaab7
call lchan_reset() after allocation, to make sure that lchan->* fields
that have a nonzero default value get initialized properly.
In particular, a future patch adds interference measurements, and an
lchan that never received any Resource Indication info should always
indicate that there are no measurements (a nonzero constant).
Related: SYS#5313
Change-Id: I700a969f5b11c21dacda9a7cad00c943dce554b3
So far handover decision 1 uses the FULL or SUBSET TDMA measurements
across all measurement reports, depending on whether the last
measurement report indicates that DTX is in use or not.
Handover decision 2 since recently uses TDMA_MEAS_SET_AUTO to choose for
each individual measurement report whether to use the FULL or the SUBSET
value, depending on each single report's DTX use flag.
Also switch handover decision 1 to heed every single report's DTX flag,
by simply using TDMA_MEAS_SET_AUTO, replacing the current decision.
Change-Id: Iebe980254b8c4a53ef9e7d720e417dc67077eff7
Add TDMA_MEAS_SET_AUTO to indicate automatic choice between FULL and
SUBSET measurements depending on DTX. So far use only in hodec2.
TDMA_MEAS_SET_AUTO looks at each individual measurement report's DTX
flag and for each report chooses FULL if DTX is not used, or SUB if DTX
is used.
The default setting for 'handover2 tdma-measurement' is still 'subset'.
To use the automatic choice, users need configure
handover2 tdma-measurement auto
Change-Id: I67dce55ccf892c8679272ee5dfedc25620f0f725
Cosmetic preparation for enabling automatic choice between FULL and
SUBSET measurements depending on DTX in handover decision 2.
Change the internal API to pass separate enums for the choices {RXLEV,
RXQUAL}, {UL, DL} and {FULL, SUB}.
Change-Id: I283e03126a6bc1f5f1b35f9801e841053edd2947
This allows quickly finding out whether the timeout is happening due to
RLL not established or whether RTP is not ready. In essence, it
indicates whether issue may be coming from MGW or from MS/BTS side.
If coming from MGW, the timer T3101 is in general not a problem and the
issue should be related to some misbehaving.
If coming from MS/BTS, T3101 may require tunning (it could be a
misbehaving of the MS/BTS too, or simply bad signal).
Related: SYS#5526
Change-Id: Ib655f71aec584962c70d84a4405d996505dff53c
As seen in osmo-bsc log during heavy load scenario:
<000f> abis_rsl.c:2171 lchan(12-2-6-TCH_H-0)[0x559b880d1f40]{WAIT_RF_RELEASE_ACK}: Event LCHAN_EV_RLL_REL_IND not permitted
Related: SYS#5523
Change-Id: Ie307872851490ae4d60c8117a5f4e2d8c2a414d6
This feature signals support to configure Osmocom Dynamic Timeslot type
as SDCCH8, on top of historically supported TCH/H and TCH/F.
The idea is that when unneeded, the TS is configured as PDCH, and as
soon as there's need for an SDCCH and there's none available, the TS is
dynamically reconfigured to SDCCH8. Once all logical channels in the
dynamic TS are released and hence becomes free, the BSC will reconfigure
it to PDCH.
Related: SYS#5309
Depends: libosmocore.git Change-Id Ifc0ca8916bd3e93e5a60a7dd7391d2588fdb5532
Change-Id: I29ac8b90168dba3ac309daeb0b6cfdbbcb8e9172
They will gain support to be activated as SDCCH/8 soon too.
Related: OS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Id5b89fe589a52ff88486435ac43809edb4b80f98
Let's make sure the null pointer is caught by the assert if ever code
ends up here with conn->lchan being NULL.
Change-Id: I404df638da6a93caa535f10fd330ea24a775bfc3
BS Power Control is not allowed on the BCCH/CCCH carrier, unless
the BTS is operating in the BCCH carrier power reduction mode.
Allow constrained BS power reduction (up to 6 dB) on active logical
channels iff BCCH carrier power reduction mode is enabled.
Take into account that the maximum power difference between a timeslot
used for BCCH/CCCH and the timeslot preceding it shall not exceed 3 dB.
Change-Id: I2cc6a86731984f586ef35b43a8d3de631f7d8a2f
Related: SYS#4919, SYS#4918
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, starting from version 13.0.0 (2015-11) there is a feature
called 'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
Introduce a VTY command to turn on and off the BCCH carrier power
reduction operation. Also introduce a CTRL command. On the
A-bis/RSL, abuse the BS POWER CONTROL message by setting
the Channel Number IE to 0x80 (RSL_CHAN_BCCH).
Currently, only osmo-bts-trx is supported. A value greater than
zero makes it reduce the power on *inactive* timeslots of the
BCCH carrier. Sending zero disables the BCCH power reduction
mode completely.
For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926.
Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783
Related: SYS#4919
The constant is called OSMO_NRI_BITLEN_DEFAULT, NRI_BITLEN_DEFAULT does
not exist and got rendered as "NRI_BITLEN_DEFAULT" in the vty doc.
Add missing vty test for 'nri bitlen'.
Change-Id: I8af840a4589f47eaca6bf10e37e0859f9ae53dfa
If BS Power Parameters IE is present in the channel activation
message, the BTS shall employ dynamic BS power control for that
logical channel and interpret BS Power IE as the maximum value.
If the maximum value is 0 dB, then it does not make sense to send
BS Power Parameters IE to the BTS, because the power control loop
would never exceed the maximum.
Change-Id: If8507992dfd90ade1edda99b72bf2420a702ccd5
Related: SYS#4918, SYS#4919
That variable is never used after being set. Furthermore, it is being
set to the same value already stored, so there's no use in setting it
and it creates confusion.
Change-Id: Ib6ee28aa9a449992f5d3dea6df7dd2b7e30e73c9
follow-up to
0256c89187
Icac06ed554fd61bf7c4bfb1d5c3739a01f2915a4
Previous patch increased the range, but let's also allow one more
argument so that the A5 mask can be fully enabled.
Change-Id: Ie8cd753e4425d7d51397e4dddc24108fa0392de4
we recently added control commands to apply vty config files during
runtime using the control interface. However, there is no command that
allows us to store the config file modifications.
Change-Id: If17095bb86f82dd8feb86eb72c4133ea3aa1c3b3
Related: SYS#5369
msg->data_len is the total number of bytes available in the buffer,
not the actual length of the payload. Use msgb_length().
Change-Id: I35bf0827ff14e84a755c1aa24a6efc06bc7b9f9b
inter-BSC into this BSC: from BSSMAP Handover Request, parse and store
Kc128. All else is already implemented: depending on the chosen
encryption algorithm, Kc128 will end up in the Channel Activation.
inter-BSC out of this BSC: nothing is needed to support A5/4, the BSSMAP
Handover Required message does not contain any encryption related
information. The MSC already knows the chosen algorithm.
Related: SYS#5324
Change-Id: I7e9590e8c96aa50086148863ad9a2741b978e614
Receive and store the Kc128 key from MSC, and use as key sent to BTS if
A5/4 is the chosen encryption algorithm.
(A5/4 in handover will follow in a separate patch)
Related: SYS#5324
Change-Id: I7c458c8a7350f34ff79531b3c891e1b367614469
Add A5/4 to the internal mask of allowed algorithms.
(Not actually working yet, A5/4 implementation follows in other
patches.)
Related: SYS#5324
Change-Id: Icac06ed554fd61bf7c4bfb1d5c3739a01f2915a4
An upcoming patch for A5/4 would need to add a kc128 arg and reject
cause rc to gsm0808_cipher_mode(). Instead prepare for less cruft by
just having a single function.
Related: SYS#5324
Change-Id: I7f7c635943990a251ae28ae7a0d69cc3a239a154
In build_encr_info(), validate the algorithm and key presence and return
negative if errors are encountered.
At all callers, handle the error case.
An upcoming patch will add handling of Kc128 for A5/4 encryption and
also wants to return error codes. This is a preparation for that patch:
I7c458c8a7350f34ff79531b3c891e1b367614469
Notice that osmo-bsc does send the key along even if A5/0 is chosen,
this patch keeps that behavior unchanged.
Related: SYS#5324
Change-Id: I125d8aabceddd5b34cb98978cee9b6d2fc8fd0f2
'vamos' is only set to true for osmobts types, hence no need to check
that condition again.
fixup for commit d37dcb9f68
'RSL: rx and tx VAMOS Channel Number cbits for VAMOS lchans'
I957eff0d2c33ec795eda75a4bff21965b0179f73
Related: CID#236318
Related: SYS#5315 OS#4940
Change-Id: I4d9afc2996d95fdc15ee1a04e31d781b595023e3
The AFS bias actually should not apply to local cell lchans, because it
makes no sense for intra-cell considerations:
- same-cell lchans obviously have identical rxlev;
- any nonzero AFS bias thus always raises the TCH/F above the TCH/H;
- for intra-cell reassignment, the power budget hysteresis is,
naturally, not applied.
So, before this patch, setting AFS bias even to only 1 would
unconditionally move all (AMR) TCH/H lchans over to free TCH/F lchans in
the same cell.
Recent patch Id40d1cf8b58410c7d4eb87407fe8b8106e352438 implements
explicit upgrade from TCH/H to TCH/F *if* the TCH/H is experiencing low
rxqual or low rxlev, as a proper replacement for intra-cell AFS bias.
Related: SYS#5198 SYS#5365
Change-Id: I315f24123ae016887ab91666870ce252e096f90f
Make sure that the target lchan has been initialized before attempting
to reassign.
I ran into this in the VAMOS tests, forgetting to set the BTS_FEAT_VAMOS
in osmo-bts-omldummy: the vty command from ttcn attempts to reassign to
a non-initialized lchan, and aborts osmo-bsc.
Change-Id: Ia77a3312dde0e4b8df9ad2f33339266bae06439d
The RSL_CHAN_OSMO_VAMOS_MASK mask applies to the chan_nr,
but the cbits variable in rsl_lchan_lookup() is chan_nr >> 3.
So the mask didn't do its job. Now it does.
A bit embarrassing how i took the suggestion to use this mask and put it
into code without testing it. It looked good enough...
Change-Id: I005c5f319bb6f14651aeb613cdff52e79f761913
Pass flag into find_alternative_lchan() indicating that a TCH/H channel
has low ratings (rxqual or rxlev, doesn't matter).
Heed this flag in the last round, the requirement A check, and allow
candidates that have equal rxlev, if they result in an upgrade from
TCH/H to TCH/F. This allows intra-cell upgrades to TCH/F.
An important point is that this patch allows upgrade to TCH/F *without*
the AFS bias setting. See also I315f24123ae016887ab91666870ce252e096f90f.
Related: SYS#5198 SYS#5365
Change-Id: Id40d1cf8b58410c7d4eb87407fe8b8106e352438
Drop terminating newline from an assignment_fail() call which causes an
erratic line feed in logging.
Change-Id: Ib56e1f6a45c7e2c235f8ef0c8dea7151481677ab
Add VTY command to trigger an intra-cell re-assignment, also allowing to
re-assign to a secondary VAMOS lchan.
Related: SYS#5315 OS#4940
Change-Id: If006f5caaf83b07675f57e5665cfa79328da55e6
Add the Osmocom-specific extension to indicate VAMOS shadow lchans in
RSL, in lchan lookup and RSL message transmission.
Note that RR messages containing cbits (Assignment Command, Handover
Command, ...) must *not* send Osmocom specific cbits to the MS. Only the
RSL messages directed to the BTS send Osmocom specific bits.
Related: SYS#5315 OS#4940
Depends: If33c1695922d110c0d2c60d5c0136caf2587194e (libosmocore)
Change-Id: I957eff0d2c33ec795eda75a4bff21965b0179f73
It's bad to abort the program for an incompatible chan_nr. Instead of
OSMO_ASSERT(), make sure that error handling happens all they way to the
original callers of gsm_lchan2chan_nr etc.
This is also preparation to add further error causes: Osmocom specific
cbits needed for a non-Osmo BTS.
Related: SYS#5315 OS#4940
Change-Id: I71ed6437c403a3f9336e17a94b4948fca295d853
There is some odd repetition of macros with all possible subslot
indexes, but now we are using the defined macros instead of magic
numbers, making it easier to see that it is correct.
Also this allows trivially adding VAMOS cbits cases to the existing
switch() in a subsequent patch.
Change-Id: I4c6ce2f4ca999c19a58909b9adb849a3b8b6ffc8
Change gsm_lchan_name_compute() to a function that in-place updates the
lchan->name. That allows calling it numerous times with the talloc
handled internally. Rename it to lchan_update_name().
Add 'shadow' to lchan_update_name() and lchan_fsm_update_id() for VAMOS
shadow lchans, and also print the lchan index that it is a shadow for,
instead of the index in the lchan array.
When set_pchan_is() updates the VAMOSness of the lchans, call
lchan_fsm_update_id(). From lchan_fsm_update_id() also call
lchan_update_name().
This is a bit convoluted for legacy reasons. There are utility programs
and C tests using bts_trx.c but not lchan_fsm.c. lchan_update_name()
lives in gsm_data.c for that reason. This patch calls
lchan_update_name() from lchan_fsm_update_id() and not vice versa to
avoid having to add stubbed lchan_fsm_update_id() functions to all
utility programs and C tests.
We can't easily unify the lchan->name and lchan->fi->id without lots of
refactoring rippling through all those little utility programs and C
tests.
Change-Id: I7c2bae3b895a91f1b99b4147ecc0e3009cb7439a
So far there is a bunch of code setting a primary lchan in VAMOS mode.
This patch now adds the actual secondary "shadow" lchans that may be
combined with a primary lchan in VAMOS mode to form a multiplex.
VAMOS lchans are put in the same ts->lchan[] array that keeps the
primary lchans. They are at most two additional usable lchans (for a
TCH/H shadow) added to either TCH/F or TCH/H.
Keeping these in the same array allows looping over all lchans easily.
The ts->max_primary_lchans indicates the index of the first VAMOS shadow
lchan.
Related: SYS#5315 OS#4940
Change-Id: I928af99498bba488d317693f3144d4fccbbe9af3
We already send the TSC Set in the RSL Channel Activation, telling the
BTS about the TSC Set. The MS needs to be instructed of the TSC Set in
the RR Assignment Command.
The first code to actually do an Assignment to a VAMOS activated lchan
will follow in If006f5caaf83b07675f57e5665cfa79328da55e6.
Change-Id: Ibf3b6d276fadf724c16a5225c03e96a27a056153
Add function lchan_activate_set_ch_mode_rate_and_mr_config() and call it
for both plain channel activation and after a mode modify that needs RTP
activation. The AMR config was missing after Mode Modify.
Related: SYS#5315 OS#4940
Change-Id: I842fe7a14a91d1ec123cb4a3f52afe34456c03e3
lchan->activate.info.ch_mode_rate should remain unchanged, it is the
immutable request data. However, for VAMOS, we will want to
automatically see that the chan_mode is chosen correctly.
As a first step, place a mutable ch_mode_rate copy at
lchan->activate.ch_mode_rate, i.e. not in .activate.info, but in
.activate. Use that everywhere.
This is mostly a non-functional change, preparing for a subsequent patch
that adds handling of VAMOS shadow lchans.
As side effect of adding lchan_activate_set_ch_mode_rate_and_mr_config()
after MODE_MODIF_ACK (enabling the voice stream after a channel mode
modify), fix AMR config: the call to lchan_mr_config() was missing.
Change-Id: Icc9cc7481b3984fdca34eef49ea91ad3388c06fe
A subsequent patch will add to this VTY command, so let's first test the
current status as a baseline.
Change-Id: I6379e306fb8fa6ec227125c6cf14893d674e7596
VAMOS shadow lchans do not exist yet, but add the indicator flag that
tells whether an lchan pointer is a primary or a shadow lchan.
In Mode Modify: based on the flag, choose a different default TSC Set
for shadow lchans; do BTS type compat checking for shadow lchan use.
Actual lchans with vamos.is_secondary == true will be introduced by
patch: 'add VAMOS secondary lchans to timeslot struct'
I928af99498bba488d317693f3144d4fccbbe9af3
Change-Id: I4072fc7703c592df699fe8e27c02df09acde0909
Put a (primary) lchan in VAMOS speech mode.
This is not yet about activating shadow lchans, this merely puts any
lchan in a VAMOS capable channel- and speech mode.
Protocol:
In RR Channel Mode Modify, send a spec conforming VAMOS channel mode as
well as an Extended TSC Set, wich adds the TSC Set to the training
sequence code value.
In RSL MODE MODIFY, send Osmocom specific extensions to indicate the TSC
Set and TSC, as well as the VAMOS channel mode; only to OsmoBTS type
cells.
- Set the Channel Mode's Channel Rate to Osmocom specific
RSL_CMOD_CRT_OSMO_TCH_VAMOS_Bm / RSL_CMOD_CRT_OSMO_TCH_VAMOS_Lm
- Add the Osmocom specific Training Sequence IE containing both TSC Set
and TSC.
(These are documented in the Abis manual.)
Implementation:
The internal API to request a Mode Modify is lchan_modify(info). Add to
this info the 'vamos' bool, set to true when the modification should put
the lchan in VAMOS channel mode or not.
When info.vamos == true, make sure the channel mode value is a VAMOS
one: in the copy of info->ch_mode_rate at lchan->modify.ch_mode_rate,
convert to the right VAMOS/non-VAMOS equivalent channel mode.
When the modification is through, set lchan->vamos.enabled
appropriately.
This patch also builds on Ic665125255d7354f5499d10dda1dd866ab243d24
'allow explixit TSC Set and TSC on chan activ / modif / assignment'
placing tsc_set and tsc values in the TSC related IEs.
Related: SYS#5315 OS#4940
Change-Id: Ibf53f4797d7491b17a33946fd7d920f038362b4c
Get rid of this artificial barrier, because Modify with active voice
stream is supported since commit
"lchan and assignment FSMs: make Channel Mode Modify more sane"
d5cb0eb8fd
I4986844f839b1c9672c61d916eb3d33d0042d747
Change-Id: I25f4a881fa32a07f97d7d6e6b812f8afc699d951
Add missing REQUIREMENT_A_TCHF to form a full REQUIREMENT_TCHF_MASK.
That allows detecting TCH/F -> TCH/H upgrades also in the requirement A
flags, where we look for any viable lchan.
Prepares for upcoming patch Id40d1cf8b58410c7d4eb87407fe8b8106e352438
which implements TCH/H to TCH/F upgrades within the same cell.
Related: SYS#5198 SYS#5365
Change-Id: Ic44615b314782423bab0ceef5810311776f92754
Fix build error:
meas_vis.c:196:16: error: 'struct gsm_meas_rep' has no member named 'bs_power'; did you mean 'bs_power_db'?
Output the value in the same format as before the change that introduced
this regression (dB / 2).
We didn't catch this regression with jenkins because meas_vis is only
built if libcdk is installed.
Related: OS#5173
Fixes: d9b7aedb ("change bs_power to bs_power_db")
Change-Id: I9ba9b491ccbde9aa14cfb14ecc551acb2bfd7674
An unintended change in default behavior was introduced in patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
Ic665125255d7354f5499d10dda1dd866ab243d24
c33eb8d569
Set tsc_set and tsc = -1 for all lchan_activate_info and
assignment_request requests to actually yield the default behavior of
selecting the TSC based on the timeslot cfg or the BSIC value.
By setting tsc = 0 implicitly, the patch caused all requests to ask for
tsc 0 instead of calling gsm_ts_tsc().
For a Channel Mode Modify in assignment_fsm, pass the lchan's current
TSC to keep it unchanged.
osmo-ttcn3-hacks Id67a949e0f61ec8123976eb8d336f04510c55c01 adds a test
to verify the expected TSC in all of the activation, assignment and
modify messages. Current osmo-bsc master fails, this patch fixes.
Related: SYS#5315 OS#4940 Ic665125255d7354f5499d10dda1dd866ab243d24
Change-Id: If12df11511fe22ea167782f776736a1a9c484b1f
A side effect is that the final cleanup part of that function is now
always called, also when num_cell == 7.
(Whether we should really clear that logging context at that place is a
different question, out of scope here.)
Change-Id: I71a402a0940857bbedbaf25d293429934706a83c
Instead of calling DEBUGPC() over and over, compose a string using
osmo_strbuf and then log it once.
Rationale:
a) DEBUGPC() is a bad idea for gsmtap_log, because each DEBUGPC()
dispatches a separate gsmtap_log packet, fragmenting the actual log line
in wireshark.
b) DEBUGPC() is a bad idea because it checks the logging categories for
every DEBUGPC() invocation.
c) using a separate function with osmo_strbuf and OTC_SELECT, we can
actually skip the entire string composition in case the DMEAS logging
category is disabled, with a single logging category check.
Change-Id: I4cb607ff43a1cb30408427d99d97c103776b6e69
The RSL BS Power IE in measurement reports is encoded as dB / 2.
Instead of using this coding all over the code, converting to dB and
often printing confusing values in logging etc, store as plain dB.
The conversions should be at the points where a "weird" format is
defined: the RSL encoding needs divided-by-two, so apply it there. The
meas_vis is (now unfortunately) defined as div-two, and so on. But
internally we now just store the plain dB value and calculate with it
without duplicating the wire decoding step everywhere.
Rename to bs_power_db to clarify the unit of the stored value.
Change-Id: I229db1d6bcf532af95aff56b2ad18b5ed9d81616
This fixes handover oscillation in the presence of power reduction on
the downlink: apply the reduced power to the cell's RXLEV in order to
not rate the current cell as weaker than it actually is.
Related: SYS#5339
Change-Id: Ifcf59964b5e2d550d79e4ba14d90962808f79dae
According to 3GPP TS 45.008, the BSS shall monitor the levels of
interference on its IDLE traffic channels. The actual measurements
are performed in the BTS and then reported to the BSC over the
A-bis/RSL link(s) in RF RESource INDication messages.
3GPP TS 45.008 defines the following measurement parameters:
* Intave: Interference Averaging period (see table A.1),
* Interference level Boundaries (see table A.1).
Both parameters are sent to the BTS over the A-bis/OML, and can
now be configured via the VTY interface. Only those BTS models
which 'speak' the OML protocol defined in 3GPP TS 52.021 will
actually get the configured parameters, others will keep using
the hard-coded parameters.
Change-Id: I99ebf57aac1f3ca7e0497c3b4f6b0738c6ed7e47
Related: SYS#5313, OS#1866
This message periodically appears in the logs with subsys=DNM and
level=INFO for every disconnected BTS. I find this message useless
and even annoying, so I propose to remove it in this patch.
Change-Id: I7e2498cc61d311ca08585b2f1c49de021b17a5a1
Without this guard, a command like this can crash osmo-bsc:
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate fr
when timeslot 0 is configured as non-combined 'CCCH'.
Change-Id: I0197a6a2595ff9dade58e37383d44d2df3b03288
CLoses: OS#5170
chan_mode_to_rsl_cmod_spd() may actually return negative on error. To be
able to check for that, handle the returned value as a signed rc before
assigning to the unsigned spd_ind.
Related: SYS#5315 OS#4940 CID#236231
Change-Id: I52e13b24ce67e288ff32dbdaa1c1759089926f5c
Use lchan->modify.tsc in gsm48_lchan_modify().
The TSC is chosen exactly once upon LCHAN_EV_REQUEST_MODE_MODIFY
(lchan_fsm.c), and that should be the only place calling gsm_ts_tsc().
All other mode modify code should just use the final lchan->modify.tsc.
This fixes an error in patch:
Ic665125255d7354f5499d10dda1dd866ab243d24
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
Thanks to coverity for actually detecting this mistake.
Related: SYS#5315 OS#4940 CID#236233
Change-Id: I87ecf7d9266f37f4c775d029e277b614671a9401
This code is available in libosmocore since ~3 years ago
(fdf8b7b1beeb0cda262c5fb060a933aa7edb5e9a). Let's use it instead of
maintaining duplicated code which diverges over time.
Depends: osmo-bsc.git Iae058c35506bc25c9f4790889b89ac46aea664b6
(contains cherry-pick of bug fixed in osmo-bsc.git).
Change-Id: I53ad3067623077b6a8737c2a0aecc8b46bf71a15
lchan->modify.info.ch_mode_rate should remain unchanged, it is the
immutable request data. However, for VAMOS, we will want to
automatically see that the chan_mode is chosen correctly.
As a first step, place a mutable ch_mode_rate copy at
lchan->modify.ch_mode_rate, i.e. not in .modify.info, but in
.modify. Use that everywhere.
This is a non-functional change, preparing for a subsequent patch that
adds handling of VAMOS shadow lchans.
Change-Id: I8a3daac0287f15a59d3688388bb13e55facb2cea
Both VAMOS- and non-VAMOS speech modes should result in indentical voice
handling. So make sure that all chan_modes are converted to non-vamos
before comparing / evaluating in switch statements.
Change-Id: I791e7966b1f8eaa3299a8a46abeb313cf5136e0b
So far we have a couple of macros iterating a specific number of lchans,
depending on dynamic timeslot state etc. With addition of VAMOS lchans,
this would become more complex and bloated.
Instead of separate iteration macros for each situation, only have one
that takes a number of lchans as argument. That allows to more clearly
pick the number of lchans, especially for non-trivial VAMOS scenarios.
Related: SYS#5315 OS#4940
Change-Id: Ib2c6baf73a81ba371143ba5adc912aef6f79238d
So far the number of usable lchans is determined on-the-fly by the
physical channel config. With VAMOS, this becomes more complex, namely
determining whether the BTS is vamos capable.
Instead of calling a function to determine the number of lchans for
every use, rather place the number of valid lchans in int members of the
timeslot struct, and initialize those during timeslot setup.
Actual use of these new fields will follow in a subsequent patch, which
introduces the ts_for_n_lchans() macro to replace current lchan
iteration macros.
Related: SYS#5315 OS#4940
Change-Id: I08027d79db71a23e874b729c4e6173b0f269ee4f
This is particularly interesting for VAMOS multiplexes, but also gives
more prominence to this rather central aspect of GSM RF.
Related: SYS#5315 OS#4940
Change-Id: I7842ff89bece6d88387dae056e350529bae6fc38
Activating / modifying to a VAMOS mode will require picking specific TSC
Set / TSC. It is a bad idea to pick the TSC in each message encoding
function, rather make this choice centrally.
So far we pick the training sequence code to use based on the timeslot
configuration, and this TSC is determined only upon encoding the RSL
messages.
Instead, pick the TSC to use upon the initial lchan activation /
modification request; store this in the request structs and pass through
the activation / modification code paths.
For VAMOS modes, we also need to pick a TSC Set. Do so also upon activ /
modif request. Note that the TSC Set is not yet applied in this patch,
it will be applied in upcoming VAMOS patches.
The activ / modif request may pass -1 for tsc_set and/or tsc to indicate
no specific choice of TSC Set and TSC, resulting in the same behavior as
before this patch.
For example, lchan->activate.info.tsc* may be passed as -1. The exact
choice for tsc_set and tsc is then stored in lchan->activate.tsc*, i.e.
one level up (the .info sub-struct is considered as immutable input
args). The lchan->activate.tsc* are the values actually encoded in RSL
messages. After the ACK, the lchan->activate.tsc* is stored in
lchan->tsc* to indicate the TSC actually in use. Same for modif.
Note that in 3GPP TS 45.002, the TSC Set are numbered 1 to 4, while the
TSC are numbered 0 to 7. On the wire, though, TSC Set is sent as 0 to 3
value. This is a weird discrepancy, odd choice made by the spec authors.
For conformance with the spec wording, I decided to pass the TSC Set
number as a 1-4 ranged value, and only convert it to the 0-3 on-the-wire
format upon message encoding. So log messages and VTY output will
indicate the first TSC Set as "1", but the first TSC as "0", as defined
in 3GPP TS 45.002, even if that is somewhat weird.
Related: SYS#5315 OS#4940
Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24
Expose the training sequence code used in the RSL Channel Description IE
as an input parameter.
So far the Channel Description IE is always composed with a training
sequence code from gsm_ts_tsc(). For RSL commands enabling VAMOS mode,
specific training sequence codes are required.
So far, all callers still use gsm_ts_tsc(), making this a patch without
any functional change. Upcoming patches will pass specific TSC as
configured for VAMOS instead, in specific places.
Related: SYS#5315 OS#4940
Change-Id: I49503a6f5d25bb3bc9a0505bd79ed1d5c4f50577
Move the conversion from chan_mode to lchan type out of the
lchan_select_by_chan_mode() function, so that the conversion can be used
by other code paths, coming up in VAMOS patches.
Related: SYS#5315 OS#4940
Change-Id: I296651ebadba81f8b3db0d9bb5b5377877a43677
Prepare for VAMOS, where there will be secondary "shadow" lchans serving
secondary MS on the same timeslots. For those, RSL messages will need to
reflect a different stream ID aka TEI, via an rsl_link_vamos.
Make sure that every code path that sends an RSL message for a specific
lchan selects the RSL link via the new function rsl_chan_link(). When
VAMOS is implemented, this function can select the proper RSL stream.
Rename gsm_bts_trx.rsl_link to rsl_link_primary. This makes sure I'm not
missing any uses of the RSL link, and clarifies the code.
Related: SYS#5315 OS#4940
Change-Id: Ifbf16bb296e91f151d19e15e39f5c953ad77ff17
So far we do all channel reassignments by Handover Command. Since
osmo-bsc now supports rassignment of ongoing voice calls, do intra-cell
congestion resolution by Assignment Command.
In effect, add support for expecting an Assignment Command in
handover_test, and expect assignments instead of handovers for
intra-cell congestion resolution test cases.
Related: SYS#5330 OS#3277
Change-Id: Id56a890106b93fcee67ac9401b890e7b63bba421
So far the assignment FSM always tried to satisfy the channel mode and
rate by either re-using the current lchan or finding a new, unused
lchan. For VAMOS however, we want to pick one specific lchan.
Add target_lchan to struct assignment_request and skip all mode matching
and lchan selection when a specific target_lchan is set.
Related: SYS#5315 OS#4940
Change-Id: I71e0d4ff4746706e0be5266e4574d70ca432e3d7
It is better design to take state change actions in the onenter
function, instead of triggering a state change and then calling
lchan_mode_modify() or lchan_activate(). The reason is that in
principle, any state change may cause error handling to abort and
deallocate FSMs.
This is also preparation for reassignment to a specific lchan in an
upcoming patch.
Related: SYS#5315 OS#4940 OS#3277
Change-Id: I9a2e7eefd4196b80671311e5dfd275893ec0e275
Firstly, do not store the encoded AMR length-value bits in gsm_lchan->*
before an activation/modify has actually succeeded.
And secondly, do not store the AMR LV structure in struct gsm_lchan at
all, but only generate the TLV exactly when a message is being composed.
In gsm48_multirate_config(), generate the LV directly to a msgb instead
of a static buffer first. gsm0408_test.c expected output verifies that
the generated LV bytes remain unchanged.
In lchan_mr_config(), introduce a target mr_conf argument, so that Chan
Act and Mode Modify may generate the filtered AMR config to different
locations (lchan->{activate,modify}.mr_conf_filtered).
Only after receiving an ACK for Activate/Modify, set
lchan->current_mr_conf from lchan->{activate,modify}.mr_conf_filtered.
Use the properly scoped lchan->activate.mr_conf_filtered for Chan Act,
lchan->modify.mr_conf_filtered for Mode Modify and
new_lchan->current_mr_conf for Handover Command as appropriate.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie57f9d0e3912632903d9740291225bfd1634ed47
The previous patch reshuffled the code without having any functional
change. In this patch, a functional change follows:
It does not really make sense to decide on AMR mode filtering based on
whether an activation request came from the VTY:
a) BTS: There is no need to skip AMR mode filtering for the BTS config
at all. There is always a BTS.
b) MSC: Instead of testing for a VTY origin of the request, rather skip
the MSC AMR config filtering exactly when there is no conn associated
with the lchan.
Move the bts filtering directly into mr_config_filter().
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9
Split off two function from lchan_mr_config() which do not directly
manipulate struct gsm_lchan members. This allows subsequent patches to
re-use mr_config_filter() for Channel Mode Modify without depending on
lchan->activate.info; allows to filter AMR modes without modifying the
state of an already active lchan before sending a Channel Activation or
Channel Mode Modify; and allows to move mr_config_render_lv() to
gsm_04_08_rr.c so that the mr_ms_lv and mr_bts_lv no longer need to be
stored in struct gsm_lchan -- they essentially duplicate s15_s0.
Rationale:
This is a follow-up for the AMR configuration in the sense that previous
patch Ie0da36124d73efc28a8809b63d7c96e2167fc412 started for channel mode
and rate, and the s15_s0 bits:
The AMR mode filtering directly manipulates struct gsm_lchan members and
takes parameters from lchan->activate.info. This makes it hard to
separate lchan activation from the Channel Mode Modify procedure.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Iebac2dc26412d877e5364f90d6f2ed7a7952351e
The GSM48_CMODE_DATA_* rates are completely unused in OsmoBSC anyway,
but there is some code in abis_rsl.c checking its value, and if we were
to start using it that is the place where it should be.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie0e065a5dca5f4a31d5d81e3528a539214a74170
The single place that calls this special case is now actually doing the
exact same thing as the general case, and this is merely code dup.
Related: SYS#5315 OS#4940
Change-Id: Ic62e8a48d3c88a1966086240a41732d169328491
I noticed during testing that an lchan used as TCH/F in fact still had
its channel mode set to Signalling -- because on Assignment, the Speech
mode used to be placed in the *previous* lchan and the new lchan was
never updated after the Activ ACK. This is unbearable confusion which I
complained about numerous times, so far mostly for cosmetic reasons. But
implementing re-assignment properly actually requires this to be cleaned
up.
Keep all volatile chan mode settings in lchan->activate.* or
lchan->modify.*, and only update lchan->* members when an ACK has been
received for those settings. So a failed request keeps a sane state.
Make sure that those settings are in fact updated in the proper lchan,
upon an ACK, so that subsequent re-assignment or mode-modify know the
accurate lchan state.
Related are upcoming patches that sort out the AMR multirate
configuration in a similar fashion, see
Iebac2dc26412d877e5364f90d6f2ed7a7952351e
Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9
Ie57f9d0e3912632903d9740291225bfd1634ed47.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie0da36124d73efc28a8809b63d7c96e2167fc412
The amr_mode parameter may be passed as -1 and is directly used as an
array index in amr_modes[]. The AMR related switch case properly checks
against a -1 index, but the EFR does not -- and should not use s15_s0.
Change-Id: I9bae5b4fb8ab8c2002fe785e130dc9faeeda892c
So far, only the MSC asked for Assignment via Assignment Request, which
we answer with a BSSMAP Assignment Complete or Assignment Failure when
done.
When Assignment is triggered for any other reason (congestion
resolution, VAMOS, VTY), we will not send any such messages to the MSC.
Additional enum values will be added in subsequent commits:
Id56a890106b93fcee67ac9401b890e7b63bba421 ASSIGN_FOR_CONGESTION_RESOLUTION
If006f5caaf83b07675f57e5665cfa79328da55e6 ASSIGN_FOR_VTY
Related: SYS#5315 OS#4940
Change-Id: Ie0cddbdb00abcec78e153f4ae6d04ce75080a111
Shows a bug / missing feature, to be fixed in
Ifcf59964b5e2d550d79e4ba14d90962808f79dae
Related: SYS#5339
Change-Id: I1cc9bc39e8695faa983819b909e0ec76f0dbc296
Subsequent patch will add a test that uses this to show a handover
oscillation problem in the presence of nonzero BS Power.
Related: SYS#5339
Change-Id: I158d4b27370ab19318f83018803853f423c89b79
The Channel Mode Modify procedure is currently implemented for changing
a TCH lchan from signalling to voice mode. For that, however, it is
re-using (abusing) the channel activation structs and state transitions,
and thus always implies activating a voice stream when the mode
modification is done.
I will add a Channel Mode Modify to enable VAMOS mode soon, so I require
separate structs and state transitions which also work on an lchan that
already has a voice stream established: a struct lchan_modify_info and
LCHAN_EV_REQUEST_MODE_MODIFY, and dedicated assignment FSM state
ASSIGNMENT_ST_WAIT_LCHAN_MODIFIED.
For the part where a Channel Mode Modify enables a voice stream after
switching from signalling to speech mode, still use the channel
activation code path, but only once the mode modification is done.
General improvements:
- To ask for a mode modification, emit an FSM event that ensures a mode
modify only happens when the lchan state allows it.
- The new lchan_modify_info struct reflects only those parts that have
an effect during a mode modification (before the lchan_activate_info
was fully populated, many values not having an effect).
- More accurate logging, indicating "Mode Modify" instead of "Channel
Activation"
A TTCN3 test for the Channel Mode Modify procedure is added in
Idf4efaed986de0bbd2b663313e837352cc139f0f, and the test passes both
before and after this patch is applied.
Related: SYS#4895
Change-Id: I4986844f839b1c9672c61d916eb3d33d0042d747
In subsequent patches, I will add enum lchan_modify_for and enum
assignment_for, I prefer to have similar lchan_activate_for naming.
Change-Id: Ia4420fcd1234dbee92e768e5a32eab13fba29ea9
Soon, there will also be enums with ASSIGNMENT_FOR_* and MODIFY_FOR_*
naming. Add the ACTIVATE_ prefix to the existing enum to clarify.
Change-Id: I12190d4d154a1da6a9ebc9a755ccc2fe382ff188
So far we were comparing the requested MSC side RTP address+port with
the MGW side's address+port, which would practically always fail, and
hence we always issued redundant MDCX even if for unchanged MSC side.
Skip the MDCX if the MSC side remains unchanged.
Emit the success event immediately if the MDCX is skipped.
Depends: Ibb488925827d9dc0ccb1f8d6d84728745d086793 (osmo-mgw/libosmo-mgcp-client)
Change-Id: If994ecef9d4269a8120b0575de9b6d0c3be19146
Change lchan_set_last_error() to macro so that the error log reflects
where the error was encountered.
Change-Id: I571fdf2d418c52d120215cf19e57a3c96d67af07
Clarify that this is the lchan that is being assigned to the MS, in
contrast to the current lchan.
Change-Id: I0de017f7c43ec495c2cd0f05f313740f42ab0bb1
This variable is the lchan that the Assignment Command should be sent
to, i.e. the MS's current lchan. The "dest" could be interpreted as the
destination of the assignment, the lchan that the MS should move to.
Change-Id: If2c102a8f1d45f84b6a765555abf7cd7a4749b0f
In practice, '+ true' may result in '+ 1', but that is not type safe. We
rely on the number of items added by summing up booleans, rather make it
explicitly 1.
Change-Id: I17a82f4f208203b748ba2d6ace0ddc06f87c1cef
A recent commit removed the references to the per-TRX description, but
wrongly removed the per-BTS in this place too.
Fixes: defb5b1200
Change-Id: Iacaa2a25633a8706bfde9e0c196fee3e5bff1639
In osmo-bsc, gsm48_multirate_config() is used in a way where the struct
amr_mode *modes always points at the full set of configured modes, and
only the AMR bits m4_75 thru m12_2 are unset to filter the used modes.
In the current test, the bits are unset to filter, but also the struct
amr_mode *modes is reduced accordingly. Instead, keep the modes fully
populated and unset only bits, like osmo-bsc does in practice.
The test results should not (and do not) differ.
Change-Id: I545de6fb66a4b74a3f08899795b4b4d9c4538f58
It's acceptable to verify an outcome by printing to an expected output.
It's unacceptable to commit those expected outputs without first
verifying that they are in fact correct!
In this case, the output has obviously not been even read, since the
length byte clearly indicates that one byte is missing from each buffer
dump.
I have now verified by hand against 3GPP TS 44.018 that each one of the
generated octets are indeed correct.
Change-Id: I92fcc7afe018a4a8dc91f0f2167e3a7835f623c9
I noticed that lchan_release() is generally called in varying error
situations, so it makes sense to generally skip the release procedure
when the lchan is already in the UNUSED state.
Change-Id: I6e9faf682d1668388d5470419110408a098b9900
Use a talloc ctx directly without an intermediate static buffer.
A subsequent patch will add a name tweak for VAMOS secondary lchans, so
it felt appropriate to first clean this.
Change-Id: Idb922605c15242a2cdc7c34668c845a179a15660
After I found that X12 was missing from the VTY config, make sure that
no timers have been forgotten in lcs_ta_req.c: change the default
timeout to -1. We will notice missing timers during testing.
Change-Id: I7c0b098622548bf0f0374c304522e6a9db0331e3
While adding timers for Channel Mode Modify, I notice that X12 is
used in lcs_ta_req.c, but missing in net_init.c. Add it so that it is
exposed on the VTY configuration.
Change-Id: I19540f64de4937b39963bb66bebb1b5d433c2be2
A crash was reported in bssmap_le_tx_reset() sending a RESET with
sccp_user == NULL. A previous patch fixes what I infer as the root
cause, but I thought let's also have this additional safeguard.
Related: OS#5134
Change-Id: I13834c4e576e8d33e67cb63e222b41255cd94875
A crash was reported in bssmap_le_tx_reset() sending a RESET with
sccp_user == NULL. Looking at the issue I noticed that when the
sccp_user is torn down, the RESET FSM should also be terminated.
Add bssmap_reset_term_and_free() to the generic RESET FSM implementation
and call from lb_stop() before sccp_user is set to NULL.
Related: OS#5134
Change-Id: If412ef990fcdde8ff88098a5169e86f05cd1c7f0
So far the function uses insane byte array magic numbers to compose the
OML "RSL Connect" message. For VAMOS, I intend to modify that message.
To ensure sanity, first change the attr composition to msgb_put*().
Related: OS#4940
Change-Id: Iba005635cf86aee1fde77d58ef203e28eed92281
"""
The old BSS shall inform the new BSS of the MS's last used E-UTRAN PLMN
in the "Last used E-UTRAN PLMN ID" information element included in the
"Old BSS to New BSS information" Information Element if this information
is present.
"""
Depends: libosmocore.git Change-Id I6280ce1abc283f1491bc6f391b2dd952df33a16b
Related: SYS#5337
Change-Id: I6cf54f9a16d598f98dc56b25f0fef56225a25a28
Whenever SRVCC EUTRAN->GERAN is performed by the CN, it will set the
Last Used E-UTRAN PLMN Id in order for the BSS to inform the MS
about EUTRAN neighbors once the call is over.
The last part (sending EUTRAN neighs) is already implemented, since same
thing is done as per CSFB. However, we lacked the first part, where the
EUTRAN PLMN Id is recorded for later use.
Actually, in both cases, we end up building the list of neighbors
without taking into accound the PLMN value (hence no filtering of
configured neighs), but it only sends such a list if any PLMN was stored
there, which means this patch is still necessary for a quick fallback to
4G after the call is over.
Related: SYS#5337
Depends: libosmocore.git Change-Id I0e55e947b6fef6dad0cf1a6c16b781bef4cc76c5
Change-Id: Ia5008f11a4c36ef8085a2037d4abddd131086e6e
This patch caused major breakage in my setup, with BSC printing at
startup: "(bts=0,trx=0) Failed to generate System Information".
And bts-trx printing all the time:
"sysinfo.c:162 PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES
value as SI3 is not available yet, fallback to 1"
This reverts commit c1a5310a3e.
Change-Id: I5da365c93aedc6668a77b82ee9b68cbec64967e3
The effects of the neighbor configuration depend on the LAC, Cell
Identity, ARFCN, BSIC configuration of neighbor cells. Make sure that
the neighbor ARFCN list in the System Information is updated.
This may seem rather aggressive: updating the SI of all BTS if only one
config item changed. But indeed even modifying one config item of one
BTS may cause a change in the neighbor relations that many other BTS may
have to the changed BTS. For example, if many BTS configure a
'neighbor lac-ci 42 23', and this cell's config changes to LAC 43, all
of those other BTS need to update their neighbor ARFCNs.
Also update the system information even before the BTS are connected and
started up. The main benefit here is that the VTY 'show bts N' command
then already lists the correct neighbor ARFCNs.
In gsm_bts_trx_set_system_infos(), make sure that the updated SI is only
sent to TRXes that are actually usable, otherwise abis_rsl_sendmsg()
spams the log with complaints that a message's dst == NULL. Still return
an error rc in case a TRX is not connected, so that the CTRL command
bts.N.send-new-system-informations accurately returns whether SI were
actually sent to all TRXes.
The desire to have the ARFCNs listed in the VTY before starting up BTSes
came during analysis for Ifb54d9a91e9bca032c721f12c873c6216733e7b1,
which fixes a bug that is now much easier to verify being fixed.
Change-Id: I2222e029fc225152e124ed1e8887f1ffd4a107ef
From 3GPP TS 48.008 sec 3.1.30 "Common ID":
"""
If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports
return to the last used PLMN after CS fallback, then it should send the COMMON ID message
to the BSS including the Last used E-UTRAN PLMN ID information element if available at
the MSC immediately following the successful SCCP connection setup.
"""
Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 "3.2.1.21 CLEAR COMMAND",
for field CSFB Indication, states:
"""
NOTE: This information element doesn't serve any useful purpose. MSCs should not send the
information element unless it is required by the recipients (due to the need to interwork
with older versions of the protocol). It is expected that in future versions of the present
document, this information element will be deleted from this message.
"""
Hence, build up the EUTRAN neighbor list based on whether we received
the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should
probably filter the list while populating it based on the received IE.
This change will also allow reusing same mechanism for SRVCC
EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found
inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST.
Related: SYS#5337
Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
For neighbors configured without explicit ARFCN+BSIC ('neighbor bts N',
'neighbor lac-ci N M', ...), actually use the local neighbor cell's
ARFCN.
So far the code looked correct on first sight, but passed an unused part
of the struct neighbor union, always resulting in ARFCN 0.
Related: SYS#5367
Change-Id: Ifb54d9a91e9bca032c721f12c873c6216733e7b1
This change will allow handling more IEs in the future, like
"Last used E-UTRAN PLMN ID" one.
Related: SYS#5337
Change-Id: I96a0e1a7491fabf7aaad62207886821ad6194927
sysmoBTS is a BTS model sold by Sysmocom, which runs osmo-bts.
The later may also work with some other back-ends, including
the genaral purpose SDR hardware. Therefore, it's more
logical to call it 'osmo-bts'.
Change-Id: I93ab4dbf483e0786c35685b75ee4ea83bd591f7b
It's already being called in inp_sig_cb(), once the A-bis/OML link
is established. There is no need to do this on the A-bis/RSL link
establishment again.
Change-Id: I435018f439181cdd046ca99fe7e01ac85e226cce
Calculating the Cell Allocation (basically a bit-vector of all the
frequencies allocated to a cell) on the OML link establishment has
several downsides and potential problems:
* Theoretically, more than 64 ARFCNs can be allocated for a cell
via the VTY interface. The problem here is that the Mobile
Allocation IE cannot contain more than 64 channels.
* The BSC's operator will neither be warned by the interactive
VTY shell during configuration, nor during the startup.
* The BSC will accept such a configuration, but then will be
unable to encode the Mobile Allocation IEs at run-time.
This change aims to improve the situation by separating part of
the logic from generate_cell_chan_list(), and invoking this
part directly from the VTY commands. This way it will become
impossible to configure more than 64 ARFCNs, neither via the
config file, nor interactively from the VTY.
Change-Id: I98211fb0684a973239f5760e1de52a24a1f4c33c
Check against NULL pointers to allow only resolving local or only remote
neighbors in resolve_neighbors(). (Though no caller exists currently
that would need this feature, it is trivial and more future-safe.)
Related: CID#220459 CID#220460
Change-Id: I8c2046335ec6f8a5d6b757446c98d8e630ee015f
The reported feature vector may contain new features the BSC is
not aware of. Report each of them individually as NOTICE.
It's normal when some BTS feature is considered as not supported
by the BSC, but a BTS reports that it is - do not log this.
Change-Id: I2f925bcdb010cb10d074bf7c82619e3ae1f8818b
Calling generate_cell_chan_list() on each Assignment Command is
quite expensive, because this function basically re-constructs
the Cell Allocation (using bitvec API) and the Frequency List
from scratch. This IE can be borrowed from pre-calculated
SI1 message, so let's do this.
Change-Id: I9c8c5ae9059ff096765412b3f3c7181a94163afc
Before, it is not clear whether the RTP is already done setting up or
the RTP is skipped entirely. This log message clarifies that.
Change-Id: I18ffcf93e82ee47413e4b2f741ffbfbb18322e1d
It is observed that a CHANnel ReQuireD with access delay
greater than 63 can be received from the Ericsson RBS.
This results in osmo-bsc sending back a CHANnel ACTIVation with
a Timing Advance IE containing the access delay value.
The RBS NACKs this, leading to a BORKEN Channel.
This patch makes the maximum acceptable access delay vty-configurable
and Ignores CHANnel ReQuireD RSL Messages with Access Delay IE greater
than that configured. Default value is 63.
Related: OS#5096
Change-Id: Ie8987bcc0e43921bc753162b77a0efc68799b3ce
The neighbor configuration storage is fundamentally broken: it requires
all local cells to be configured before being able to list them as
neighbors of each other. Upon config write-back, the neighbor config
however is placed back inline with the other config, and hence a
written-out neighbor config no longer works on program restart.
The cause of this problem is that the config is stored as explicit
pointers between local cells (struct gsm_bts), which of course requires
the pointer to exist before being able to reference it.
Instead, store the actual configuration that the user entered as-is,
without pointers or references to objects that need to be ready. Resolve
the neighbors every time a neighbor is needed.
Hence the user may enter any config at any place in the config file,
even non-working config (like a BTS number that doesn't exist), and the
relation to actual local or remote neighbor cells is made at runtime.
Abort program startup if the initial neighbor configuration contains
errors.
Related: OS#5018
Change-Id: I9ed992f8bfff888b3933733c0576f92d50f2625b
This tests the opaquely designed neighbor config storage. However, a
subsequent patch will refactor the neighbor config storage, and this
neighbor ident API will change fundamentally. No need to test this.
The new storage will use the usual scheme of transparent struct and
llist, the opaque design is not necessary and just bloats. There is no
need to test a plain llist, so this test needs no replacement.
Related: OS#5018
Change-Id: I6522796bf0bbb9ab83e49168bcbff7bc70fd6c6d
So far the list of penalty timers was stored for an opaque target
pointer. That was either a gsm_bts pointer for a local BTS, or a cell
identifier list pointer for a remote-BSS cell.
Reasons to refactor penalty timers:
- The cell identifier list pointer came from the neighbor configuration
storage, but the way cell neighbor config is stored will change in a
subsequent patch. There will be no more cell identifier lists there.
- Storing object pointers is inherently unsafe -- if an object gets
removed and another gets allocated, the penalty timer could
theoretically remain in force for an unrelated object.
Rather store penalty timers for specific Cell IDs. Since remote-BSS
neighbors can be requested by a cell identifier *list*, use a
gsm0808_cell_id_list2 as key in the list of penalty timers.
Fix handover_test.c: have different CI for each local BTS. So far it was
the same LAC+CI for all BTSes, which now would make the test fail,
because any penalty timer would appear to apply to all local cells.
Related: OS#5018
Change-Id: I72dd6226a6d69c3f653a3174c6f55bf4eecc6885
Increase the number of values saved in the FIFO from 16 to 60, so there
is more time to read them out.
Related: SYS#4877
Change-Id: Ic5fd7c0fa030004fd88fee74f0028fb93c9f2d10
Allow selection of RX diversity from VTY
Options are a,ab,b
Default is 'a' so there is no change from previous behavior
Change-Id: I430762b8cfa51060841d90ba4446de73bd557c6c
This commit adds support for Selection of syncronization source.
Options are internal for E1 and external for GPS
Change-Id: Ia3d1acd6b3442238b35fc911092e12a6ac989adb
We only use libosmo-sigtran these days, so we can remove the depdency
to the old libosmo-sccp from osmo-bsc. We don't use LIBOSMO_SCCP_*
variables in any Makefile.am, nor do we #include <osmocom/sccp/...>
anywhere [anymore].
Change-Id: Ie478016ffb6e767ba10968c1ee2ab98db15a45a3
Related: OS#2601
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I4d48c0c0aa46065560a020369e3b0544385f173e
Related: OS#5034
Changing the BTS type is not supported, so don't allow it.
For example, Changing from type sysmobts to type rbs2000
may hit an OSMO_ASSERT in om2k_bts_fsm_alloc()
The default BTS type if osmo-bsc is started with an empty
configuration and the operator issues config terminal->network->bts 0
will be "unknown". This type and only this type can be
changed from the vty config node.
Change-Id: I0df97ef128a1bbd84c787654d1d842dce4dad819
The function is not really handover specific, and will be used in other
places in subsequent patches.
Change-Id: Icae8b9045e497f850f22cb3b6f93acbf61b84746
The manual currently does not mention ACCH repetition yet. Lets
add some info on how to set up ACCH repetition correctly.
Change-Id: I1e27ac955882497bbeefac0c830708dd18ad46b3
Related: SYS#5114
Many years prior to the implementation of osmo-cbc, we introduced
a way how raw RSL SMSCB COMMANMD can be injected from the VTY.
These days, people should use the CBSP interface with osmo-cbc or any
other CBC. We should not advertise the VTY command hack
as a standard feature anymore.
Change-Id: If5ddc3db989763a1f47d4cbc026e293e3134d8ef
Related: OS#4753
So far osmo-bsc would enable Uplink DPC (Dynamic Power Control) only
for osmo-bts, and the 'static' mode for all other BTS models. This
decision dates back to the time when ip.access specific encoding for
dynamic power control parameters was not implemented, and the MS
Power Parameters IE was sent empty in the RSL messages.
Let's make a step forward by enabling Uplink DPC by default for
all BTS models which declare the API for vendor-specific encoding
of the power control parameters. Currently this includes osmo-bts
and nanoBTS, both supporting ip.access specific format.
Change-Id: If86d27d4332af3d82f862737340d061e42e34eba
Related: SYS#4918
On lchan activation, we already know the Timing Advance in most
situations: from the Channel Request RACH, or from a previous lchan in
the same cell. Place this information in lchan->activate.info.ta.
So far, the lchan->last_ta (until recently called rqd_ta) was used to
store the initial TA for channel activation -- move the initial TA to
lchan->activate.info.ta, for proper scoping.
Only an inter-cell handover does not yet know a Timing Advance (until
the Handover Detection RACH is received), so indicate
activate.info.ta_known = false for that case.
If ta_known is false, do not include an Access Delay IE in the Channel
Activation message, ensuring that the BTS does not use an arbitrary TA
that is likely inaccurate.
The effect for OsmoBTS is that we will *not* start the downlink SACCH on
channel activation for inter-cell handover, but will wait for a HO RACH
first, and then use the correct TA when enabling downlink SACCH.
Related: OS#4008 SYS#5192
Change-Id: I986bf93e8acd6aef7eaf63ac962480b680aa894f
Originally, the lchan stored only the Timing Advance from the initial
channel request, hence it was called rqd_ta.
Since quite a while now, rqd_ta also stores the most recent Timing
Advance from each received Measurement Report. So rename to last_ta.
This is cosmetic preparation for an upcoming patch that clarifies
whether the Timing Advance is already known for Channel Activation.
Change-Id: I1049526a173819baeb4978db5bf018ba3f1006a0
This is a non-standard RSL message that must be sent after each traffic
channel has been established. Without it, any voice call will be
disconnected within seconds.
This is a hack; we need to store the subscribers classmark2 value and
use it here.
Change-Id: I6cb6d25e405aa888c4df4022d897330a6af9e946
Related: OS#2389
This is required in order to tell MS that osmo-pcu now supports
Network Assisted Cell Change (NACC).
Other BTS are not enabled by default since NACC support is not known to
work nor tested there.
Depends: libosmocore.git Change-Id I61991266b95d0c13d51b47906cc07846e9cf1390
Related: SYS#4909
Change-Id: If91d85331d402c3ab9c32b70c2c66cd7ba6ceb28
We cannot simply use the highest 'x' in A5/x codecs.
For A5/7 through A5/3, larger 'x' means better.
But: A5/1 is better than A5/2, so we need to prefer the former
over the latter.
Change-Id: I399fff8d07d1bfcbc6b385e90914ff6d9e00eb73
Closes: OS#4975
Name both new tests with suffix '_2' even though the first h_to_f does
not exist (yet?), to indicate the complementary nature of those two
tests.
Related: SYS#5301
Change-Id: I8c8d9d5936f713f7d02e4246eeb373916e62510b
If an emergency call arrives at the BSC while all TCH are busy, one TCH
is cleared in favor of the emergency call. However, if emergency calls
are disabled (system information), it is still possible that an MS might
try an emergency call anyway or that due to interference a regular call
might look like an emergency call (channel request reason). In those
cases the preemption must not happen and the emergency call must be
rejected.
Change-Id: I1af1f4fefcbe6a886bb5396901ce0cb2368a0e19
Related: OS#4976
When setting the BER threshold for ACCH repetition the VTY displays
wrong threshold values in the online help.
Change-Id: I4c89ad130da328aba99663e5a2931a4007772bca
Related: SYS#5114
When balancing congestion, not only look at TCH/F or TCH/H separately,
but also to take into account the effects on the other TCH kind from
using/freeing dynamic TS.
Related: OS#5298
Change-Id: I433df6f343650f9056b1bab926bc19ac1d867ad5
Add bool log argument to lchan_avail_by_type() and omit logging when
passed as false. From handover_decision_2.c, pass 'log' as false, from
all other callers pass true, i.e. for unchanged behavior.
Rationale:
Usually, we use lchan_avail_by_type() to select a new lchan to initiate
actual service. For that, it is interesting to see how osmo-bsc decides
which lchan will be used.
For handover decision 2, we since recently call lchan_avail_by_type()
for each and every handover candidate, to determine whether it will
occupy a dynamic timeslot or not (to know whether we would congest the
other TCH kind). So this happens for each permutation of source lchan
and target cell. That produces a lot of logging, out of proportion of
being useful to the maintainer.
Change-Id: Ia403f8fc853ca9ea9e81f7a7395df6b23845ebed
For handover algorithm 2, properly figure out what effects the target
cell will see for the *other* TCH kind when a handover would occupy a
dynamic timeslot.
Before this, only TCH/F or TCH/H would be regarded at a time. This
introduces detection of whether a dynamic timeslot would be occupied by
a handover, and how losing one unused dynamic timeslot affects the
congestion situation for the TCH kind that is not targeted by the
handover.
In other words, if a handover to TCH/F causes congestion in TCH/H
because of a dynamic timeslot becoming occupied, the handover will not
be performed. Before this, oscillation situations could occur.
A subsequent patch will do the same for congestion balancing.
Related: SYS#5297
Change-Id: I1536b60f03cb0aeb6ba14a72b518aec82fa572fe
The test shows a cascade of failures. When we fix the first failure, it
will change the sequence of events that follow after that. But it will
still be interesting to evaluate all the situations currently shown.
Hence fixate each stage's initial situation, by duplicating the
expect-ts-use with an identical set-ts-use. Then, when each individual
scenario gets fixed, subsequent scenarios still remain unchanged.
Change-Id: Ifeaec39ecb64b476ff1438cf987ba0403489c43b
The idea is to avoid confusion between the static PDCH and the dynamic
timeslots. The PDCH is always in 'pdch' mode, while the dynamic
timeslots are 'pdch' when they are not occupied by any TCH.
Change-Id: I1a12518d85ed891c491723e7f03f5bdd4fad980f
So far, the test only works because osmo-bsc fails to notice that
occupying the dynamic TS 1 as TCH/F does, overall, not free a TCH/H, but
reduces available TCH/H from 5 to 4 (one TCH/H freed, but two TCH/H lost
from occupying a dynamic TS). An upcoming patch will make osmo-bsc
sensitive for these cross effects between TCH/F and TCH/H when dynamic
timeslots are involved, hence this test needs to be stabilized.
By using a static TCH/F for TS 1 instead of a dynamic timeslot, the dyn
TS cross effect does not occur and this test actually makes sense.
Change-Id: I492ea095cf3e3c3fd186c889166c4ed93ab3a007
On -u, update the handover_tests.ok file that lists all tests that are
expected to run. This is necessary for the regression tests to succeed.
Update all the numerous test_*.ho_vty.{err,ok} files only when the
update arg is a captial -U, because those are usually not interesting,
except for manual comparison of test runs.
Change-Id: Id280a8d084fd84b0b7486a5c8022e5b7a26f6095
The following message makes no sense:
DRLL DEBUG gsm_data.c:844 MS Power class update: 4 -> 4
because nothing really changed, MS Power class remains 4. Neither
it makes sense to call lchan_update_ms_power_ctrl_level().
Change-Id: I519d2d1575cbb5352cc381a60513db8e0e2cb0a0
Allocating a new list of supported codecs *before* checking the
command arguments is a bad idea. The operator may simply mistype
one of the codecs and will end up with a list of NULL pointers.
The functions calling audio_support_to_gsm88() assume that this
list always does contain valid pointers, so if a new subscriber
connection gets established, or the operator simply invokes
'show running-config', osmo-bsc would crash due to NULL pointer
dereference.
Steps to reproduce:
1. In the VTY, do: 'en' -> 'configure terminal' -> 'msc';
2. Configure any invalid codec list, e.g. 'codec-list Boom!';
3. Invoke 'show running-config', boom!
Let's check the input before changing the internal structures.
Change-Id: I35b740a39c9cf3716d286e717486ef505bc61522
Fixes: OS#4946
My assumption that lchan_reset() is called on CHANnel ACTIVation
was wrong - it's actually called on CHANnel RELease. Therefore
(re)setting per-lchan BS power value must be done in the other
function that is responsible for channel activation.
Change-Id: I056c448ce017458dc4a004374ddca86d44dc35b4
Related: SYS#4918
config_write_bts_gprs() currently writes the remote address of an
NSVC even if osmo_sockaddr_str_from_sockaddr() returns non-zero
code. Thus saving a configuration with only one configured NSVC
to a file would produce the following:
bts N
...
gprs nsvc 0 nsvci 101
gprs nsvc 0 local udp port 23023
gprs nsvc 0 remote ip 127.0.0.1
gprs nsvc 0 remote udp port 23000
gprs nsvc 1 nsvci 0
gprs nsvc 1 local udp port 0
gprs nsvc 1 remote ip
and next time osmo-bsc would refuse to start due to:
Error occurred during reading the below line:
gprs nsvc 1 remote ip
The related condition consists of the following two parts:
- checking if osmo_sockaddr_str_from_sockaddr() != 0;
- checking if 'remote.af != AF_UNSPEC'.
The first one is wrong, because osmo_sockaddr_str_from_sockaddr(),
like many other functions, returns 0 on success. Let's fix this.
After the fix, the second part does not seem to make sense, because
remote.af would remain AF_UNSPEC (0) if the function call succeeds.
Printing the remote port alone does not make sense, let's avoid
printing it if the address cannot be parsed into a string.
Change-Id: I5d6cbde4f605c8184db4ade87de5644a849c05db
Fixes: I621360cab1e12c22248e33d62a9929995053ce04
For balancing load across congested cells and across congested TCH/*
kinds, instead of comparing the number of lchans above the configured
congestion threshold, compare the percent of lchans of overload.
In short, using a percentage prevents cells with less min-free-slots to
fill up 100% while neighbor cells still may have several free lchans
available.
An obvious example of why this is desirable is illustrated by
test_balance_congestion_by_percentage.ho_vty:
Cell A has min-free-slots 2, and has all slots occupied.
Cell B has min-free-slots 4, and has 2 slots remaining free.
If we count congested lchans as in current master: cell A has a
congestion count of 2: two more lchans in use than "allowed". If we move
one lchan over to cell B, it ends up with a congestion count of 3, which
is worse than 2. So when counting lchans, we decide that cell A should
remain full.
Instead, when comparing percentage of remaining lchans, we would see
that cell A is loaded 100% above congestion (2 of 2 remaining lchans in
use), but when moving one lchan to cell B, that would only be 75% loaded
above its treshold (3 of 4 remaining lchans in use). So a percentage
comparison would cause a handover to cell B.
Related: SYS#5259
Change-Id: I55234c6c99eb02ceee52be0d7388bea14304930f
This new CTRL interface allows users of this BSC (such as attached PCU)
to gather neighbor information.
This interface is needed for PCU to translate ARFCN+BSIC keys provided
by MS in the Um side into CGI + RAC keys used to identify target cells
in RIM procedures against SGSNs on the Gb interface.
This patch extends the already existing neighbor information storage in
the VTY by allowing storage of CGI + RAC (RAC couldn't be stored
beforehand).
Related: SYS#4909
Depends: libosmocore.git Change-Id If48f412c32e8e5a3e604a78d12b74787a4786374
Change-Id: Ib07c9d23026332a207d4b7a0f7b4e76c0094e379
Considering feedback by a customer, we prefer congestion balancing by
using percentage of overload instead of number of lchans of overload.
This test is intended to illustrate the change in behavior.
Change-Id: I314915718f66aec50e8dcf94569b0a52ca34b96f
When evenly distributing congestion across cells, count the number of
occupied lchans surpassing congestion, and not the overall number of
free lchans -- which disregards congestion thresholds.
Fix the bugs shown by
test_congestion_no_oscillation.ho_vty
test_balance_congestion_tchf_tchh.ho_vty
This implements a simple calculation for congestion load by counting
lchans in use above congestion. An improvement of this calculation
using percent follows in I55234c6c99eb02ceee52be0d7388bea14304930f.
Related: SYS#5259
Change-Id: Icb373dc6bfc9819446db5e96f71921781fe2026d
With 'set-ts-use', it is convenient to build a scenario of lchan usage,
but still inconvenient to send measurement reports to all lchans.
I need this for testing congestion-check, because each lchan needs to
have at least one measurement report, or congestion check is skipped.
Example:
set-ts-use trx 0 0 states * TCH/F TCH/F - - TCH/HH TCH/HH TCH/H-
meas-rep lchan * * * * rxlev 10 rxqual 0 ta 0
This patch adds the '*' for the lchan arguments, usually being bts idx,
trx idx, timeslot idx and subslot idx.
Use lchan wildcards at the appropriate places to shorten some tests.
Change-Id: I441f92348508d45e1069a3dfa1ff3842dbba97d6
Store the number of free lchans and the min-free-slots settings in
ho_candidate, instead of figuring those out in various places, to make
it easier to read.
Prepare for upcoming patch which also requires these values to fix a
bug.
Change-Id: Ie6ca5af5e8d0ebb8deaaaa637e2728008ecba517
So far it is often confusing which cell a specific member refers to.
Clarify lchan, bts, ... to current.lchan, target.bts, ...
Also move the rxlev_{current,target} to {current,target}.rxlev.
Eliminate numerous local variables to make it easier to read which side
is being used (e.g. "c->target.bts" instead of just "bts").
No functional change.
Change-Id: I06898eb745a5be548df0b76fa760ce790cfab3ed
Also add test_congestion_no_oscillation2.ho_vty which is an almost
identical scenario that does not show the bug -- because it has two more
TCH/H available in BTS 1, showing the strange behavior of the algorithm.
Related: SYS#5259
Change-Id: Idf88b4cf3d2f92f5560d73dae9e59af39d0494c0
Echo each handover_test command on the test output, to help with
understanding the exact point of a test failure.
Even nicer would be a general echo of all VTY commands, but the VTY
currently does not support that feature. Refraining from a libosmocore
patch just for these test scripts...
Change-Id: Ifc307a7d0b7e3caa355f8cee88778762b529ad71
Similar to chan act handling, clarify and safeguard HO Request handling.
Ensure that each HO Request is handled by the test script.
Place unhandled HO Requests in new_ho_req pointer, moving to last_ho_req
upon handling it. Instead of the got_ho_req flag and additional
ho_req_lchan pointer, just keep a last_ho_req pointer.
Drop a bunch of utterly useless RSL message parsing code.
Fix unhandled HO Request in test_max_handovers.ho_vty.
Change-Id: I0a664f24d7dd3d7b254b29675fdc49cd70a1a480
Do not clear pending chan act requests when sending a measurement report
or starting congestion check. This potentially left channel activations
unnoticed and dangling, e.g. for repeated meas-rep.
A typical test should indeed handle pending channel activation requests
before potentially triggering more, safeguard against this by asserting
that only one channel activation is pending.
Place unhandled channel activations in new_chan_req pointer, moving to
last_chan_req upon handling it. Instead of the got_chan_req flag and
additional chan_req_lchan pointer, just keep a last_chan_req pointer.
Change-Id: If06587058798d96afca86358030dc0c1c3c6df39
Fix flaws in picking a candidate for congestion resolution, shown in
recently added tests.
- For TCH/H->TCH/F upgrading, do not favor moving to a weaker neighbor
cell.
- When comparing dynamic timeslots on the same cell, favor a dynamic
timeslot that frees an entire dyn TS even though the target rxlev
differs.
Do not separate the passes for inter-cell and intra-cell candidates:
before, the inter-cell pass would already pick a candidate and start
handover, even though the subsequent intra-cell pass would have revealed
a better candidate. Join the intra-cell considerations into
pick_better_lchan_to_move().
The intra-cell pass was separate, because it would find the *weakest*
current rxlev, to give a TCH/H to TCH/F upgrade to the currently weakest
lchan.
Instead of the separate pass for weakest rxlev, in addition to the
target cell's rxlev, also consider the rxlev *change* in
pick_better_lchan_to_move(): For candidates that do not change the rxlev
(usually those that stay in the same cell) and that upgrade to TCH/F,
favor a candidate with weaker current rxlev.
Completely revisit the conditions in pick_better_lchan_to_move() to
yield the desired prioritization of candidate preferences.
In three handover tests, remove the "FAIL" comments and adjust to now
expect the actually desired behavior.
Related: SYS#5032
Change-Id: I2704899c85c35dfd4eba43468452483f40016ca2
Instead of passing the TCH/H -> TCH/F bias (AFS bias) in local
variables, rather store it in the ho_candidate struct next to the other
rxlev related values.
Add the AFS bias to the compared rxlev in pick_better_lchan_to_move().
Modify pick_better_lchan_to_move() to simpler semantics of returning
either a or b.
No functional change.
Change-Id: I73860abdf2a77270ca4851ad58c09767d1bb08f1
Store the rxlev of the current lchan and the target BTS in the
ho_candidate, to clarify the code.
No functional change, cosmetically prepare for
I2704899c85c35dfd4eba43468452483f40016ca2.
Change-Id: Ie6c165e17bb3c99eebc967a6bb02529db8bdfc98
In handover decision 2, choosing an lchan to move so far takes into
account only the absolute current rxlev, and it fails to look at the
*difference* in rxlev between source and target cell.
My recent feature to favor freeing half-used TCH/H does in fact not work
well. The main reason why the test for that feature passes is that all
lchans in the test get identical measurements -- which is unrealistic.
A test with differing ratings uncovers the flaw in comparing intra-cell
candidates.
Related: SYS#5032
Change-Id: Iabce1ab44b496833c19d999fc3f2903d835c357f
The aim is to pin the current basic behavior of handover decision 2,
before modifying the algorithm conditions to fix some bugs in upcoming
patches -- so far no test ensures this particular detail.
Change-Id: I68cdda21ef59c464f0af3c2eee356623e58ea1cd
Some tests want to repeat the same measurement report, typically 10
times to fill the averaging window. Instead of 10 lines saying
'meas-rep ...', allow 'meas-rep repeat 10 ...'.
Change-Id: Ib2fa81a449fb73ec7c458b0e6877d6561c79a846
In handover_decision_2.c, instead of repeating a similar loop four
times, put that loop in a function and parameterize it.
Prepare for a fix of two problems in handover decision 2, see
I2704899c85c35dfd4eba43468452483f40016ca2.
Change-Id: I7c32d08e490a88a7f044b0a71dc4b07d748dd572
An upcoming test that uses set-ts-use to release used lchans uncovered
an incomplete release, keeping the lchans occupied due to a missing
release ack. Always ack the release.
Change-Id: Ia22906bfbfcc48b7bd08473a2b17f6b0554687d3
We decided not to keep the handover_test script expected outputs
(osmo-bsc's logging output) in the source tree. Hence do not fail the
handover_tests when the output differs, just show a diff (if at all).
Change-Id: I3e9e123b41be71d1fcd9576b0bd38d2fd32353b4
We decided not to keep the handover_test script expected outputs
(osmo-bsc's logging output) in the source tree. For manual comparison,
they are still produced by 'handover_tests.sh -u', ignore them.
Change-Id: I5dda03f21b568e07cf26501ba2e0683108d408b6
Adding SMSCB messages to a BTS so far only worked if there were
existing messages with a lower scheduling period than the new message.
Before this patch, it fails for new messages if they are of equal or
lower scheduling period than the existing messages.
Change-Id: I69a05b22200b3a1ee406b0673553e135603d723b
None of those commands apply immediately, they only affect newly
established logical channels. The reason is that the related
IEs are only getting sent on channel activation / assignment.
Change-Id: I06c7851115fb31d1eb92c400d9724f4f051bd171
Related: SYS#5114
Both commands are basically doing the same thing, so we can merge
them into a single command by adding a parameter to the command
string. The VTY syntax remains the same:
do-something foo
do-something bar
becomes:
do-something (foo|bar)
This change reduces code duplication.
Change-Id: Ibe98718d8f4933926eed0e622109c9c82537f526
Related: SYS#5114
Presence of these lines in the config file does not necessarily mean
that the BTS will not perform measurement pre-processing. It actually
means that the BSC would not include the optional IEs related to the
measurement pre-processing, so the BTS may still apply its default
averaging algorythm with default parameters.
In order to avoid potential confusion, let's avoid printing them.
Change-Id: I585b5bf4fde93d66e47666e0fa9903f21a268b51
Related: SYS#4918
This fixes the following heap overflow in the SMSCB scheduler:
==109051==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d00003a9a0 at pc 0x55d77e4bedf1 bp 0x7fff8cdc4240 sp 0x7fff8cdc4238
READ of size 8 at 0x60d00003a9a0 thread T0
#0 0x55d77e4bedf0 in bts_smscb_sched_add_before /space/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/cbch_scheduler.c:64
Change-Id: If529aa905336a1b9e7a36e931c165df0ba9899ad
The existing code uses short-lived FSMs which are allocated straight
before START, and which are free'd after DONE state is reached.
While that works, it makes state introspection a bit hard, as one
cannot show the FSM states, etc.
Let's change to a different model where the per-OM2k-MO FSMs are
always around (in state INIT after object creation). While at it,
also introduce a RESET event that can reset each FSM instance back
to INIT state, i.e. in case of OML link failure.
Change-Id: Ia37cffff5c451e1d79a52ccae41ab5718b4661d4
There is only one parameter in command:
repeat dl-facch (command|all)
so indeed argv[0] must be used instead of argv[1].
Change-Id: I01efff109a33791e13b0149fc47c792d3266da71
Related: SYS#5114
For several years now we are using line lengths longer than 80chars,
let's re-format this code more in-line with our new style.
Change-Id: I8143280358c0e23ca7e32b882e952eac991e105b
This allows a given BTS model driver to initialize data structures
specific cor this BTS instance (or a TRX for this BTS instance).
Change-Id: Icbad9cdc12221c9ad997267d77e5414edcbac538
Before the recent changes, the MS Power Parameters IE would always
be included empty in RSL CHANnel ACTIVation messages iff the BTS
type is 'osmo-bts'. Then this behavior was changed, so the user
would need to enable dynamic power control explicitly.
This is a regression, let's revert it back to the old behaviour.
Change-Id: Idb453fc894584ccf4f5f8b45a24421db958e9478
Related: SYS#4918
According to 3GPP TS 45.008, section A.3.2.1:
c) Comparison of RXQUAL_XX with L_RXQUAL_XX_P (XX = DL or UL):
Increase XX_TXPWR if at least P3 averaged values out of N3
averaged values are greater (worse quality) than L_RXQUAL_XX_P.
d) Comparison of RXQUAL_XX with U_RXQUAL_XX_P (XX = DL or UL):
Decrease XX_TXPWR if at least P4 averaged values out of N4
averaged values are lower (better quality) than U_RXQUAL_XX_P.
Given that RxQual is a value in range 0 .. 7, where 0 is the best
and 7 is the worst: L_RXQUAL_XX_P must define the worst quality,
while U_RXQUAL_XX_P must define the best quality value.
Change-Id: I0f37b23ed360782f3c1f4275234c4e18a17aa89b
Related: SYS#4918
The meaningful names expose that some of those tests are apparently
quite similar.
With names like this it is far easier to see whether a specific scenario
is already tested or not, and find a test when looking for a specific
scenario.
Change-Id: I6f6d65d818fd1265e8ff94a2e0afba6392c50eb9
The handover_fsm activates voice on a target lchan only when the source
lchan has an osmo_mgcpc_ep_ci pointer for the BTS side. Since that
struct is opaque, set a fake pointer and override the
osmo_mgcpc_ep_ci_name() function so that the pointer is never
dereferenced.
This more accurately models the RTP stream setup events during handover.
Change-Id: Ibc22001bf9e9874dd3f44f0acac8b6a4c1069aa7
Do not show source file and line numbers in the log, so that the log
output remains unchanged for unrelated changes.
Also show the log level.
Change-Id: I8ebcaf16cd14881a3a41616dcff175e173db9ae8
So far we skipped the HO Detection message, because the FSM also accepts
a handover when the Handover Complete arrives without a Detection.
Rather model the real behavior.
Also send the EST IND message and RTP-ready events from the ho
detection.
Change-Id: Ib676e74f23ef9cd1b55262117822b0e110013bdc
Drop the string arrays, and move the 32 handover tests to separate
script files. Instead of the peculiar implementation and instead of
cryptic commands, implement the handover test scripts as a VTY.
handover_test.c now sets up a VTY with handover testing VTY commands. It
also features the complete and unabridged VTY configuration nodes of
osmo-bsc itself. That allows dropping various ho script commands.
Before:
static char *test_case_14[] = {
"Handover to congested cell, if RX level is below minimum\n\n"
"The better neighbor cell is congested, so no handover is performed.\n"
"If the RX level of the current cell drops below minimum acceptable\n"
"level, the handover is performed.\n",
"create-n-bts", "2",
"create-ms", "0", "TCH/F", "AMR",
"expect-ts-use", "0", "0", "*", "TCH/F", "-", "-", "-", "-", "-", "-",
"set-min-free", "1", "TCH/F", "4",
"set-min-free", "1", "TCH/H", "4",
"meas-rep", "0","0","1","0", "10","0", "1","0","30",
"expect-no-chan",
"meas-rep", "0","0","1","0", "9","0", "1","0","30",
"expect-chan", "1", "1",
"ack-chan",
"expect-ho", "0", "1",
"ho-complete",
"expect-ts-use", "0", "0", "*", "-", "-", "-", "-", "-", "-", "-",
"expect-ts-use", "1", "0", "*", "TCH/F", "-", "-", "-", "-", "-", "-",
}
After:
# Handover to congested cell, if RX level is below minimum
# The better neighbor cell is congested, so no handover is performed.
# If the RX level of the current cell drops below minimum acceptable
# level, the handover is performed.
create-n-bts 2
set-ts-use trx 0 0 states * TCH/F - - - - - -
network
bts 1
handover2 min-free-slots tch/f 4
handover2 min-free-slots tch/h 4
meas-rep lchan 0 0 1 0 rxlev 10 rxqual 0 ta 0 neighbors 30
expect-no-chan
meas-rep lchan 0 0 1 0 rxlev 9 rxqual 0 ta 0 neighbors 30
expect-ho from lchan 0 0 1 0 to lchan 1 0 1 0
expect-ts-use trx 0 0 states * - - - - - - -
expect-ts-use trx 1 0 states * TCH/F - - - - - -
Note how osmo-bsc's stock vty config nodes seamlessly integrate in the
test steps: just enter a configuration node, modify some values, and
indenting trivially takes care of exiting nodes correctly.
Running a test manually:
./handover_test test_0123.ho_vty
Instead of calling each test separately in testsuite.at, have a
handover_tests.sh script that picks up new tests just by presence of
files named test*.ho_vty.
Rationale:
It was considered to move handover tests to the TTCN suite, but there is
an advantage in having these C tests: they run super fast and catch bugs
even in the gerrit verification job, potentially saving a lot of time.
It is a reality that I need more of these tests, for dynamic timeslots
and TCH/F <-> TCH/H switches. The way the handover tests are written, as
arrays of strings containing cryptic fixed-argument script commands, has
been a pain to work with from the start, and now I am no longer willing
to endure that pain.
Change-Id: Ie238ebe41039d3fa44c9699937589e000883e052
If the user doesn't specify any CON connection groups in the config
file, then the CON is not used. The current code runs into an error
condition, as abis_om2k_tx_con_conf_req() never sends the CON CONF REQ
if the groups list is empty, but we still wait in the FSM for the
arrival of a CFG REQ ACCEPT. The CON FSM eventually times out in T10
and we proceed with the IS, ignoring the error.
With this patch, we simply skip the entire CON MO in case there is no
related configuration.
Change-Id: Ia4d5bd96734686381f04aa3b380b17a161a31174
In I68ae0bc51a565f903b47cf72f3e3dd6f1a2d2651 we started to
initialize all (TS 12.21) NM MO state to LOCKED by default,
which means BTSs not using TS 12.21 are stumbling across
a general check in bts_isdn_sign_link() and will fail to
process and uplink RSL messages.
Change-Id: I4450cc47ede4005bf4bbd4af8d5a22c78377d4cd
Related: OSE4914
Thanks to this message, there is no need to include MS/BS Power
Control parameters in every RSL CHANnel ACTIvation message.
Instead, we send them only once, and then send empty IEs.
Change-Id: I46ae4e6003a1839ee57f8e941a54bf479f7e532d
Related: SYS#4918
This change introduces two optional function pointers:
- power_ctrl_enc_rsl_params() - this function will be called by the
A-bis/RSL code in order to encode MS/BS Power control parameters
for CHANnel ACTIVation and MS/BS POWER CONTROL messages.
- power_ctrl_send_def_params() - this function will be called for
each transceiver on A-bis/RSL link establishment in order to
send default MS/BS Power control parameters.
Change-Id: Iba3ad5d8d549a6676050272f85b21c9b4c219d21
Related: SYS#4918
libosmocore > 1.4.0 is required (master, not yet released) since some
fixes done in osmo-bsc code where not cherry-picked to libosmocore APIs.
Depends: libosmocore.git I2bf5635b8536b11d69774d17ac1908019633e3af
Change-Id: I7d5e5ddd174463c2a3d957c8245d2911ce013681
Steve Langasek <steve.langasek@ubuntu.com> submitted some patches
against downstream osmo-bsc 1.3.0 because some possible null derefences
were detected by the compiler on Ubuntu s390x. Code has eveolved since
then and patch doesn't apply directly anymore, since related code
changed (we now use osmo_count in bsc_subscr_get).
The compiled allegedly claimed some null dereference in gsm_lchan_name.
In general code using that function seems to be doing checks for
existing lchan before calling it, or assuming the lchan pointer is not
null, so I couldn't find any major issue.
However, let's add a OSMO_ASSERT to make sure we can easily identify the
issue if an issue ever happens there, since the gsm_lchan_name should
clearly only be called on non null pointers.
Change-Id: If4d12cb1d95ee2a89244bb8f27df839871667387
This is needed in order to to proper feature support verification for
IPv6 when configuring the NSVC.
Before this patch, there could be a race condition where NSVC FSM
checked for BTS feature BTS_FEAT_IPV6_NSVC before it was negotiated
through BTS Get Attributes (Ack).
Fixes: OS#4870
Change-Id: I7c207eee0e331995ae04acec014fbd13d4d16280
Before this patch, Get Attributes was sent quicklyafter the OML link
became up, even if the BTS/BB_TRANSC objects were still powered off,
which is wrong since attributes should only be available after the
objects transition out of the Power off state.
Furthermore, information about get attr response already received will
be required in future patches to delay NSVC setting.
Related: OS#4870
Change-Id: I8ec39c7e1f956ffce9aecd58a5590c43200ba086
There's no real need to retrieve the trx before passing it to the
function, we can do that in the function itself and hence also simplify
the function itself.
Related: OS#4870
Change-Id: I7181510c5021ff2712c09ebc6ec8b13fdd8e8dc2
The condition was set in st_op_disabled_notinstalled_on_enter():
"""
site_mgr->peer_has_no_avstate_offline = (bts->type == GSM_BTS_TYPE_NANOBTS);
"""
However, at startup of the FSM the oneneter func of the default initial
state is not called. In any case, if called it would be too early since
the type is not known yet (because its parsed later on at the VTY with
the "type" command, that's after the "bts X" node is called and the
bts_sm is allocated.
So we need to make sure to always enable it, also for nanobts.
Change-Id: Ic6049a44ae3fca1b8e968fe800c268f579e7cad4
The only real 1-1 relationship between BTS NM objects is the one between
GPRS Cell and BTS (which is actually a BTS cell).
In our current osmo-bts implementation we don't care much since we only
handle 1-cell BTSses, but let's make the data structure organization
more generic.
Implementation notes:
The gsm_bts_sm is moved to its own file, APIs to allocate are added and
the new public object is hooked correctly in the allocation process of
osmo-bsc.
Change-Id: I06461b7784fa2a78de37383406e35beae85fbad8
MS Classmark 3 is optional, and thus can be NULL.
Change-Id: I4f1455a3db4972ea9843564b590e405c51083b47
Fixes: I39ae439d05562b35b2e47774dc92f8789fea1a57
Fixes: CID#215593 "Explicit null dereferenced"
The CTRL connect already includes 30 retries with .1 seconds delay each, so
there is no point in adding a fixed two second delay that unnecessarily drags
out test duration for each test.
Change-Id: I830fabbd037d6e945956a99aa3f5e4d4015ea165
In order to activate FACCH/SACCH repetition on the BTS, the classmark 3
IE in the CLASSMARK CHANGE message must be parsed and depending on the
Repeated ACCH Capability bit the RSL_IE_OSMO_REP_ACCH_CAP is added to
the RSL CHAN ACT und RSL CHAN MODE MODIFY. Since
RSL_IE_OSMO_REP_ACCH_CAP is a propritary IE, it may only be added for
BTS type osmo-bts.
Change-Id: I39ae439d05562b35b2e47774dc92f8789fea1a57
Related: OS#4796 SYS#5114
To be able to control the FACCH/SACCH repetition behavior inside the
BTS a one byte flag is sent to the BTS together with the
RSL_IE_OSMO_REP_ACCH_CAP IE. This patch adds the necessary VTY commands.
The sending of the flag is implemented in a follow-up patch.
See also: I39ae439d05562b35b2e47774dc92f8789fea1a57
Related: SYS#5114, OS#4796, OS#4794, OS#4795
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Change-Id: I083eaa2c30478912426e9c24a506f0b88836e190
When ICMI becomes zero for 'start-mode auto', the smod bits will remain
whatever start-mode was set in the previous osmo-bsc config. Instead, osmo-bsc
should clear the smod bits for 'start-mode auto' so that its MultiRate Config
does not vary depending on what was previously configured.
Change-Id: I1ec5bad0bce01cc425ee05ecf70c83ec662a226a
So far, the smod bits reflecting the start mode never made it to the
MultiRate Config IE: gsm48_mr_cfg_from_gsm0808_sc_cfg() always sets them
to zero, and the mode filtering fails to carry the BTS set bits.
Set smod bits according to BTS config after the filtering of available
modes.
Change-Id: I49691df01745a7c485bf165e897872c35fc4b147
Send the proper ICMI value, instead of always sending ICMI=1 regardless
of the AMR start-mode setting.
To avoid test fallout from the fix, we should first merge
osmo-ttcn3-hacks I4cff01c37d5c7e301e9a01f773b7e009a789519b
Change-Id: I577ff590d7588fd7e3ee4846c7955ab8f84cf2b1
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Iff920ff3dbeb48bd871b7578470f27fe9d0f9516
Fixes: OS#4865
The IPV6_NSVC feature is required to use IPv6 NSVC to connect
to the SGSN. The features in general should be dynamic discovered for
the BTS which support this.
Workaround for OS#4870
Related: SYS#4915, OS#4870
Change-Id: I711efca931012b8e66516f2721390e9dbdbb72a8
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (killall -SIGABRT
osmo-bsc), then the process would print the talloc report and continue
running, which is not desired.
Change-Id: I125288283af630efa20d64505e319636964a0982
Fixes: OS#4865
This was started in 2017 before the NITB split. Let's align it with
reality, mostly in terms of naming and making explicit what was
implemented.
Change-Id: Ib4e66b565a1edfc5ea8c1446f911011bfd4b1642
Shows undesired behavior of moving a TCH/H from a fully used dyn TS
leading to two half-used dyn TS, rather than moving the half-used dyn TS
that would lead to completely freeing a dyn TS.
Change-Id: I3beaa95d12ca0a19d4d1a732f3e22558e68ee29c
When a used timeslot gets moved to another timeslot for load balancing, prefer
moving a dynamic timeslot, as illustrated by handover_test.c test 30.
Rationale: freeing up a dynamic timeslot is better for PDCH availability, as
well as for flexibility in timeslots. Test 30 shows that when freeing a static
TCH/F even though a dynamic one with identical ratings is in use, later
handovers to a TCH/H may become impossible, because no more dynamic timeslots
are available to switch to TCH/H. A freed dynamic timeslot allows congestion
resolution to continue and reduce more TCH/F to TCH/H.
The scope of this preference is per-TRX, where the RXLEV ratings used for
picking a target lchan are the same by definition. In other words, this never
overrules picking another lchan that has better RXLEV.
Among lchans on dynamic timeslots that could be moved, this code favors moving
later lchans; mainly because it makes for a simpler condition in the code.
Change-Id: Ic221b8d2687cdec0bf94410c84a4da43853f0900
There are four places deciding which of 2 lchans to move, depending on average
db ratings. Upcoming patches will enrich that decision for better handling of
dynamic timeslots, so have one common function for these to avoid code dup.
Change-Id: I745dc95cf564dd330295cecb4d64dccebf55163f
Show undesired behavior of opening up another TCH/H timeslot even though
another TCH/H timeslot still has room for a second lchan. This is particularly
bad for dynamic timeslots, reducing PDCH as well as TCH/F resources.
Change-Id: If222835af92d832b848824e5466bdcaf9af8a614
In the test, show the undesired behavior of moving non-dynamic timeslots first,
because they are the first to be considered in the congestion resolution loop.
The behavior will be fixed in Ic221b8d2687cdec0bf94410c84a4da43853f0900.
Change-Id: I09ab9f2f79fa434c7279cb4d09899f69b047aa55
So far the 'meas-rep' expects the index of the MS in order of appearance, to
send a measurement report for that MS. That may seem like a simplification for
human readability, but in fact, it is confusing for a human to keep track which
MS has which index, and to which timeslot it has been handovered. When reading
the tests, it is much easier to read exactly which timeslot the measurement
report is being sent to; which MS came first is inherently not as interesting
as which lchans are currently occupied.
Change-Id: I7ab2ef604196cfe96112dfefb9aa930368bf4812
When a test wants to use N lchans, so far it has to issue N 'create-ms'
commands. Many lchan distributions cannot be easily obtained by this, because
'crate-ms' always takes the first free lchan. To shorten test setup and easily
allow arbitrary lchan distributions, this command sets specific lchans to
specific usage states in one line.
Change-Id: I6e90679bf22609fb72e53e3d11748a4070a38159
In handover tests, it can be hard to follow which lchans are currently
occupied. The expect-ts-use command is like an assertion for a specific
distribution of used lchans, and helps understanding test intentions.
Change-Id: I6f4b573de7faace2d6bfe4f58b568e69c74dd07d
Before this, handover_test channel activation and release on dynamic timeslots
failed to reflect the correct pchan type that osmo-bsc uses.
Change-Id: I3284b4565ad2c3b124442f4373243da1518206ce
Adjust 'create-bts' command so that it allows multiple TRX and arbitrary
timeslot configurations. It is now possible to write tests for dynamic
timeslots and multiple TRX.
Change-Id: Ic645cea671aa4798804666b8886f11bab5351e11
This "global" array shadows the bsc_gsmnet state and is not needed. Look up the
BTS in bsc_gsmnet like all of osmo-bsc does.
Change-Id: Ieb27403b97124771e4d28b9c69bf7c36288f396d
I will add a command to create a single BTS with arbitrary timeslot
configurations.
To limit amount of editing of the current tests, keep the current 'create-bts'
command, which creates N identically configured BTS, but rename it to
'create-n-bts'.
Thus allow the upcoming single-BTS command to take the name 'create-bts'.
Change-Id: I4853771cf23b509b7f278d04c57883332ede786d
Preparation for Ic645cea671aa4798804666b8886f11bab5351e11 to allow arbitrary
timeslot configurations in the tests.
Change-Id: Ie0d0c85552ba24802392423b60cfa3919e87563f
Allow passing timeslot config to create_bts().
Preparation for Ic645cea671aa4798804666b8886f11bab5351e11 to allow arbitrary
timeslot configurations in the tests.
Change-Id: I3ae898be4a503060c6bf30ae89115a75461ffc27
Preparation for Ic645cea671aa4798804666b8886f11bab5351e11 to allow arbitrary
timeslot configurations in the tests.
Change-Id: I8ed468da53f7b0e5ba8125d1bebafebe8c5becbb
Preparation for Ic645cea671aa4798804666b8886f11bab5351e11 to allow arbitrary
timeslot configurations in the tests.
Change-Id: I6eb11e9f98c827cfcd819990db38b6848bf18b27
The function bssmap_handle_cipher_mode() suggests to check if an lchan
is actually present when it gets called, but it only checks for conn.
This might lead to a segfault later in the execution path.
Change-Id: I3103ec89cd6dce1a11ea8e9f8187373e4114e852
The python scripts already use #!/usr/bin/env python3 so it was pure
coincidence that the tests are working.
Change-Id: Id5745d5ff5ff1072ccfbf9ad50b2d67f3ea95583
osmo-bsc is pretty useless without osmo-mgw these days. Let's not
make it a strong dependency, as the mgw could of course be running
on different machines.
Change-Id: I17711c6abdab0fc2d5d3afe1976d4248fd010e83
Event NM_EV_OML_DOWN in allstate will transition to Disabled
NotInstalled state. In the case where that is the current state, there's
really no change but we didn't allow the transition. Let's allow it
since it doesn't hurt and get rid of error messages when a BTS
disconnects.
Fixes: OS#4831
Change-Id: Ia5b7c88ff89e68ec5086d24f6ee20a8b3b2d994d
A header file should only contain declarations, not entire definitions.
The fact that we have 'static const struct ...' definitions in a header
file means that very C file including this header file will get its own
private copy of the entire definition.
The header file should only include declarations, while the actual
non-static definitions should go to a *.c file. Let's fix this.
Also, take a chance to improve readability and apply more consistent
formatting (similar to 'struct hf_register_info[]' in Wireshark).
Change-Id: Ib5949879902acbe1edda577477d9d51a2cc425d1
Closes: OS#4816
This feature apparently assigned a fixed LAC and CI to a specific MSC, but
looking at the implementation was obviously not useful.
Keep the vty commands for legacy compat, now without effect besides logging an
error via vty_out().
Related: OS#4751
Change-Id: I6bee704e7e5d5b6b86473323bae1fa9fce9241ee
Older osmo-bts versions (before FSMs) tended to mimic broken behavior
from nanoBTS. As so, we detect it because SiteMGr becomes Enabled by
default as in nanoBTS, and hence we can manage them also by expecting no
Offline state and sending Opstart (and hence finally transitting to
Enabled) during Dependency state.
Change-Id: Iaa036a2936f609b9b9721b2b4ad8d6deaf023f42
Before they were set with a value of 0, which had no related enum field,
but since in general all comparsions are done against NM_STATE_UNLOCKED
they also hold valid.
The major change in behavior with this patch is upon OML link down,
where gsm_bts_mo_reset() is called on all objects. This way, upon OML
re-establishment we have again all objects as Locked again, which is the
expected default value as per TS 12.21.
Change-Id: I68ae0bc51a565f903b47cf72f3e3dd6f1a2d2651
This bit of code was borrowed from MSC handling, where multiple MSC might tap
on the same SCCP user. There is only one remote SMLC, so there is no need to
osmo_sccp_user_find(), just bind it and be done.
Change-Id: Ia05c27c13dfb9df4f89c87b8477eea4e62fbe349
Previous commits to generalize the a_reset FSM prepare for this commit: use the
same reset FSM for the Lb interface.
Change-Id: I8c03716648f8c69d12d8f0a0bcec14f040d7cff2
To not modify previous SCCP behavior of OsmoBSC, keep the Lb interface disabled
by default. The following configuration enables the Lb interface:
smlc
enable
Change-Id: I01314a29a2cad6f325d9f4687a9dedca6b90a3ce
We don't really expect connection attempts during ST_DISC, but if the user
happens to dispatch those events for whatever obscure reasons, treat them
instead of erroring about an unallowed event.
Change-Id: Ic7c60a40ff25ae647ee659259dfea769bc4592e4
It is not particularly interesting to see a periodic "Sending RESET" to an
unconnected MSC in the logs. De-escalate to LOGL_INFO to make it easier to
configure away these logs.
Sending a RESET ACK is much more interesting, because it indicates that a
connection has been established.
Note that additionally, there will be a log on DMSC LOGL_NOTICE whenever a link
goes up or down, so the RESET logging does not add much crucial information for
operation maintenance, see a_reset_link_up() / a_reset_link_lost().
Change-Id: I86d67d19e20135c4944613c8e99580ef0e22ea8d
So far we would cancel ongoing Paging for a given MSC only after receiving a
RESET message from that BSC. However, the typical operation would be that
OsmoBSC *sends* a RESET and receives a RESET-ACK.
Instead, move the call to within osmo_bsc_sigtran_reset(). This is also called
when OsmoBSC considers the A-interface link to be lost, from the a_reset.c
code, after multiple SCCP connection failures.
Change-Id: Ia14b916be56563d18632c69a833084e71799a468
Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that
it can be re-used on the Lb interface.
Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we
have generally established in our osmo_fsm implementations.
Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c.
A difficulty is setting a proper logging category: the FSM definition allows
only one fixed logging category for FSM state transitions and events. Ideally,
the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log
on DLCS. Since that is not possible, introduce a separate DRESET logging
category. This in fact matches an item on my wishlist, because if a given MSC
is configured but currently not connected, the previous RESET FSM would
continuously "spam" log LOGL_NOTICE messages indicating that it is resending
RESET, and I often want to silence those messages without silencing the entire
DMSC category. This is now easily possible by setting DRESET logging to
LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all
interesting info is still visible on DMSC.
Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
If an A-interface conn is already active (for Location Services), an RSL EST
IND may arrive during GSCON_ST_ACTIVE. Pass it on instead of rejecting. This
allows establishing Layer 3 on an already active A-interface conn.
Change-Id: Ib18a12f8b8bcfb356188b2c0d97d555c1850f23e
The function parse_powercap() contains a nested switch case statement
that is used to populate the variables lu and pwr_lev. Those variables
are used at the bottom of the function later. Unfortunately the (outer)
switch case that consumes the pdisc variable does not put a break; at
the end of its only case "GSM48_PDISC_MM", which eventually causes a
fall through to the default case, which simply returns. Since this can
not be intended, lets add a break to make the bottom code reachable in
case lu and pwr_lev are successfully populated.
Change-Id: I48331cca784d8fa3a5904f2c4cf1555622b319e8
Fixes: CID#214886
When adding the Lb interface, it is necessary to determine an unused conn id
across *all* SCCP users. Prepare adding Lb by moving conn id creation out of
the gscon code and generalizing.
Change-Id: I12fcb18f6e4380f72929cfe7681bac05330a8c9a
Data Link Connection Identifier (DLCI) is defined in 3GPP TS 48.006,
section 9.3.2, and coded as follows:
.... .SSS - SAPI value used on the radio link;
CC.. .... - control channel identification:
00.. .... - indicates that the control channel is not further specified,
10.. .... - represents the FACCH or the SDCCH,
11.. .... - represents the SACCH,
other values are reserved.
RSL Link Identifier is defined in 3GPP TS 3GPP TS 48.058,
section 9.3.2, and coded as follows:
.... .SSS - SAPI value used on the radio link;
...P P... - priority for SAPI0 messages;
CC.. .... - control channel identification:
00.. .... - main signalling channel (FACCH or SDCCH),
01.. .... - SACCH,
other values are reserved.
As can be seen, CC bits in both DLCI and RSL Link Identifier
are coded differently. Therefore, we cannot just assign
one identifier to another, we need to do conversion.
I noticed that osmo-bsc indicates DLCI '01000011'B for SMS
messages sent over SACCH/F (SAPI3), and this is wrong because
'01'B is reserved. Let's fix this.
P.S. Interesting coincidence: section 9.3.2 in both documents.
Change-Id: If4d479a54cad467f53b49065c1c435a4471ac7d2
Related: Ica69ae95b47a67ba99ba9cc36629b6bd210d11e4
Related: OS#3716
Location Services brings a new scenario to OsmoBSC: the MSC may create an
A-interface conn for a subscriber without an lchan being established (N-CONNECT
from MSC to BSC, so far only for an incoming inter-BSC handover).
If an MS becomes active while an A-interface conn is already established,
associate with an existing conn.
Change-Id: I42290f519a419ed7e8dd02a5ed0a5261b30a51e6
The N-CONNECT.req on the A interface is a possible *consequence* of the event
being handled, namely the incoming RSL ESTablish INDication containing the
Complete Layer 3 message: dispatched by bsc_compl_l3().
If an (LCS related) connection is already present on the A-interface when the
lchan is established, there will be no N-CONNECT but an N-DATA sending the
Complete Layer 3. See BSC_Tests.TC_cm_service_during_lcs_loc_req().
Change-Id: Ic43aabeb0d3c58ac62249ad9d3718363d32508f9
During LCS development, I'm getting use count bugs and would like to see use
token strings to figure it out.
Change-Id: I29bf60059d4cf7bb99a00753e6cdc149baf95f94
To distinguish between the CN requiring a Complete Layer 3 response, or just
the BSC requiring a TA, allow recording a separate for-LCS paging reason.
Change-Id: Ib28d1599ae4e483727398859d07de4490fbc31f0
Allow starting a paging from elsewhere than a BSSMAP Paging Request. For
upcoming Location Services (LCS), a BSSLAP TA Request from the SMLC may require
triggering a Paging.
Change-Id: Iaff91584699d163bd1963927280ff3a8ddd43073
For LCS, I would like to add an enum indicating the paging reason. Instead of
modifying extremely many function signatures to pass the reason across all
levels of paging, introduce a struct combining these.
Change-Id: I27ca78fc6ff8ef1101554c0a8429e34945ca6f3c
I lost count of how many times the gsm48_hdr got parsed from the msg in the
same compl l3 code path. Here is one less.
Change-Id: I9f15b3e5e7352ef90b4598dadf2ebc0d2665f069
Instead of iterating the llist of gsm_paging_requests first to find an MSC, and
then again right away to mark the paging as served, do both in the same step.
Change-Id: I447e61afc9934f3a5a82f6076e41c155d3328041
Set conn->bsub as indicated by the Mobile Identity. Now the
'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);' becomes useful.
Upcoming patch to support Perform Location Request will use the subscriber to
retrieve an already established conn via the bsub.
Drop fixme in gscon_fsm_init(), MI now extracted and id updated.
Change-Id: I00d4c7e8284b745368a432a7ec176aa99f79db47
Move conn allocation to bsc_compl_l3(), from gsm0408_rcvmsg().
Drop dispatch of GSCON_EV_A_DISC_IND, because a) we did not receive such
DISC.IND, and b) the lchan release will discard the conn in the regular
fashion.
In upcoming LCS patch, bsc_compl_l3() will decide whether to allocate a new
conn or whether a conn from a Perform Location Request already exists for the
subscriber.
In this patch, it becomes clear that the conn->bsub is always NULL in
bsc_compl_l3(), and that the 'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);'
never has the intended effect. An upcoming patch will change that.
Change-Id: I92af0f0d54c4282d782f2b29d524a64006c3b674
Move getting the CGI closer to where it is used.
Use a use_scl pointer to remove a bit of code dup.
Drop logging for tx Compl L3, there is plenty logging later in
osmo_bsc_sigtran_open_conn().
This cosmetically prepares future changes for LCS handling.
Change-Id: If7a7d0fe857797d569968e694bf20818d7472bcd
Move two calls of osmo_mobile_identity_decode_from_l3() from bsc_find_msc() and
handle_page_resp() out into a single call in bsc_compl_l3().
Prepares cosmetically for upcoming LCS patch.
Change-Id: I26950b63621417da0ed3125d0dc0b06cf015cb4a
bsc_scan_bts_msg() essentially updates the MS power class for LU and CM
Service, and also stops the paging and counts the response for a Paging
Response. Separate that.
Reduce code dup by one common parse_power_cap() function for both LU and CM
Service.
Call handle_page_resp() separately.
(Upcoming patches will add more reasons to read the gsm48_hdr's pdisc and mtype
in bsc_compl_l3().)
Change-Id: If14284494c74a396fabebd79da8079342e65dcc2
The missing return code isn't a problem atm because remote.af is checked
and remote.af is only set when osmo_Sockaddr_str_from_sockaddr() returns success.
However check the return code to be safe also in the future.
Found-by: Coverity
Fixes: CID#214863
Change-Id: I621360cab1e12c22248e33d62a9929995053ce04
Introduce a address_type in the NSVC configuration pass the given
protocol. The remote_ip is network byte order, the default
encoding for in_addr and in6_addr.
Related: Iae854875a45dbc29cd46a267ccaf60f1f2ac2973
Related: SYS#4915
Change-Id: I740be0a401612bb5ed4e8ccd7f4be8176b936449
According to TS 12.21, when adminsitratively Locking an object, in
general it should go into operative state Disabled. We don't really
implement it this way right now, but keep it this way consistent in all
objects.
Furthermore, TS 12.21. Figure 2 describes vaguely that unlock procedure
is done around same time where object attributes are set, which is
before OPSTART.
Change-Id: Icd4b3bb467f23c9ddfa56f6b6f8a55da1e574ab8
The protocol 9 was extended (compatible) with
* app info request
* suspend request (ETWS)
* rach indition (add fields ts / trx)
Only copy the relevant parts but no implementation.
Related: OS#4766, OS#4767, OS#4768
Change-Id: Ia81310326b093a8e473b6c69045304667b3b60f1
This is the only place where the entire dtap header is passed, where
the split between SAPI and CHAN is done. Other places in osmo-bsc pass
around a link_id integer containing everything, so leaving that out of
the scope for this patch.
The gsm0406_dlci_sapi_name() API was introduced in libosmocore 1.3.0,
and osmo-bsc currently requires libosmocore 1.4.0, so it means we are
not further restricting libosmocore dependency here by using it.
Change-Id: Ib72e2bda46e39d1075e4270ac5fa51df2f418164
During the A-bis/OML bootstrapping, osmo-bsc sends Opstart to the
Radio Carrier MO twice. The first Opstart is triggered by the
State Changed Event Report, originated by the Radio Carrier itself.
The second is triggered by Software Activated Report.
According to 3GPP TS 12.21, figure 2, we shall send it only once,
after the "Attribute setting" step. Therefore, the first Opstart
is premature, and we shall not send it.
Related: SYS#5063, OS#4755
Change-Id: If69393551117266ecb726d8961153560b2b3cc59
Backwards compatibly, introduce timer groups in OsmoBSC, and move some
non-specified T timers to new X timers:
T993111 -> X3111
T993210 -> X3210
T999 -> X4
Why X4? because there already is an X3 used elsewhere in Osmocom, and I find
it less confusing if X-numbers don't repeat across programs. See
https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers
Drop unused timers from g_mgw_tdefs. Only X2427 has an actual effect.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
Put libosmo-mgcp-client related timers to the 'mgw' group, like in osmo-msc.
This makes the MGCP timeout configurable for the first time.
Keep previous timer commands as DEFUN_HIDDEN, and also translate the moved T
timers to X timers on-the-fly. All previous VTY commands still work, and new
'timer [(net|mgw)] ...' commands are added. timer.vty shows this.
Remove the "_OPTIONAL" from the legacy "timer" and "show timer" commands, so
that they don't ambiguously overload the new "timer [(net|mgw)] ..." commands.
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I4beec47502afa193dee343869c4be55dc6a4b536
The manual channel activation work in a very hackish way by sending the
CHANNAL ACTIVATION message manually using rsl_tx_chan_activ(). This
means the channel activation is not under FSM control. Also switchover
of dynamic channels does not work.
The lchan_fsm supports an activ_for in its activation info struct. The
header files define a "FOR_VTY" enum value there. However, the lchan_fsm
is not yet prepared to handle this. Lets update the lchan_fsm so that
FOR_VTY is supported and change bsc_vty to use lchan_activate() instead
of calling rsl_tx_chan_activ() directly. This will give us real channel
activation under FSM control.
Change-Id: Iffc57b7a5b7bdde06d392267791fd908e80bbb5d
Related: SYS#4910
Instead of maintaining two variables and re-calculating the bit
position on each iteration, let's use the existing field of the
bit-vector: set it to the first LSB and decrement in the loop.
Change-Id: I1b226a2d5867434c33ae04a0b971dbfd16c4688f
Related: SYS#4868, OS#4545
Before transitioning some unspecified T timers to X timers, and to introduce
timer groups, first add this timer VTY test. Changes here will illustrate that
the legacy commands will still work and redirect to new timer definitions.
Related: OS#4539
Change-Id: Ie1bc635e16dc9a4040d063e1d9a51cdc76d9d1f2
It does not make sense to set the bsc_subscr's LAC from a Paging Request,
especially since the paging code has loops that possibly kick off several
pagings.
At this point, there remains no code setting bsub->lac anywhere. We could set
it during rx of Complete Layer 3, but since there is no use for it besides a
vty dump, let's just drop the bsub->lac completely, and the vty dump of it.
Change-Id: Id017bd494d329b6fc254d7135b4074ac2b224d66
RF-locking: simply ask bsc_grace_allow_new_connection() at the start of
page_subscriber(). Before this patch, we would log an INFO of "Paging request
failed" when RF-locked, for each BTS. Instead log "RF-locked". (An upcoming
patch will introduce a LOG_PAGING() macro that will trivially add more log
context there, so not bothering now.)
Drop LAC condition: since Stefan introduced page_subscriber() starting 2018
Ic3c62ff0fccea586794ea4b3c275a0685cc9326e, matching a requested LAC to a
specific BTS is done *before* calling page_subscriber().
BTW: the msc->core_lac (config 'core-location-area-code') has not had an effect
on Paging maybe ever. I opened OS#4751.
Change-Id: Ic8696414a1db8f4b1be502d6434599f684746ed6
When the measurement bandwidth was added the calculation of the maximum
length wasn't increased.
Fixes: 27a887f666 ("gsm 04.08: encode the LTE neighbors measurement bandwindth in Channel Release")
Change-Id: Ic8132fd988140c34b8e0fd8349f4518fcbaecc31
The VTY already has a method available to activate lchans manually,
however, this method does not support proper activation of signalling
channels. Also additional commands to activate multiple lchans at once
are helpful to make labtesting simpler and more efficient.
Change-Id: I66b874736c8c456eb82ccc26d5209987d8ed706c
Related: SYS#4910
The function reduce_rach_dos() only removes the tossed channel requests
from the list, but does not free them.
Change-Id: I0a62fc897c07e118dd637b156b6f2822c44db731
Related: OS#4549
At the moment expired channel requests are dropped silently, however, it
might help to know when this happens - not only for debugging.
Change-Id: Ib49df551a4cd7d5652e85c8ce29ef132385d4ae4
Related: OS#4549
Encoding missing measurement bandwidth of LTE neighbors in Channel Release
(Cell selection indicator after release of all TCH and SDCCH value part).
The measurement bandwidth was encoded in the neighbors description transmitted in
SI2quater while missing in the Channel Release which would overwrite the
SI2quater measurement bandwidth.
Change-Id: I4847d840ba9d5ac56bd00e4f405dc47792008c0d
The spare bits were never encoded even when the spec says it must be 00.
Most caller of _chan_desc_fill_tail() initialized the struct with memset(),
but not all.
The SI4 did not initialize it.
Change-Id: Ib03d6d2cdadc49e49aa94917d17f81ef3c83f11c
Ensure that osmo-bsc would not continue to work as usual, if for
some reason we cannot encode or send System Information messages.
Introduce transitional state OM2K_TRX_S_SEND_SI, from where we
can generate and send System Information messages. Otherwise
it's confusing if we fail to do something when we're already
in state OM2K_TRX_S_DONE.
Change-Id: Ia6df539d0914c57ea80fdb29882832678b47f267
This is needed to be able to force MGW to provide an IPv4 address during
MDCX, since IPACC protocol on the BTS side only supports IPv4, but one
may need IPv6 side at the same time on the core side.
By moving the IPACC MDCX request to a later step, the BSC gains
knowledge of the local address on each side (BTS, MGW), and if they
don't match (ie. BTS uses IPv4 and MGW uses IPv6), it can then get MGW
to offer an IPv4 address during MGCP MDCX containing the BTS IPv4
address. At that point, the MGW can see the mismatch and provide an IPv4
address in the MGCP MDCX ACK, which can then finally be communicated to
the BTS during IPACC MDCX phase.
Previous order:
BSC -> MGW: CRCX
BSC <- MGW: CRCX ACK (get MGW local IP addr)
BSC -> BTS: IPACC CRCX
BSC <- BTS: IPACC CRCX ACK (get BTS local IP addr)
BSC -> BTS: IPACC MDCX (set MGW IP addr)
BSC <- BTS: IPACC MDCX ACK
BSC -> MGW: MDCX (set BTS IP addr)
BSC <- MGW: MDCX ACK
New order:
BSC -> MGW: CRCX
BSC <- MGW: CRCX ACK (get MGCP local IPv6 addr)
BSC -> BTS: IPACC CRCX
BSC <- BTS: IPACC CRCX ACK (get BTS local IPv4 addr)
BSC -> MGW: MDCX (set BTS IPv4 addr)
BSC <- MGW: MDCX ACK (here MGW changes its local addr to IPv4)
BSC -> BTS: IPACC MDCX (set MGW IPv4 addr)
BSC <- BTS: IPACC MDCX ACK
Change-Id: I4de5ea5c94c1482c9cb0b6386997a942edc60e32
Ensure that osmo-bsc would not continue to work as usual, if for
some reason we cannot encode or send System Information messages.
Change-Id: I7d3458fb10760e33411f2074a6b2df1c257438d5
Make sure that in generate_si4() we do not corrupt other SI buffers
by limiting maximum length of the Mobile Allocation to 2 octets.
This would preserve at least 2 octets for the Rest Octets, what
should be enough to encode at least GPRS Indicator.
Change-Id: I2e3553865096faecda6bb22fc25b83fd47b738c4
Related: SYS#4868, OS#4545
If for instance "mgw remote-ip ::1" is configured, the MGCP IPA proxy
socket towards the MGW will use ::1 as the destination address, but it
was being created as AF_INET. Let's use AF_UNSPEC instead and let
osmo_sock_init2 decide the best socket type to create.
Moreover, change the default local address from "0.0.0.0" to NULL to
also let osmo_sock_init2 pick an IPv6 address if necessary.
Change-Id: Ide88c7358a38702ef11c84145518794e75870ef8
when an emergency call arrives while all TCH are busy, the BSC should
pick an arbitrary (preferably the longest lasting) call / lchan and
release it in favor of the incoming emergancy call.
The release of the existing call is a process that can not be done
synchronously while the ChanRQD is handled sonce multiple messages are
exchanged between BTS and MSC and multiple FSMs need to do their work.
To be able to release one lchan while handling a ChanRQD a queue is
implemented in which the incomming channel requests are collected. If
an emergency call is established while all channels are busy, an
arbitrary lchan is picked and freed. When freeing the lchan is done,
the queue is checked again and the emergency call is put on the free
lchan (TCH/H or TCH/F).
Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36
Related: OS#4549
According to 3GPP TS 44.018, table 10.5.2.21.1 "Mobile Allocation
information element", in the cell allocation frequency list the
absolute RF channel numbers are placed in increasing order, except
that ARFCN 0, if included in the set, is put in the last position.
This basically means that the last bit of the Mobile Allocation
(MSB on the wire) corresponds to ARFCN 0, if it's included in
the cell allocation frequency list, or the last channel otherwise.
Recently introduced TTCN-3 test cases uncover the following problems:
a) ARFCN 0 is encoded twice: as MSB and LSB of the bit-mask,
b) ARFCN 0 is encoded one bit off its expected location.
Change-Id: I264a66a1405e72940a79e9e20ad6ad8f269a7bbc
Related: SYS#4868, OS#4545
osmo-nitb supports the modification of an lchan if the lchan is
compatible but in the wrong mode. This feature was dropped in the
transition to AoIP/bsc-split. However, osmo-bsc still has code to
generate and parse the messeages, but the FSMs do not support a mode
modify yetm
Lets add handling for mode-modify to the lchan_fsm and assignment_fsm in
order to support mode modify again
Change-Id: I2c5a283b1ee33745cc1fcfcc09a0f9382224e2eb
Related: OS#4549
In commit [1], I replaced the way the CBSP link is configured in the VTY. But
that configuration was already part of a release, hence I should only have
deprecated the old commands. Re-add the legacy config as deprecated.
Try to make the legacy commands take a similar effect as they previously would
be intended for, i.e. switching to server/client/disabled modes, and take
effect immediately when commands are read from telnet.
[1] 641f7f0845
Icaa2775cc20a99227dabe38a775ff808b374cf98
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"
Related: OS#4702
Change-Id: If6b742f28191b3f19ff1d87a217037a305133f4b
According to 3GPP TS 44.018, section 9.1.36.2, the CBCH Mobile
Allocation IE shall be present if CBCH Channel Description IE
indicates frequency hopping. For some reason it was missing.
This change makes BSC_Tests.TC_fh_params_si4_cbch pass.
Change-Id: I8dce506a07d9d291b631b44fa2177c9deff6aa88
Related: SYS#4868, OS#4545
A similar problem has already been fixed in [1]:
- include GSM48_IE_MA_AFTER instead of GSM48_IE_MA_BEFORE,
- fix position of the Mobile Allocation (after time) IE.
This problem was uncovered by (not yet merged) TTCN-3 test case
verifying handling of the hopping parameters [2]. This change
makes it pass.
[1] I43ef66c109b107ebcaa1cb6197637701b13b3787
[2] BSC_Tests.TC_fh_params_handover_cmd
Change-Id: I7569eead9760b6fd4bb91fc2d8d0b8200bebe374
Related: SYS#4868, OS#4545
IPACC protocol supports only IPv4 addresses, so make sure if an IPv6
address (or whatever malformed address) is caught is not sent without
noticing. Prior to this patch, faulty addresses would be sent over the
wire as 255.255.255.255 (-1 returned from inet_addr()).
Change-Id: Iee84e8b40cdede1cacd8e8a9e26dda0d85383ec8
If the feature is not enabled there's no real use in displaying default
values for it.
Related: SYS#4912
Change-Id: I759eb0c31dd3c9b6f5f3d2bf57c6efc9ac5f74f1
Restart the CBSP link from the VTY only from telnet sessions, not when reading
in the config file. When reading the config file, link startup might happen too
early and twice -- rather rely only on the CBSP startup invoked from main().
This is fixing a bug introduced recently in
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"
commit 641f7f0845
Change-Id Icaa2775cc20a99227dabe38a775ff808b374cf98
Change-Id: Ia0bb507c8468048789a446df09185ad8565c5ad8
Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the
test passes for the wrong reason. The ambiguous cell identification should be
the cause for the handover error, but the log shows that instead a handover is
attempted to BTS 3 which is not connected.
find_handover_target_cell() first tries to find a precise match of values, and
in a second pass applies wildcards like BSIC_ANY and
NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous
matches.
Use the same code for both passes, by encapsulating in a loop of two, which
first runs with exact_match == true and then false.
Proper detection of the ambiguous target cell identification in
TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count,
see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks).
Related: OS#4736
Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks)
Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
An inter-BSC-OUT handover ends with a Clear Command, which HO_OUT_ST_WAIT_CLEAR
waits for. Actually tell the handover_fsm.c about an incoming Clear Command, so
that the inter-BSC-OUT success can be counted.
Similarly, count failing handover results for an unexpected Clear Command from
the MSC.
Related: OS#4736
Change-Id: I0c489838a99f930e2104619ca745191d2a736f1b
During handover cleanup due to a Clear Command from the MSC, do not send
another Clear Request to the MSC. Only send that when no Clear Command was
received yet.
Add a flag rx_clear_command per gscon instance, indicating whether a Clear
Command was received, and exit early in gscon_bssmap_clear() when true.
This is part of patches fixing the rate counters around handover, which uncover
some bugs:
- Another patch enables proper handover result handling when receiving a Clear
Command.
- After that, the handover_end() handling would always cause sending a Clear
Request, even if a Clear Command was already received.
- This patch removes the extraneous Clear Request, for this scenario and for
all other corner cases that might still exist.
Related: OS#4736
Change-Id: Iab82cac0a7ffa7d36338c8ff7c0618a813025f13
So far, during inter-BSC outgoing handover, when receiving an RR Handover
Failure from the MS, it would be counted as 'error'. Instead, add the 'failed'
counter like for all other HO types.
It may make sense to omit the 'failed' counter for inter-BSC *incoming*
handover, because then we won't receive an RR Handover Failure message. I
probably got those two mixed up during initial development.
Related: OS#4736
Change-Id: I9a61d5cc7273a830ba4e66e43e4aac6cdb707471
To handle cases of unknown handover type (like failure to find the target
cell), return -1 as counter code; treat -1 as skipping in ho_count_bsc() and
ho_count_bts().
The handover:* counters indicate overall counts, without knowing whether inter-
or intra-BSC, or whether the target ARFCN even exists. So they need to be
counted separately, and must not serve as fallback category in
result_counter_bsc() and result_counter_bts().
Related: OS#4736
Change-Id: Ie311e599d7bd35d33cf471c6c63e649246e8396a
Move initial 'handover:attempted' counts from bsc_subscr_conn_fsm.c to
handover_fsm.c, where all the other counters are handled.
Add missing increments for the overall 'handover:*' counts.
Related: OS#4736
Change-Id: I783bdedafc0eb8f2df9ea100792846fecc7ccbf7
Currently osmo-bsc encodes the IAR Rest Octets as follows:
IAR Rest Octets
0... .... = Extended RA: Not Present
.0.. .... = Extended RA: Not Present
..1. .... = Extended RA: Present
...0 1011 = Extended_RA: 11
0... .... = Extended RA: Not Present
.L.. .... = Additions in Rel-13: Not Present
Padding Bits: default padding
This is not really critical, but still may look confusing as this
is only relevant for the PS domain (11-bit RA), while osmo-bsc is
responding to a CHANNEL REQUEST in the CS domain.
Change-Id: I30a43efc70345a4bb0571127c239a24422b7fd2c
Firstly, make CBSP server and client mutually exclusive: Do not allow osmo-bsc
to be configured as CBC client *and* CBC server at the same time.
cbsp_link.c expects at most one CBSP link to be established, and, upon sending
CBSP messages, probes whether to send the message to a CBSP server or client
link. When both listen-port and remote-ip are configured (regardless of an
actual CBSP connection), osmo-bsc gets confused about where to send CBSP
messages.
One solution would be more accurate probing for an actual established TCP
connection. But the simpler and less confusing solution is to force the user to
configure only server or only client mode, never both.
Introduce 'cbc' / 'mode (server|client|disabled)'.
Secondly, clarify the 'cbc' config structure into distinct 'server' and
'client' subnodes. Refactor the 'cbc' VTY node in such a way that the IP
addresses for server and client mode can remain configured when the CBSP link
is switched between server/client/disabled modes.
To implement the above, switch the struct bsc_cbc_link to use osmo_sockaddr_str
for address configuration.
Related: OS#4702
Related: I7eea0dd39de50ed80af79e0f10c836b8685d8644 (osmo-ttcn3-hacks)
Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground)
Change-Id: Icaa2775cc20a99227dabe38a775ff808b374cf98
As 3GPP TS 48.058 clearly states, an RLL RELease INDication is only
sent if the datalink is released by the MS. Thre's no cause value
giving further diagnostics, but if the MS releases the link, it is
clearly not the BSS's fault, and hence "BSS not equipped" is wrong.
Change-Id: I38222e60071841abcd06046a472ddb35907164a4
Related: OS#4728
The tx TRAP callback is triggered through a signal which is never sent in
osmo-bsc code, and never was as far as I can tell going quite far in the
logs.
In the meanwhile, the msc_connection_status was left in favour of
multi-msc msc.X.connection_status CTRL variable, so let's prepre the cb
function to work for that onei too, dropping global variables which may lead
to wrong output in multi-msc environments, and simply use msc->nr==0 for
the old variable "msc_connection_status".
The signal is now triggered in a_reset when the A conn becomes connected
or disconnected. As a result, a user waiting for the disconnect event
may notice that the status may be changed with a noticeable delay, since
the A conn may be reset only due to high layer timeouts after several
repeated failures (T4, BAD_CONNECTION_THRESOLD).
Related: OS#2623
Related: OS#4701
Related: SYS#5046
Change-Id: I645d198e8e1acd0aba09d05cb3ae90443946acf8
"127.0.0.1" is changed to "localhost" to let local NSS decide whether to
use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since
IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail. In any case, since
the default remote address is a local one and it's the client side,
there's no real logical change since the kernel would anyway should have
taken a local address anyway.
Change-Id: Ic93be6c47403e65b7c338604728570f23bc3de12
Normally, each ETWS CMD instructing to broadcast triggers a five second
etws_timer to send a zero-payload ETWS CMD that stops broadcasting, five
seconds later. Before this patch, this lingered past an ETWS RESET instruction.
Instead, clear the etws_timer on ETWS RESET, and make sure that all ETWS PN
broadcast is stopped by sending a zero payload ETWS CMD to the BTSes
immediately.
This will cause all CBSP ttcn3 tests to fail unless
Ifee313369a433a6a638c5fffdedee5363b8e47c2 is merged to osmo-ttcn3-hacks at the
same time.
Related: Ifee313369a433a6a638c5fffdedee5363b8e47c2 (osmo-ttcn3-hacks)
Change-Id: I925a041936c6163483d70fe6d158af368ec8c444
The functions lchan_fsm_allstate_action, lchan_fsm_allstate_action and
lchan_fsm_cleanup are only used internally in lchan_fsm.c, lets make
them static
Change-Id: If1ceb69d14a7840e1f753b0dd911726257125e99
There are some preperations and checks done before calling
lchan_mr_config(), those checks could also be done from inside
lchan_mr_config(), so lets merge them into lchan_mr_config()
Change-Id: I068aadda53b2c3a85ed4fb1e513b17bf9870bd50
In some (error-) cases we might be unable to determine which BTS to use
when counting handover events. We don't want to loose these events
because then ctr(bsc) == sum(ctr(bsc->bts)) would not be true anymore.
Those events are now counted by a counter in struct gsm_network which
uses an index that is out of range for regular BTS (65536).
Change-Id: Ic0f3edd5dc014c4eac5e8423133633a3e5d4c13e
Related: SYS#4877
Currently the counters don't distinguish between intra-cell and
intra-bsc handover.
Add _CTR_INTRA_CELL_HO_ and _CTR_INTRA_BSC_HO_ counters to track
intra-cell/bsc handover separately.
Change-Id: I3a1195640b99813036c9f1426ee5f07548e26547
Related: SYS#4877
Our current handover counters only count success/failures per BSC. It
would be nice to also count which BTS is part of a (successful/failed)
handover.
This patch duplicates the BSC counters for the BTS and changes the
ho_count and related macros to also count per BTS. If a BTS is NULL
(when conn->lchan is NULL) counting for the BTS is ignored.
Change-Id: I025ef14e2cfd2eea8880212c9406372ce0bf9296
Related: SYS#4877
by reading the code, I notice that a refcount on the subscr would be leaked if
there were no bts. That is not realistically happening, but nevertheless rather
rejigger so that no leak is possible, ever.
Change-Id: I0b804b8136cd78a777ca02667f696cdefa90c4a9
The MSC may at any time send a BSSMAP CommonID message via a
SCCP connection to inform us of the IMSI of the subscriber. Let's
make use of that information by associating a related bsc_subscr
and updating the identity of the bsc_subscr_conn_fsm for improved
logging / filtering.
Closes: OS#2969
Change-Id: I52c43fb940f0db796adf4c0adb2260321c721c39
Since we verify the cause code of the RSL channel release in ttcn3-bsc-tests,
BSC_Tests.TC_chan_act_ack_est_ind_noreply shows an invalid release cause code
of 127. Fix that.
On gscon timeout, don't send the unrelated RSL code RSL_ERR_INTERWORKING, but a
proper RR cause code. GSM48_RR_CAUSE_ABNORMAL_TIMER is defined as the proper
cause for an expired timer (3GPP TS 44.018 10.5.2.31).
Should fix this error in BSC_Tests.TC_chan_act_ack_est_ind_noreply:
BSC_Tests.ttcn:1590 Dynamic test case error: Assigning invalid numeric value 127 to a variable of enumerated type @GSM_RR_Types.RR_Cause.
Change-Id: Ic2e4b692e78f7b134fe57d1077a08adb48398e06
If a CHAN RQD indicates an emergency call on a BTS that does not allow
emergency calls, then respond with an IMMEDIAGE ASSIGNMENT REJECT
message to deny the emergency call early.
Related: OS#4548
Change-Id: I148c540269bffd703f38233a1e689e863c175e97
Before this patch FSM instances of configured but not connected BTS's
look like this:
FSM Instance Name: 'timeslot[0x612000004a20]', ID: '(null)'
Log-Level: 'DEBUG', State: 'NOT_INITIALIZED'
Now they look like this:
FSM Instance Name: 'timeslot(0-0-7-NONE)[0x612000004a20]', ID: '0-0-7-NONE'
Log-Level: 'DEBUG', State: 'NOT_INITIALIZED'
which makes it possible to attribute them to where they belong.
Otherwise, they look like lingering or leaking unattributed FSM
instances.
Change-Id: Idc74ea142b96323b48826f8a52e13e45d535512a
I beleive MSC split is finished a long time ago and everything is
already re-wired for the A-interface.
Change-Id: If2a0b15e360c44abc92fdeb9004be7ccc0537cdd
If the BSC configuration is set up to deny emergency calls, make sure
that an EMERGENCY SETUP will not be passed to the MSC, instead ensure
that the call is released.
Change-Id: Ia6eb38370ce4165d221d2ffbe1cd105c0628313c
Related: OS#4548
The MGCP endpoint name, that is generated when an E1 endpoint is
selected does have a hardcoded trunk id number, which is permanantly set
to 1. Lets use the E1 line number instead.
Related: OS#2547
Change-Id: Ic5447bb4426e31d119667bdfddfd2c91fd591fc6
The hard-coded per-BTS feature vector for osmo-bts currently lacks
BTS_FEAT_HOPPING, and this is unlikely to change, because only the
recent osmo-bts-trx does support freq. hopping, while the other
(DSP based) back-ends do not seem to be capable of doing it.
Let's allow enabling freq. hopping regardless of the feature vector,
so either it would work if it's supported, or the BTS would reject
Set Channel Attributes message by sending NACK on the A-bis/OML.
Change-Id: Iff23109cacb5d314f7bcbf34b25e89af9281ce40
Related: SYS#4868, OS#4546
Instead of logging a hex value for the met requirements, fully expand the "ABC"
flags for both TCH/F and TCH/H.
From HO_CANDIDATE_FMT/_ARGS, split off into REQUIREMENTS_FMT/_ARGS and use that
when logging the chosen HO candidates.
Also change the RX level to dBm, to match general logging and reduce confusion
between rxlev number variants in the log.
Change-Id: I1b30a6e98bdb4bd92e72864fafdd2f4f3ae3134c
When check_requirements() returns zero, do not keep such an entry in the
candidates list at all. This removes logging confusion, where some "candidates"
are still listed even though not meeting any handover requirements.
Change-Id: I12e48292d5731cb601165c870b9570003bc488ec
When the BTS is is not an ipaccess BTS, the BTS can only be an E1 bts.
In that case E1 endpoints must be used and there will be no RTP stream
setup towards the BTS.
Change-Id: I4f1f39bf90b0a7c9ea448dab255daf99cd36bb4a
Related: OS#2547
The functions lchan_rtp_fsm_timer_cb() and lchan_rtp_fsm_cleanup() only
used in lchan_rtp_fsm.c, lets make them static.
Change-Id: I31940aff166ccd7a9612574536674e4e483a3cb9
On a TS 12.21 spec compliant BTS, each Um traffic channel must be mapped
to an E1 sub-slot on the terrestrial back-haul. This happens via
the CONNECT TERRESTRIAL TRAFFIC message.
We always had code to sen that message, but it got deactivated when
ts->pchan_is / ts->pchan_from_config was introduced. Of course,
while we are bringing up OML, there is no 'pchan_is' set yet. We only
have 'pchan_from_config' and must use it.
Change-Id: I8988a027b0e897bd9dda460590f974d6be34a4fa
Prior to this patch, ACC ramping was only used to go 0->N in the
number of allowed ACCs during BTS startup. It could optionally
dynamically stretch or extend the ramping time based on channel load.
With this patch, ACC ramping is kept alive during the entire time the
BTS is active, and subset of allowed ACCs can now be incresed or
decreased based on channel load. A new VTY command
"access-control-class-ramping-chan-load" is added to configure a lower
and an upper threshold. Channel load under the low threshold will
potentially trigger an increment of the subset size of allowed ACCs,
while a channel load over the upper threshold will potentially trigger
the opposite (a decrease in size).
The time between checks is kept fixed per VTY command (reusing old
"access-control-class-ramping-step-size"), but the "dynamic" option
is deprecated and ignored from now on since it provides nothing valuable
in the new implementation, because the size always dynamically changes
based on channel load (configured thresholds).
Related: SYS#4912
Change-Id: Id17f947c92cdfc0eb9541a9bf066338169caaeb5
[ 160s] acc.c: In function 'get_highest_allowed_acc':
[ 160s] acc.c:117:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 160s] for (int i = 9; i >= 0; i--) {
[ 160s] ^
[ 160s] acc.c:117:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
[ 160s] acc.c: In function 'get_lowest_allowed_acc':
[ 160s] acc.c:127:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 160s] for (int i = 0; i < 10; i++) {
[ 160s] ^
[ 160s] Makefile:617: recipe for target 'acc.o' failed
Change-Id: I03722854634b2d6d6f1abac7c7553762b5fc6890
The files have been used successfully in the past weeks to bring up a
variety of different combinations of Ericsson DUG20 + RUS.
Change-Id: I046f786d68f7cd3fd21693142bd1315bf40696f5
See updated documentation section in manuals/chapters/bts.adoc regarding
an explanation on how the system works.
Related: SYS#4911
Change-Id: I952c9eeae02809c7184078c655574ec817902e06
The RLL ERR IND is sent by the BTS in any number of casese that lead
to a disconnect of a radio link layer, for example due to bad RF
conditions. The lchan FSM currnently prints error messages about
this event not being permitted, leading to confusion among users.
Let's ignore this event, I don't think the lchan FSM should or could
be doing anything as a result. We could also simply remove that event,
but let's keep it in case we should need it in the future.
Change-Id: I07aad62d25566d6068a95797915bb97fc3c66328
With upcoming next commit, the file will contain far more code that
simply ramping, so rename it to be more generic.
Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
Those adoc files are only used by osmo-bsc.git and openbsc.git
(osmo-nitb), and the later is deprecated and no longer maintained, which
means new features are only added to BSC. Hence it makes no sense to
keep the doc shared between both.
Change-Id: I20aa60d2f4111d66e922f3e2a73a20352ec1f7e4
CentOS is happy with the spec file as-is, but OpenSuSE is more strict:
[ 62s] osmo-bsc-1.6.0.191.bd5b-lp152.1.1.x86_64.rpm: directories not owned by a package:
[ 62s] - /usr/share/doc/packages/osmo-bsc/examples/osmo-bsc/ericsson
[ 62s] - /usr/share/doc/packages/osmo-bsc/examples/osmo-bsc/nokia
[ 62s] - /usr/share/doc/packages/osmo-bsc/examples/osmo-bsc/siemens
Change-Id: I40ad5d38b968db847cf5f733f82163ecac1151e0
The function initializes the struct owned by a bts, so it makes sense to
have it done there instead of somewhere else later.
It was most probably put in bsc_vty when it was initially introduced
because of all the data structure and object file mess I untangled
during last set of patches.
Change-Id: I66c4b208583e92070793183b83b3a7b7edf6ba00
In the big mess of gsm_data we reached a point where we have multiple
functions doing the same thing, most probably because it's hard finding
stuff in there. Let's drop one of them (the one which less callers) and
move it to bts.*, where it belongs.
Change-Id: I9071a0ab250844619280fbe2be63ed99f2c87eb1
Place all code related to the object into the related file.
Having all the data model in one file made sense in early stage of
development to make progress quickly, but nowadays it hurts more than
helps, due to constantly growing size and more and more bits being
added to the model, gaining in complexity.
Currently, having lots of different objects mixed up in gsm_data.h is a hole
of despair, where nobody can make any sense were to properly put new stuff
in, ending up with functions related to same object in different files
or with wrong prefixes, declarations of non-existing functions, etc.
because people cannot make up their mind on strict relation to objects
in the data model.
Splitting them in files really helps finding code operating on a
specific object and helping with logically splitting in the future.
Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
In various places that receive an error cause from RSL and place it in
lchan.release.rsl_error_cause, translate it to an RR cause and place that in
the recently added lchan.release.rr_cause. Hence the RR Channel Release message
now reflects more specific error causes when the reason for the error was
received in an RSL message's cause value.
Change-Id: I46eb12c91a8c08162b43dd22c7ba825ef3bbc6ac
In lchan.release, add 'cause_rr', and set RR Channel Release message's cause
value to lchan.release.cause_rr.
In lchan_release(), do not set lchan.release.rsl_error_cause to the RR cause
value, these are unrelated. Store in new lchan.release.cause_rr instead. The
rsl_error_cause is apparently only used for logging, except for one place in
lchan_fsm_wait_activ_ack() that compares it to RSL_ERR_RCH_ALR_ACTV_ALLOC, so
there should not be a functional difference by this fix.
Propagate the BSSMAP Clear Command cause to the RR Channel Release:
Add struct gscon_clear_cmd_data as event data for GSCON_EV_A_CLEAR_CMD -- so
far it sent the is_csfb flag, add the gsm0808_cause; invoking the event happens
in bssmap_handle_clear_cmd().
Adjust event handling in gscon_fsm_allstate(); there, pass the cause to
gscon_release_lchans(). In gscon_release_lchans(), pass the cause to
gscon_release_lchan(), and then lchan_release(), which sets the new
lchan.release.cause_rr to the passed cause value.
As soon as the lchan FSM enters the proper state, it calls
gsm48_send_rr_release(). There, set the cause value in the encoded message to
lchan.release.cause_rr.
Interworking with osmo-msc: so far, osmo-msc fails to set the Clear Command
cause code for normal release, it just passes 0 which amounts to
GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE. Before this patch, osmo-bsc
always sent GSM48_RR_CAUSE_NORMAL in the RR Channel Release, and after this
patch it will receive 0 == GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE from
osmo-msc and more accurately translate that to GSM48_RR_CAUSE_PROT_ERROR_UNSPC.
This means in practice that we will now see an error cause in RR Channel
Release instead of GSM48_RR_CAUSE_NORMAL when working with osmo-msc. For
changing osmo-msc to send GSM0808_CAUSE_CALL_CONTROL instead (which translates
to GSM48_RR_CAUSE_NORMAL), see OS#4664 and change-id
I1347ed72ae7d7ea73a557b866e764819c5ef8c42 (osmo-msc).
A test for this is in Ie6c99f28b610a67f2d59ec00b3541940e882251b
(osmo-ttcn3-hacks).
Related: SYS#4872
Change-Id: I734cc55c501d61bbdadee81a223b26f9df57f959
3GPP 44.018 10.5.2.1e defines the EARFCNs encoded in the 'Cell selection
indicator after release of all TCH and SDCCH IE' as follows:
<Cell Selection Indicator after release of all TCH and SDCCH value part> ::=
[...]
| 011 { 1 <E-UTRAN Description : < E-UTRAN Description struct >> } ** 0
So after a 3-bit discriminator of '3' there can be multiple E-UTRAN
Descriptions, and each of them starts with a '1' bit to indicate that another
item follows. Finally there is a '0' bit to indicate the list end.
Before this patch, osmo-bsc only encoded the first '1' bit, and failed to
repeat this before each following E-UTRAN Description. Fix that by moving the
'1' encoding into the loop.
The final '0' was missing. Add it.
With these changes, adjust the size calculation in
CELL_SEL_IND_AFTER_REL_MAX_BITS to match.
Also fix CELL_SEL_IND_AFTER_REL_MAX_BYTES by using OSMO_BYTES_FOR_BITS()
instead of the inaccurate (n/8)+1.
A test for this is in I882c5e1f70bcc4833fc837a95c900ce291919cc5
(osmo-ttcn3-hacks).
Related: SYS#4871 SYS#4872
Change-Id: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab
This adds osmo-bsc config files for Ericsson RBS2308, Siemens BS-11 and
Nokia InSite which were working in July 2020 to get the BTS initialized,
recognized by MS and up to signalling.
Voice/TRAU support is still missing in OsmoBSC, but should be added
relatively soon.
Change-Id: I1fe15cc3654025e52fc1110ac3052fb1f7a009a0
Depends: osmo-python-tests I896b99032d94ba0cdd340a8eed7c7b625661ad69
Closes: OS4651
This option has been deprecated back in 2018 [1], but for some
reason we still have it in the configuration examples, so it
prevents osmo-bsc to allocate TCH/F on dynamic timeslots.
[1] Ib2335d02ea545aff837aadd49f15b2fdb418c46e
Change-Id: Icc82f6178d18dccc7207485b25dc3bdad91a0052
Related: SYS#5014
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ia5a656567d212fa265aef1375d714d0c5fee5dd6
We don't want to fprintf directly, and we want to make sure to always
log as much context as possible.
Change-Id: I29ec935669175a08cb42e1666559b681c50a6e72
When we introduced the timeslot FSMs in
I82e3f918295daa83274a4cf803f046979f284366, the BS-11 stopped to work, as
the timeslot FSMs are never brought out of NOT_INITIALIZED stage.
Closes: OS#4666
Change-Id: I557cb105247552887ca47a0f2c1b06b71bca6cac
There are a number of OML messages which are not seen on IP based
BTSs. Those are perfectly normal and expected on E1 based BTS.
Change-Id: Icd87fc9f3652b21f9d569af2572d080c9ac89e8b
Closes: OS#4665
Up to 16 SI2quater are multiplexed; each fits 3 EARFCNS, so the practical
maximum is 48 (of course depending on how many bits are used by other SI2quater
elements).
Change-Id: Iabeed10053ee5899b4def3509aedd25abb2410a9
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25.
Removing only 25 bits from the budget resulted in malformed SI2quater starting
with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits.
These malformed SI2quater were also expected in gsm0408_test.c. Update the
expected SI2quater to what is being generated now. This patch passes the ttcn3
testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some
confidence that the coding expected in gsm0408_test.c is now correct.
Related: OS#4652
Change-Id: I5df269f713456a6ccbb874d6b7faac4a6f123c67
According to 3GPP TS 44.018, section 9.1.2.4, if at least one of
the Channel Description IEs indicates frequency hopping, one and
only one of the following IEs shall be present:
- Mobile Allocation, after time (see 10.5.2.21);
- Frequency List, after time (see 10.5.2.13).
For some reason, osmo-bsc includes the GSM48_IE_MA_BEFORE instead
of GSM48_IE_MA_AFTER - fix this.
According to section 9.1.2.6 of the same document, if any of the
Mobile Allocation IEs (before/after time) is present, then the
network must ensure that either the MS has already received the
the proper reference cell frequency list (CA), or that the Cell
Channel Description IE (see 10.5.2.1b) is present.
Without this IE, the phone I was using in my testing setup sends
RR Status message with cause #100 "conditional IE error".
Fortunately, we already have generate_cell_chan_list(), since we
also need to include the Cell Channel Description in SI Type 1.
Change-Id: I43ef66c109b107ebcaa1cb6197637701b13b3787
Related: SYS#4868, OS#4545, OS#4546
Refactor osmo_bsc_sigtran_init(): invoke osmo_sccp_simple_client_on_ss7_id()
exactly once per cs7 instance.
When introducing MSC pooling to the ttcn3-bsc-tests, it became apparent that
osmo-bsc rapidly huts down and re-creates the SCTP link for each configured
MSC. This manifested in an osmo-stp crash (fixed in libosmo-sccp
I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa). I first tried to fix it by only
restarting an ASP when it wasn't found in the AS yet, but that created obscure
problems described in OS#4635 which in turn completely broke ttcn3-msc-tests.
This solution keeps osmo_sccp_simple_client_on_ss7_id() unchanged and instead
invokes it exactly once per cs7 instance.
Keep the same auto-config logic, but change and improve the mechanisms to
achieve it:
Replace the fail_on_next_invalid_cfg flag with a more accurate check against
remote PC collisions between configured MSCs. Before this patch, the code made
sure that at most one MSC lacks an explicit remote address (and cs7 instance),
so that no two MSCs get the same default remote PC. This patch more accurately
checks that no two MSCs use the same remote PC on the same cs7 instance,
period, whether implicitly or explicitly configured.
Before this patch, the logic amounted to creating cs7 instance 0 implicitly,
but it was not very obvious: If an 'msc' has an msc-addr configured, it is
associated with the cs7 instance that has this addr in its address book. If it
has no msc-addr configured, then msc->a.cs7_instance_valid == false. In that
case, msc->a.cs7_instance is still 0 (from talloc_zero) and hence
osmo_sccp_simple_client_on_ss7_id(ss7_id = 0) created cs7 instance 0. In this
patch, that logic remains unchanged, but is written out more explicitly: if any
msc has no cs7 instance associated, make sure to create cs7 instance 0
beforehand.
Then iterate all osmo_ss7_instances. If at least one MSC uses it, set up the
SCCP client on it and connect all MSCs as appropriate.
Related: OS#4625 OS#4635
Change-Id: I16f4f7f447f69525a2f57c4649ab295112904d6a
The IPACC protocol is an extension to the conventional RSL protocol
to negotiate ip address and port for RTP/VoIP. This protocol is BTS
specific (sysmobts, ip-access nanobts) and not used with E1 BTSs
The bsc VTY is able to trigger certain IPACC functions for debug
purposes. Some of those commands do not check if the BTS is really of
type IP-access before trying to send an IPACC command. Let's add
checks to prevent IPACC messages to be sent to E1 or otherwise
incompatible BTSs models.
Change-Id: I9ee78b6b1d342abaccc09a87dee6af79e76e5468
Related: OS#2547
According to 3GPP TS 48.058 (version 15.0.0), section 9.3.5, the
3GPP TS 24.008 "Mobile Allocation" shall for compatibility reasons
be included but empty, i.e. the length shall be zero. Therefore,
no matter if frequency hopping is in use or not, send it empty.
Change-Id: Ie224a45f10522332eac653fa371564f022108c3f
Related: OS#4545, OS#4546
In the state LCHAN_RTP_ST_WAIT_MGW_ENDPOINT_CONFIGURED, the event
LCHAN_RTP_EV_ROLLBACK is allowed and also handled in the action
callback, which causes a change to LCHAN_RTP_ST_ROLLBACK. However,
LCHAN_RTP_ST_ROLLBACK is missing from the out_state_mask.
Change-Id: Ifca3892901c8389beee6e4f0fea03c33cfbdc265
We assume the SI shall be re-sent because something has changed. This
means that change_mark should be incremented. Let's call
gsm_bts_set_system_infos() which already does the trick.
Change-Id: I73d9bd3cddc561f3a7af8bcc225fac126dca3f78
Closes: OS#3679
This recently merged patch introduced a new bad segfault in bsc_compl_l3() by
dereferencing conn->sccp.msc before it was set to the actual msc pointer:
commit 6281d4f869
"fix crashes due to OSMO_ASSERT(conn->lchan)"
Change-Id Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
Fix that by moving the new checks back further down in bsc_compl_l3(), to where
conn->sccp.msc actually points at the msc.
Change-Id: Ic5832da7c58fce583caa504a90f18c334fc234f2
Found while playing with "rf_locked 1" on a 2TRX setup with channel
allocator descend. After applying the setting, the 1st TRX is still used
to allocate the channels. After this patch is applied, the BSC correctly
allocates channels from TRX0.
Change-Id: I5201d2749363c9cbd0706177bde09117b163cbe3
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed
that osmo-bsc crashes with the following message:
Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376
The cause of this is a recently merged patch that calls conn_get_bts() during
assignment_fsm rate counter dispatch:
"Count assignment rates per BTS as well"
commit b5ccf09fc4
Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a
The root cause being that the assignment_fsm attempts to count an Assignment
event for a BTS after the lchan has already been released and disassociated
from the conn.
The assertion is found in conn_get_bts(), which is used in various places. In
fact, each caller is a potential DoS risk -- though most are in code paths that
are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the
relatively volatile presence of an lchan is not a good idea for osmo-bsc's
stability and error resilience.
- Change conn_get_bts() to return NULL in the lack of an lchan.
- Adjust all callers of conn_get_bts() to gracefully handle a NULL return val.
- Same for cgi_for_msc() and callers, closely related.
Here is a backtrace:
Program received signal SIGABRT
pwndbg> bt
0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376
0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758
0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325
0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257
0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260
0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291
0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953
0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6
0x0000555555b61bbe in _start ()
In the case of the assignment_fsm counter, we now miss a chance to increase a
BTS counter for a failed Assignment, but this is a separate problem. The main
point of this patch is that osmo-bsc must not crash.
Related: OS#4620, OS#4619
Patch-by: fixeria
Tweaked-by: neels
Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
osmo-bts (in combination with osmo-pcu) has been supporting paging
for CS services via PCU/PACCH for a very long time. Let's make sure
this is reflected by the correct BSS_PAGING_COORDINATION bit.
Change-Id: I0e80ca5afc06737273b6699bde6e325e454b57f6
Requires: libosmocore.git Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38
Related: OS#2406
If the BTS downlink CCCH (PCH + AGCH) queue is full, it sends
us an RSL DELETE INDICATION. So far, osmo-bsc logs this as
<0004> abis_rsl.c:2026 Unimplemented Abis RSL TRX message type 0x14
which is not very helpful. Instead, make the log message more
descriptive and add a rate counter for monitoring.
Change-Id: I9bd2966db90e39ccca442d6bc9abc91e9a9147d4
Closes: OS#3190
Particularly on BS-11 with only one TRX installed, this will improve
the output of bs11_config from
PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: unknown 0x8 Abis-link: Down
to
Change-Id: I10a77315d537681985f8390b838a4cabfb7d27f3
PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: Not equipped Abis-link: Down
For historical reasons we had bsc_vty.c and osmo_bsc_vty.c. Ever since the
osmo-nitb split, there is no reason to keep these files separate. Merge
osmo_bsc_vty.c into bsc_vty.c (because osmo_bsc_vty.c is smaller).
I noticed this particularly because adding the NRI configuration required
adding things like #define NRI_STR in two separate files: once for the
'network' level vty, and once for the 'msc' level.
Change-Id: I7fd2ee631b22e38f3d96d8159dc1deaaca6a7013
This message may contain optional IEs (HSN, MAIO, ARFCN list),
so we cannot know the final length in advance. Let's set both
msg->{l2h,l3h} pointers and use msgb_l3len() to get the length.
Change-Id: I948ad4b847921324794a6eabd95d5583324da6e4
Related: OS#4545
3GPP TS 12.21 defines coding of 'ARFCN List' attribute as follows:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| Length | 2-3 octets |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 3) octets |
+---------------------------+--------------------+
so this is basically TL16V, where L16 is the length of V.
In the Siemens dialect of OML coding rules are different though:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| ARFCN count | 2nd octet |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 2) octets |
+---------------------------+--------------------+
so this is TCV, where C is the amount of ARFCNs in V.
This change fixes encoding of 'ARFCN List' for other dialects,
in particular encoding of the 'Length' field (1 vs 2 octets).
I verified the results in Wireshark (generic 3GPP TS 12.21
and ip.access dialect), everything looks good.
Change-Id: Iec1826f55459ac8e9355328a1a6bb0949874db60
Related: OS#4545
Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f
(osmo-ttcn3-hacks).
Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
In the ttcn3 tests, the MSC round robin algorithm is affected by what tests ran
before, so an osmo-bsc test needs this to reset the round robin to get
predictable behavior to test against.
Change-Id: I2155d906505a26744966f442ffb1e87a6a9b494c
As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid
attaching new subscribers to it:
4.5a.1: "UEs being moved from one CN node are stopped from registering to the
same CN node again by an O&M command in BSCs and RNCs connected to the pool."
Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
At this time, no MSC has been selected for handling this subscriber, so DMSC is
clearly the wrong logging category.
Change-Id: I9c6373e5f28c9c69a0609889188ef28ade11da3d
Use the new osmo_mobile_identity API to shed some code dup and simplify.
gsm48_paging_extract_mi() is now unused, drop.
(More refactoring to use osmo_mobile_identity follows in subsequent patch.)
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: Id6cccaac64392b737b3bba8f3a22a88009adb23b
Move 'doc' subdir further down to "make sure" the osmo-bsc binary is built
before the docs.
Remove bsc_vty_reference.xml from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-bsc --vty-ref-xml cmdline switch.
Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals)
Change-Id: I5dc872149154e1a949bb6a2b9bbc1461e0fc51f6
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: I316efedb2c1652791434ecf14a1e261367cd2fb7
This adds the assignment counters for the BTS as well and changes the
assignment_count() macro to increase both the counters for the BSC as
well as the BTS.
Related: SYS#4877
Change-Id: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Prepare for MSC pooling by NRI. Before introducing actual NRI decoding and MSC
matching, fix the bsc_find_msc() implementation.
(Indicate the places relevant for NRI by "TODO" comments).
bsc_find_msc() puts an MSC to the end of the internal list of MSCs when it was
used. This has problems:
- Modifying the list affects VTY output, e.g. 'show running-config' and
'show mscs' change their order in which MSCs are shown, depending on how
often a round-robin selection has taken place.
- Emergency calls and normal calls potentially pick quite different sets of
eligible MSCs. When the round-robin choices between these sets affect each
other, the choice is not balanced. For example, if only the first MSC is
allow_emerg == true, every emergency call would reset the round-robin state
to the first MSC in the list, also for normal calls. If there are regular
emergency calls, normal calls will then tend to load more onto the first few
MSCs after those picked for emergency calls.
Fix: Never affect the ordering of MSCs in the internal list of MSCs. Instead,
keep a "next_nr" MSC index and determine the next round-robin target like that.
Keep a separate "next_emerg_nr" MSC index so that emergency call round-robin
does no longer cause normal round-robin to skip MSCs.
Further problems in current bsc_find_msc():
- The "blind:" label should also do round-robin.
- The "paging:" part should not attempt to use disconnected MSCs.
- Both should also heed NRI matches (when they are added).
Fix: instead of code dup, determine Paging Response matching with an earlier
Paging Request right at the start. If that yields no usable MSC, continue into
the normal NRI and round-robin selection.
The loop in this patch is inspired by the upcoming implementation of MSC
pooling by NRI, as indicated by the two TODO comments. The point is that, in
the presence of an NRI from a TMSI identity, we always need to iterate all of
the MSCs to find possible NRI matches. The two round-robin sets (Emergency and
non-Emergency) are determined in the same loop iteration for cases that have no
or match no NRI, or where a matching MSC is currently disconnected.
Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
Testing these functions is actually done in libosmocore. Also, with new
osmo_mobile_identity API, the functions being tested are marked deprecated. So
drop the test.
BTW, the test contained an IMSI of 16 digits, which is too long, yet was
expected to succeed. GSM23003_IMSI_MAX_DIGITS == 15. I first considered fixing
the test data, but the test is in the wrong place here anyway.
Change-Id: I902d31ecd72d71892fad7945f695a9f1fb403bf2
The value of the feature vector can not only be greater, but also
shorter than size of the buffer! This would potentially result
in a buffer overrun. Let's fix this.
Change-Id: I65e3228022865ea73de2e4821985df3097b9448b
This is unlikely to cause any problems, but having a NULL-pointer
that can potentially be dereferenced is dangerous. Fix this.
Change-Id: Icf594604f69023d1483e897edb811e51774b5b8e
The separate struct osmo_bsc_data is like another separate struct gsm_network
for no reason. It is labeled "per-BSC data". These days, all of this is a
single BSC and there will not be different sets of osmo_bsc_data.
Drop struct osmo_bsc_data, move its members directly into gsm_network.
Some places tested 'if (net->bsc_data)', which is always true. Modify those
cases to rather do checks like 'if (net->rf_ctrl)', which are also always true
AFAICT, to keep as much unmodified logic as possible in this patch.
Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
Another legacy feature. All that this setting effectively does is prevent MSCs
from being contacted for non-emergency calls. To select which MSCs shall handle
emergency calls, there is the allow_emerg flag.
Change-Id: I7fc630d9c35be9a69a0d378d3de2b2312c69690d
The BSC is the wrong network component to originate USSD messaging, as can be
seen in the hacks in the USSD code: for example, the BSC would send a CM
Service Accept message as if an MSC had accepted the connection, dispatch a
USSD and directly send some RR release message (without proper tear down
messaging like the lchan_fsm does these days). This made sense in the osmo-nitb
world, but by now we are aiming for solid 3GPP compliance. The BSC shall not
originate USSD messages.
Deprecate all VTY and CTRL commands related to USSD:
VTY
[no] bsc-welcome-text
[no] bsc-msc-lost-text
[no] bsc-grace-text
[no] missing-msc-text
(the commands with 'no' are ignored, without 'no' lead to an error)
CTRL
ussd-notify-v1
Drop (already unused) ussd.h.
Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code.
Drop "RF grace" notification, where osmo-bsc was able to notify active
subscribers that the RF was being turned off.
Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
Tweak return code handling: also return a failure code when dispatching the
GSCON_EV_A_CONN_REQ event failed.
Change-Id: I939e8a9a865250033e4837439a6b9ec251e5ce4c
It is not entirely clear to me what this used to do once, but I've stumbled
upon this before. By now I am certain that this is a non-standard legacy
feature. The BSC does *not* redirect connections during CC transactions.
Along with this, a bunch of legacy utility functions can be dropped. All of
this is unused code.
(Preparing for MSC pooling.)
Change-Id: Id54afe8ccf0e11b9121a733224054c9565eafb58
Whether to forward the message or not to an SCCP connection is
an internal question for the GSM 04.08 code. Unlike errors with
the message decoding, memory allocation and other critical errors,
this not an error which should be reported to the caller.
abis_rsl_rx_rll() (the caller) shouldn't know about the message
routing decisions and should only care about actual errors.
This code path is hit in production very often because we frequently
receive a Classmark Change message from a phone right after the MSC
has shut the SCCP connection but before we close the lchan on the BTS.
Change-Id: I2d430ebc894a2345bebaa1841a75e94a3b45eae2
conn->fi might be NULL and thus can't be safely dereferenced.
E.g. we're checking if it's NULL or not just a few lines above. so we
should here as well.
Here is a backtrace for the crash:
(gdb) bt
0 0x000055b948002772 in gscon_forget_lchan (conn=0x55b949c6b870, lchan=lchan@entry=0x7f00ae9ade68) at bsc_subscr_conn_fsm.c:718
1 0x000055b948036c84 in lchan_fsm_wait_rf_release_ack_onenter (fi=<optimized out>, prev_state=<optimized out>) at lchan_fsm.c:1040
2 0x00007f00afc6a599 in state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, keep_timer=keep_timer@entry=false, timeout_ms=2000, T=3111, file=<optimized out>, line=1344) at fsm.c:699
3 0x00007f00afc6aa5d in _osmo_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, timeout_secs=<optimized out>, T=<optimized out>, file=<optimized out>, line=<optimized out>)
at fsm.c:748
4 0x00007f00afc78e62 in _osmo_tdef_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, state=state@entry=8, timeouts_array=timeouts_array@entry=0x55b9482b56a0 <lchan_fsm_timeouts>, tdefs=<optimized out>,
default_timeout=140730455622800, default_timeout@entry=5, file=file@entry=0x55b948079d39 "lchan_fsm.c", line=1344) at tdef.c:346
5 0x000055b9480341eb in lchan_fsm_timer_cb (fi=0x55b949bcfe10) at lchan_fsm.c:1344
6 0x00007f00afc6b84a in fsm_tmr_cb (data=0x55b949bcfe10) at fsm.c:325
7 0x00007f00afc65926 in osmo_timers_update () at timer.c:257
8 0x00007f00afc65cda in _osmo_select_main (polling=0) at select.c:260
9 0x00007f00afc66526 in osmo_select_main_ctx (polling=<optimized out>) at select.c:291
10 0x000055b947fdcadf in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953
(gdb) p conn->fi
$1 = (struct osmo_fsm_inst *) 0x0
Change-Id: I2427266ef4660935cde899462fa6df8d785c420e
Filtering by IMSI in osmo-bsc is a legacy use case with questionable
usefulness. Remove.
Do not keep deprecated VTY commands: those could be dangerous, since
(presumably non-existing) users might assume that the filtering would still be
in place. Rather fail to start osmo-bsc for config with an IMSI ACL.
The IMSI filtering did, if present, provide the logging with an IMSI to print
for the bsc_subscriber. TMSIs should have ended up in logging likewise, which
has never been implemented. The proper way to learn the IMSI would be by the
Common Id message from the MSC. Furthermore, the upcoming MSC pooling feature
will extract the mobile identity again, and will hence make sure that both IMSI
and TMSI identities, as available, end up in the bsc_subscriber and will be
logged again.
So long, IMSI ACL, and thanks for all the fish.
Change-Id: I89727af5387e8360362e995fdee959883c37d89a
Remove OpenSUSE bug report link, set version to @VERSION@, make it build with
CentOS 8 etc.
Related: OS#4550
Change-Id: I4b87cb0d80bda7bbfda600310aee24a814f97f3f
osmo-bsc has crashed with the following backtrace:
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007f0bc49b38db in __GI_abort () at abort.c:100
2 0x00007f0bc581ba30 in osmo_panic () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
3 0x00005648ceeced69 in conn_get_bts (conn=<optimized out>) at ../../include/osmocom/bsc/gsm_data.h:1392
4 0x00005648cef37164 in conn_get_bts (conn=0x5648cf769e80) at osmo_bsc_filter.c:87
5 bsc_patch_mm_info (conn=conn@entry=0x5648cf769e80, data=<optimized out>, length=<optimized out>) at osmo_bsc_filter.c:48
6 0x00005648cef371b6 in bsc_scan_msc_msg (conn=conn@entry=0x5648cf769e80, msg=msg@entry=0x5648cf77ead0) at osmo_bsc_filter.c:159
7 0x00005648cef33988 in dtap_rcvmsg (msg=0x5648cf72b2f0, length=40, conn=0x5648cf769e80) at osmo_bsc_bssap.c:1215
8 bsc_handle_dt (conn=conn@entry=0x5648cf769e80, msg=0x5648cf72b2f0, len=40) at osmo_bsc_bssap.c:1299
9 0x00005648cef3b2b7 in handle_data_from_msc (msg=<optimized out>, conn=0x5648cf769e80) at osmo_bsc_sigtran.c:152
10 sccp_sap_up (oph=0x5648cf72b378, _scu=<optimized out>) at osmo_bsc_sigtran.c:267
11 0x00007f0bc5813c03 in _osmo_fsm_inst_dispatch () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
12 0x00007f0bc51a8935 in sccp_scoc_rx_from_scrc (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scoc.c:1695
13 0x00007f0bc51a62f3 in scrc_rx_mtp_xfer_ind_xua (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scrc.c:459
14 0x00007f0bc51a9545 in mtp_user_prim_cb (oph=0x5648cf7681f8, ctx=0x5648cf6a8d60) at sccp_user.c:182
15 0x00007f0bc51a09c6 in m3ua_rx_xfer (xua=0x5648cf764a80, asp=0x5648cf45f540) at m3ua.c:586
16 m3ua_rx_msg (asp=asp@entry=0x5648cf45f540, msg=msg@entry=0x5648cf71e880) at m3ua.c:739
17 0x00007f0bc51b0763 in xua_cli_read_cb (conn=0x5648cf441ed0) at osmo_ss7.c:1761
18 0x00007f0bc55fab53 in osmo_stream_cli_read (cli=0x5648cf441ed0) at stream.c:232
19 osmo_stream_cli_fd_cb (ofd=<optimized out>, what=1) at stream.c:321
20 0x00007f0bc580edcf in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
21 0x00007f0bc580f526 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
22 0x00005648ceecfb2f in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953
Apparently, there is no lchan allocated at this moment, so
conn_get_bts() crashes. But we only use it to get to "network" which
we can do much easier and safer by doing conn->network.
Change-Id: Id3f7b3efba60c0f050c1be98e5e539f1dab4cd57
The bsc_msc_data->rtp_base has been unused ever since we introduced the exernal
MGW in osmo-bsc [1]. The vty command also still exists. Deprecate the vty
command, remove the member.
[1] "mgcp: use osmo-mgw to switch RTP streams"
commit 39c609b7c9
Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a
Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
We decode the mesage and print it to the log files at ERROR log level.
We also count it in the BSSMAP message counters. There is not much
else we could do about it.
Depends: If8afd2d096fb66c6c2f255a08fc1129de3d09cec (libosmocore)
Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
This is a corner case but still we should count the events to
know when is this happening. And for the number of paging requests
to match the number of paging responses.
Change-Id: I1755be40d29980b75353cb4b8087d1ce0d92854a
I notice that some merges seem to have missed updating the
bsc_vty_reference.xml file. Re-generating it from current master yields these
changes.
Change-Id: I75269cbed8dd62be23293fd2c1470af6f61e6ad2
Not sure why this specific message is ERROR while similar ones around
are DEBUG. So let's fix this disparity by demoting this message level.
Change-Id: I655d4555f037def354aacbc5f089794f5fe811ed
The "CHAN RQD: reason" message is purely informational and is a part
of normal operation. Nothing to NOTICE there. Let's demote this to
DEBUG.
Change-Id: I325f2beb3248ed8eb25d1d8494c3868c5be4b758
We're sending multiple RESET messages to establish a conection with
an MSC and MSC can (and often will) respond with multiple RESET ACK
messages. We should not treat this as an ERROR as it used to be
in the original code.
Change-Id: I109d638d5167e24f0357e3541415b9e7269aa5d1
The "new SIGTRAN connection" message is sent on every new transaction
between an MS and MSC, i.e. A LOT during normal operation. Let's
demote it to INFO and clarify that this is about SCCP connection
instead of a generic SIGTRAN term.
Change-Id: I711b70ae84aa98f43ea3f807ea5c8464b71ca6bb
"Paging request failed" message can be logged e.g. when we're already
paging this subscriber which means we get hundreds of these messages
in a perfectly normal situation. Let's demote this to INFO and adjust
the wording.
Change-Id: I97214796906ac599338e87b2b4b5465ab6b2447a
We already have counters for Rx side, now we also count Tx side.
See comments in the msc_ctr_description array implementation for
the details.
Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
It should be fine if we receive PDCH_ACT_ACK late. We should just go
into the PDCH state as normal.
Change-Id: If816b681e0b2e76fb7122cf211e15eeee92451ee
In the lchan_fsm_borken() we request to change the state to
LCHAN_ST_WAIT_RF_RELEASE_ACK in response to a late
LCHAN_EV_RSL_CHAN_ACTIV_ACK event but this transition is prohibited
by the FSM definition, so the channels stay in the BORKEN state
forever. :(
Change-Id: I17a9b935a116eb842fd0239ef53d73bef35e6511
Explanation from Harald:
There are plenty of things that can happen above the bare SCTP/M3UA
connection which can happen, such as SCCP or MTP level routing
problems.
The fact that a MSC responds to a BSSMAP reset tells us that all of
the underlying SS7 transport network is operational and the MSC
responds to us.
Go draw an IP analogy: Saying "SIGTAN connection up" here is like
saying "Ethernet link up" when you get an ICMP response.
Change-Id: If9d37c94f2f2b6cffef97f445774766993f538db
Parts of Osmo-BSC want to see the NM state as valid ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I0db11819d23e40272c4aa6fd093365b9c13f7bcf
It's useful to know how many BTS are actually configured to compare
it to a number of connected BTS's.
Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
I originally assumed that after a complete scan with llist_for_each_entry
the loop counter would be either NULL or a valid entry. That's just not
the case.
Fixes: CID#210256
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iad647b74771c4ac406a88effd371ed7748c8847e
From the CS perspective, there is no difference whether this is
a dynamic TS in NONE/PDCH mode or a static TCH in UNUSED mode since
BSC can switch into USED mode at any moment. So we should count
dynamic timeslots in the "total" count.
A bit of a challenge here is that GSM_PCHAN_TCH_F_TCH_H_PDCH
timeslots could be either switched to a single TCH/F or to
two TCH/H, so the total can't be calculated reliably beforehand.
In this code we assume TCH/F since this gives a lower total
count.
Change-Id: Iabd70e8adbf15eb3b7a7be597281ea99b352317b
The OM2K link "per-trx" only comes up after MCTR is setup. So that means
we need to wait for it before trying to boot the TRX itself.
He we simply apply a "dumb" 5 sec timeout as this is the most reliable
way I found to get this working reliably.
Tracking the link state proved difficult and unreliable:
- Multiple TRX can be present with their link coming up in random
order.
- They can already be up at the start (BTS already initialized from
a previous boot) and so the link may actually come up, down, and
up again.
- All of theses transitions might happens before/after we get to the
OM2K_BTS_S_WAIT_TRX state depending on how the LAPD timeout
expire, if the BTS config was actually changed or not and how much
time it takes to apply the new config.
So all in all, what we must do is wait for the link to stabilize ...
hence just waiting 5 second.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I55a06e08b9c52ff6e97e8c72f2d55770809eba51
Currently only supports a single MCTR with fixed configuration
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
Starting from G12R13 the MCTR swiches to BSC controlled mode. And
although we think we know how to configure it (via MCTR Conf Req),
something doesn't work right and the timeslot configuration is not
accepted. (TS Conf Result shows "Data not according to request").
So as a workaround for now, we use this version of the protocol where
we don't configure the MCTR (it's in "BTS controlled mode") and with
this protocol, the BTS accepts our timeslot config and we can bring
the system up.
This commit add a generic option to limit either OML or RSL IWD
version to any value. It also keeps track of the actual negotation
version so we can react to it in other places of the code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65
better version limit
Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
* OM2K_DEI_FREQ_SPEC_RX:
(hop << 15) | (rx_addr << 10) | arfcn
. hop Hopping marker
. rx_addr is not really the TRX number, it's just a sequential number
different for all TRX, doesn't need to be 'in-order' of TRX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_SPEC_TX:
(hop << 15) | (tx_id << 10) | arfcn
tx_id Pretty much same as rx_id except here we know that the order
doesn't have to match TRX order. It seems to even vary from one
reboot to another on some real-world capture we got.
. hop Hopping marker
. tx_addr Same as 'rx_addr' above but for TX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_LIST:
Groups of 3 bytes (24 bits), 1 per frequency used.
(tx_addr << 20) | (rx_addr << 16) | (is_c0 << 10) | arfcn
. tx_addr See above
. rx_addr See above
. is_c0 Must be 1 if that ARFCN hosts the C0. (first TRX of a MCTR)
. arfcn The ARFCN number
(Note MAIO must also be set properly on the different TRX/TS sharing
a frequency ... )
The way we generate theses here is what we gathered from real-world
traces:
- Each 'TX' of each TRX is set to the ARFCN set in that TRX config
- Each 'RX' of each TRX is configures as 'hopping'
(which I assume means it will just pick the appropriate freq ?)
- For each TS, we use :
. tx_addr of the TRX that has the ARFCN we want to TX on
. rx_addr of the TRX where the TS we're configuring is
. arfcn The actual ARFCN we want to add to the list
This is incomplete but will work for the 1 MCTR case.
Config for multiple MCTR or multiple virtual-bts still need to be
handled but it's not yet known exactly how those need to be
configured.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie39a857543adaa11d1822346d8563ce3718412c8
During the configuration of the TS object through OML we must use
pchan_from_config since it's too early to use anything else.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iecdc911a79b66d8f3d746347710ad697cb288174
The existing Nokia *Site code destroyed the LAPD SAP instance for OML
while processing an OML message. Once the stack frame returned back
to the LAPD code, the LAPD SAP was gone -> segfault.
Let's work around this by moving deletion of the LAPD SAP out-of-line
by starting a timer 0ms in the future. Not particularly nice, but
effective.
Change-Id: I6270c7210f600e53f845561898245d2fd30a368d
Closes: OS#1761
This is probably a fault report of some kind, but didn't get any
confirmation or naming from anywhere for it yet.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8333093d09f27f61094c7f5854573aa16e4bf28c
Thoses messages IDs are 16 bits and the upper 8 bits are sort of
important :D
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ifcc1a01fdbf66a0f6f44cf8fed60dc19e72dd56a
* In superchannel mode, those 3 are required.
* In normal mode, "Config Type" is optional and the two others are
forbidden.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: If02d02c067ae8af8ce693ddfb8747212f3f4e441
slashes are invalid so we can't use om2k_mo_name() directly, so we just
build it manually with dashes.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I3cfc19670e6d7bb607d796cabcee5e86a15d1985
Make various internally used timers negative, to indicate that they are
Osmocom specific. A follow-up patch will make them configurable.
Change-Id: I6f8be40ea54a3083f4b21ab938cc1723fc67c2ef
/usr/bin/ld: bsc_subscr_conn_fsm.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: multiple definition of `mr'; abis_rsl.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: first defined here
See also https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000649.html
Change-Id: Ic21af84f2a6de48d220940f30dad02a0e7683ce8
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE
contains two parameters related to 11 bit Access Burst support:
- ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be
used in the PACKET CHANNEL REQUEST message, the PTCCH/U block,
PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS
messages on the PRACH (if present).
- EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall
use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF
establishment on the RACH or on the PRACH (if present).
The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls
the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may
be hard to understand this from its name and description.
This patch is actually a group of tightly related changes:
- deprecate 'gprs 11bit_rach_support_for_egprs (0|1)':
- update its description to avoid any possible confusion,
- print a warning if it's used in non-EGPRS mode,
- print a warning if it's still used;
- introduce '[no] gprs egprs-packet-channel-request':
- ensure that it can only set / printed in the EGPRS mode;
- take a chance to clean-up / rename the related struct members:
- 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request',
- remove 'supports_egprs_11bit_rach' from 'gprs_cell_options'
because we already have 'ext_info.use_egprs_p_ch_req' there.
Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: If71654d87b375b4b882ab527e89353cd035f695b
This logging category has been removed in [1], what caused test
case execution failures on our Jenkins (since build #930). The
problem is that configuration files may still contain this
category in 'logging' section (see [2], [3], [4]), and
osmo-bsc would refuse to start because of that.
[1] Id965295dfe04f8bd5ce831db70c86f67b8dc290b
[2] Ie2afacfc15589c26238214cddc00baaf80e993c1
[3] I266d6f6ed54d1457b1ca63b87fc1c29f6dd40caf
[4] If02272c08ba2df37d1295d09c104d11f96abbe1e
Change-Id: I111362d19aba325889bada5a46eea62343c30033
This dates back to a time where osmo-bsc_nat was in the same repository,
which is a long time ago.
Change-Id: Id965295dfe04f8bd5ce831db70c86f67b8dc290b
Link to the osmo-gsm-manuals/common/cs7-config.adoc chapter to fully explain
the 'cs7' client configuration.
Related: OS#2767
Depends: Ia2508d4c7b0fef9cdc57e7e122799a480e340bf7 (osmo-gsm-manuals)
Change-Id: I5b4973901f02046322b852fd9862517982d21bd9
If, as before this patch we call initCDKScreen() before
attempting to bind the socket, then the socket bind fails,
we exit and the terminal needs a reset.
Attempt to open the socket before initCDKScreen()
so we don't end up with a messed up terminal if the socket
call fails.
Change-Id: Ia5148d9ef386df314bc2837b3cb672150250bd2a
The measurement tools use libosmocore socket functions that will
use logging if the socket cannot be opened, but the tools did
not initialise logging, resulting in
Assert failed osmo_log_info logging.c:235
backtrace() returned 9 addresses
[.....]
Initialise logging so that we get a nicer and more informative
message, such as:
unable to bind socket:(null):8888: Address already in use
no suitable addr found for: (null):8888
Change-Id: Ib3b3558723682defcee22e7ea2d8bf5c2cff1278
Save OML failure reports from each BTS. Add a VTY command to display them
conveniently and optionally clear the list.
OsmoBSC> show bts 0 fail-rep
[2020-03-23 14:51:22] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
[2020-03-23 14:51:19] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
Related: OS#1605
Change-Id: I18aa17a721cd5eb1c98926dc2367229c0a50bc78
Separate raw input parsing from handling the failure report. A follow-up
patch will use the new parsing function to print saved failure reports
to the VTY.
While at it, put struct tlv_parsed inside struct nm_fail_rep_signal_data
instead of a pointer, so we don't need an additional alloc. Also add
error handling to the abis_nm_tlv_parse() call.
Related: OS#1605
Change-Id: Ia51004faf620aa4d40435d58c70d758c9d0054d8
Use the extra bts pointer instead of mb->trx->bts, which does not point
to an allocated bts.
Related: OS#1605
Change-Id: Ie61512f5690763fa380bdf0e7fb4763dbda019d2
Refuse to start with mutually exclusive codec settings, unless
allow-unusable-timeslots is set in the network section of the config.
The checks were already implemented and fill the error log if the config
is invalid.
Related: OS#3739
Change-Id: I3ccfc3b0a8641400cb97a23b24d7ed92d2ad25cd
All timeslots are configured for full rate, so the codec list must also
have a full rate codec. Fix this error on startup:
"Configuration contains mutually exclusive codec settings -- check configuration!"
All other example configs don't have mutually exclusive codec settings.
Related: OS#3739
Change-Id: Iddac13c7d644ed57b6d9e6a57d23d88c01bd8b8e
OM2000 is not only used for the venerable RBS2000 family, but also
for the more modern RBS6000 family, specifically the DUG 20 GSM
baseband unit.
In RBS6000, there are some protocol extensions which are not yet fully
understood. However, we are understanding some bits around the MCTR
(multi carrier transceiver?), a new MO that appears to be present for
every physical RUS (Radio Unit) attached to the DUG 20.
Let's add what we have learned so far.
Thanks to Sylvain Munaut for his help with this.
Change-Id: Ib868358eca12b94c4fcca58e94ec8ab1a4edfda2
Calling osmo_tdef_vty_write() twice: with and without the 'timer '
prefix definitely looks like a bug. After setting any timer to a
custom (non-default) value, config_write_net() would generate an
incorrect configuration file:
$ osmo-bsc -c /tmp/osmo-bsc.cfg
There is no such command.
Error occurred during reading the below line:
T10 10
Change-Id: I5cc893fb2077bb21f1f661e30a7ab2af1b9bd561
The loglevels of DNM, DFILTER and DPCU are set to low, lets set them all
to NOTICE
Change-Id: I03a5426b341e9908ffc89240f97d6d3ea791b4a8
Related: OS#2577
Let's not just pass around the raw msgb, but also all other metadata,
such as the decoded parts of the TS 12.21 message.
As there's no current consumer of that signal, this creates no
compatibility issues.
Change-Id: I5d4d9d422b4e23348ffbe69c6e87a31d5574f90d
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I438ca0c4b8e7957d0f347a5b2f5c4cb93f9325e6
gsm_04_80_utils.c: In function ‘bsc_send_ussd_release_complete’:
gsm_04_80_utils.c:37:9: warning: ‘gsm0480_create_ussd_release_complete’ is deprecated: Use gsm0480_create_release_complete() instead. [-Wdeprecated-declarations]
37 | struct msgb *msg = gsm0480_create_ussd_release_complete();
| ^~~~
CC gsm_data.o
In file included from gsm_04_80_utils.c:22:
/usr/local/include/osmocom/gsm/gsm0480.h:120:14: note: declared here
120 | struct msgb *gsm0480_create_ussd_release_complete(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The commit is not changing the existing logic/assumption: TID 0 should
not be in use by anything else at the point the USSD is generated.
Change-Id: I739158dec62cd5f0c2080fbb426af9c024baef87
Replace python 2 code using pychart to draw a graph in
osmux-reference.adoc with the generated svg file. The upstream of
pychart is dead, there is no python 3 version, and python 2 is EOL at
the end of 2019.
This is the only time we ever made use of pychart in osmo-gsm-manuals,
so with this change, we can just drop the dependency.
I've generated the chart by saving the python code in chart.py, then:
$ ./chart.py --format=svg --font-size=3 > chart.svg
Related: OS#2819, OS#4193
Depends: osmo-ci I754b133d77743582bd84c33c74ecc9eb9ca4c0ef
Change-Id: I36b721f895caee9766528e14d854b6aa2a2fac85
After sending of NM_MT_IPACC_RSL_CONNECT message, we start a timer,
and stop it on receipt of NM_MT_IPACC_RSL_CONNECT_{ACK,NACK}. When
running a multi-trx setup, one can see the following warnings:
DRSL NOTICE abis_nm.c:2852 (bts=0,trx=1) RSL connection request timed out
DRSL NOTICE abis_nm.c:2852 (bts=0,trx=2) RSL connection request timed out
even despite NM_MT_IPACC_RSL_CONNECT is actually being acknowledged.
The problem is in abis_nm_rx_ipacc(): we cannot just use sign_link->trx,
because the message itself was received over the OML link, so this
pointer always gives us C0/TRX0. Instead, we must find a TRX by its
number from the FOH header using gsm_bts_trx_by_nr().
Change-Id: Ib4b9a198da11c88a51cfa78ffb7e7235a6365ef4
This way we can avoid the runtime overhead of checking whether or not
it is initialized over and over again. It also brings this code more
in line with other users of osmo_fsm_register().
Change-Id: I3c7220491cf6ffb1361e7259c0344df64a013a0a
Since osmo-bsc uses the MGCP client FSMs, it is required to enable this new
feature to guarantee safe operation. The issue is described in detail in commit
logs linked below.
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Related: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 (osmo-mgw)
Change-Id: Ib7fce7b7d54dfb87af97544796680919e5929a50
Lots of times, the MS power class is unknown until after the first
channel has been activated, at which point the MS power class is
received in messages such as LU update or CM Service Requet.
Since the MS Power level is sent upon CHAN ACT, the only way to
communicate the change of maximum MS Power (based on MS power class)
after CHAN ACT is to send a MS Power Control msg. Let's do that.
Related: OS#4244
Change-Id: I3d6b75578e5cb9b2ad474a0ad01362d846ebe135
As can be seen from include/osmocom/bsc/gsm_data.h:
- pchan_from_config - channel configuration from the VTY/config
(can be changed from the VTY at runtime, should not affect
the existing RSL/OML connections);
- pchan_on_init - channel configuration after the OML link is
established (pchan_from_config is copied here);
- pchan_is - the *actual* channel configuration currently active.
Since we call bootstrap_bts() during the initialization, even before
establishing any OML/RSL connections, neither pchan_on_init nor
pchan_is can be used. Let's use pchan_from_config instead.
This change fixes the problem discovered by @mqng2 and reported
together with https://gerrit.osmocom.org/c/osmo-bsc/+/15909:
CCCH_CONF in System Information Type 3 does not reflect the
actual channel configuration, and always indicates a single
CCCH combined with SDCCH. This also misleads the lchan
allocation algorithm during the MO connection establishment.
Change-Id: I8f9d7aa27f24b55732a4de933bc834ed930806fd
Do not count the number of additional CCCHs if TS0 is using combined
channel configuration (CCCH+SDCCH4), because they are only allowed
if TS0 is not combined with SDCCH.
Get rid of the 'switch' statement using the following formula:
CCCH_CONFIG = (N << 1)
where N is the number of additional CCCHs.
Change-Id: I1430500999389e9b30e55ea89a8a5ea5071f7957
As per 3GPP TS 45.002, section 3.3.2.3, and table 3 of clause 7,
the following limitations apply mapping of CCCH/BCCH channels:
- TS0/C0 shall be configured as CCCH/BCCH (optionally combined);
- combined CCCH (CCCH+SDCCH4) can only be used on TS0;
- additional CCCHs can be on TS2, TS4, and TS6;
- additional CCCHs are not allowed if TS0 is combined.
Let's make sure that OsmoBSC is properly configured before starring.
Change-Id: I758ef80f7884ba35cdf59d671ee30222ffb9d68b
Since MS Power Param IE content is operator dependant, it's currently
not known which kind of content non-osmocom BTS support/allow, so let's
avod possibily breaking those BTS until each BTS has been checked
separately.
Related: OS#1622
Change-Id: If44121222042bdac06c2a5e70f7b35a88b00b27c
Further accesses will be addter in forthcoming commit, so let's first
store the pointers in variables to clean up the code.
Change-Id: Ie5ea0f44dfb5731cab7e8e5a3dd3d791ee703df7
TS 48.058 sec 8.4.1 CHANNEL ACTIVATION and state:
"""
The BS and MS Power Parameters elements are included to indicate that BS
and/or MS power control is to be performed by BTS. The maximum power to
be used is indicated in the BS and MS Power elements respectively.
"""
Since we always want the BTS to do autonomous MS power control, let's
add it.
Related: OS#1622
Change-Id: Icaaa61b363b093f00b6653c3df64d3e66583b9f8
NULL or 0.0.0.0 should actually not be used upon connect() calls.
Whoever, it worked so far because osmo_sock_init2() calls getaddrinfo()
on it which does the 0.0.0.0->127.0.0.1 translation.
osmo-msc already passed 127.0.0.1 as default address, so let's do the
same here.
Change-Id: Ib0d33c66faab78e609742638425cb8a0c382406f
TTCN3 BSC_Tests.TC_ms_rel_ind_does_not_cause_bssmap_reset seems to
sometimes run into a race condition on the order of messages received by
osmo-bsc comming from MSC and BTS.
Usual (expected) scenario):
BTS->BSC EST IND
BSC->MSC CL3 Info
BSC<-MSC CC
BTS->BSC REL IND
BTS<-BSC DEACT SACCH
BSC->MSC ClearRequest
BSC<-MSC ClearCommand
BSC->MSC ClearComplete
BTS<-BSC RF Chan Release
BTS->BSC RF Chan Release ACK
Sometimes CC message and REL IND message are received swapped (because they
are sent by different components asynchronously in TTCN3).
As a result, osmo-bsc was failing to go into CLEARING state and was
unable to send the ClearRequest because CC was still not received.
So the idea is to stay in WAIT_CC until CC is received, then check if
the lchan was dropped and in that case go into clearing state.
Change-Id: Id1abf5ee44c60925b478123409f26bd29006202b
In addition to transmission of the ETWS Primary Notification via all
dedicated channels, we also need to send it to the BTS for transmission
via PCH (P1 Rest Octets) and for forwarding to PCU for PACCH
transmission.
Change-Id: I7e45b0373458a4348b12b92dd92861062532548b
Function fsm_reset_ack_timeout_cb() could be called directly from within
a_reset_alloc(), but it's still desirable to deferr the BSSMAP RESET to
be sent asynchronously by the timer upon next main loop step as soon as
possible, so whole process is already configured properly.
1ms needs to be set instead of 0 (immediate asynchronous) because value
0 actually disables the timer.
As a result, moving the state_chg() after the msc->a.reset_fsm
assignment is not really needed, but still makes it more clear that the
pointer will be set upon call of the timer callback.
Related: OS#4188
Change-Id: I68d76a4050d4dec7d53b0031d67e0dd35ddd8764
As soon as we have received an ETWS primary notification message from
the CBC, we should transmit it as "RR Application Information" to all
dedicated channels.
Change-Id: I913d0237cffdcb95037da8489acef5f32a7fc02e
SCCPlite is long supported (again) by osmo-bsc, let's remove the
outdated pointers to osmo-bsc-sccplite.
Change-Id: Ia3d831aca7c3c7ef9f257e974faf6e8e360c59f5
This adds code to handle CBSP (Cell Broadcast Service Protocol)
from the CBC (Cell Broadcast Centre), as well as BSC-internal data
structures for scheduling the various SMSCB on the CBCH of each BTS.
There are currently one known shortcoming in the code: We don't yet
verify if keepalives are received within repetition period.
Change-Id: Ia0a0de862a104d0f447a5d6e56c7c83981b825c7
When osmo-bsc receives a paging response via the A-bis interface it
tries to find the MSC which is in charge for the paging. This is due to
the fact that osmo-bsc supports multiple msc connections, which is not
specified by 3gpp specs.
In an MT-CSFB call the MSC pages the UE via the SGs interface. Then the
UE falls back to 2G. It then reports back as MS on the A-Bis interface
with the paging response directly. In those cases osmo-bsc will not be
able to determine an MSC in charge, so we will forward the paging
response to the first configured MSC.
Change-Id: I7f091ed1bbc2afe12656e42031e122144eeb6826
Related: SYS#4624
If lchan_select_by_type() fails to find a suitable logical channel,
it would print a message using LOGL_ERROR. This can happen if all
logical channels of the requested type are busy, thus it is not a
error. Let's use LOGL_NOTICE for that.
Change-Id: I9b45852116253e5237b779a91bed8b800758360e
The LOGPC() is usually used for continuation when printing complex
logging messages (e.g. where using format string is not enough).
In this case, nothing is being printed before calling LOGPC(), so
the logging messages appear without the meta info (time-stamp,
level, category, etc.), for example:
BTS 0 reported connected PCU version 0.7.0.1-2585-dirty
Change-Id: I868633ad3e50f2cb3ebfb2c566d16c4710f17563
Fix neighbor config to match OsmoBSC manual: implement the plan for neighbor
configuration that was so far only described in the manual without actually
being in operation.
This first allows re-using ARFCN+BSIC pairs in and across BSS.
So far the handover_start() code always looked for handover target cells across
*all* local cells, even if they were not listed as neighbors to a source cell.
Imply all cells as neighbors only as long as there are no explicit neighbors
configured. As soon as the first 'neighbor' line appears in a 'bts' config,
only the listed neighbors are regarded as handover target cells. (The
'neighbor-list' commands are not related to this, only the relatively new
'neighbor (bts|lac|cgi|...)' commands affect actual handover procedures.)
TTCN3 tests TC_ho_neighbor_config_1 thru _7 play through the various aspects of
neighbor configuration: both the legacy implicit all-cells-are-neighbors as
well as allowing only explicit neighbors by config.
Related: OS#4056
Related: osmo-ttcn3-hacks Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc
Change-Id: I29bca59ab232eddc74e0d4698efb9c9992443983
This is required for an upcoming TTCN3 test that plays through various neighbor
configurations.
Related: OS#4056
Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc (osmo-ttcn3-hacks)
Change-Id: I8623ab581639e9f8af6a9ff1eca990518d1b1211
The struct member struct bsc_msc_data->is_authenticated is set to true
permanently. This is a leftover from the sccplite implementation and can
be removed now.
Change-Id: I966a48b383c85345c92c9a1fec791150e96cd7b9
Related: OS#3112
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Change-Id: Ic3c578347864fa225feb6d2dbe14798b9c19ace0
Related: OS#4138
When we add an EARFCN to to the SI2quater struct we do not add Serving
Cell Priority Parameters. This essentially causes to MS to ignore the
EARFCN because it is still undefined under which conditions the MS
should change to LTE.
Related: SYS#4510
Change-Id: I7eaf7de4386fe8aea404e8a187d8a1f5ed596ead
There is unfortunately no way to suppres this witha pragma,
and gcc 9 uncovers quite a few new instaces with enabled LTO that can't/won't be fixed
Related: OS#4123
Change-Id: I571a85b6ea53af7661248afd84e61cf34b7b5641
It's quite ugly to have manual "bts=%d" printf-statements all over
the BSC code. Let's change this to use shared logging helper functions
all over the place, whenever we need to log something related to one
BTS or one TRX.
This can also help us as the first step to later add alternative logging
of BTS identities, e.g. by printing the Cell Global Identifier or
LAC+CI, or even a human-readable/vty-defined 'name' of the BTS, rather
than its numeric bts number. With this change in place, we can
introduce such changes at a single location in the code.
Change-Id: I4a7814d164384eecfb6913c31802cf2faead6e6c
If no target cell got selected in a handover attempt, enum value NO_HANDOVER is
used. In that case, do not log a lot of errors saying
"invalid enum handover_scope value: none" -- they are misleading.
Change-Id: I98e748bea58ebb02812b6aaa6431c7d4b813242d
Clarify some in-code comments.
Fix descriptions of some handover timers, which still talked of "MO" and "MT"
handover -- which we now call "inter-BSC out" or "inter-BSC in" instead.
Change-Id: I8429a830edd0325893ac90f22fcc05309617bd2d
Run "make maintainer-clean" after publishing manuals, not the other way
around. Otherwise jenkins.sh fails when running for the master branch,
because docs/manuals/Makefile gets deleted although it is still needed
to publish the manuals.
Related: OS#3047
Fixes: 471fd92170 ("contrib/jenkins.sh: run "make maintainer-clean"")
Change-Id: I8ba5369b0948b61c68f43d807312c52465119aa5
If a handover fails when the new lchan is already fully established, osmo-bsc
so far caused two BSSMAP Clear Requests to be sent out to the MSC: one caused
by detaching the lchan from the gscon, one from returning the gscon back to
ST_ACTIVE, which detects that no lchan is present and Clears. In fact only one
of those is necessary.
Checking for the presence of an lchan when entering ST_ACTIVE is an earlier
attempt to catch insane situations. Since then, osmo-bsc has acquired other
logic that will ensure sending a Clear Request in all cases, see
gscon_forget_lchan(). Sending another BSSMAP Clear Request in ST_ACTIVE's
onenter is simply not necessary. Drop gscon_fsm_active_onenter() entirely.
Note: the double Clear Request is currently hit by
TC_ho_out_fail_no_ho_detect(), which currently fails and will pass again after
this patch; however, osmo-bsc should actually not release the lchan at all
during this test, see OS#4093. In other words, osmo-bsc behavior for this
scenario as well as TC_ho_out_fail_no_ho_detect() need to be changed, and the
test will, once fixed, not be useful to trigger this issue anymore.
Related: OS#4078
Change-Id: Iac1519eb8b24e8523caec682f9ac8e6dcf1327ce
bsc_clear_request() is in fact used only within gsm_08_08.c, make it static to
that file.
Since the gscon FSM, "real" BSSMAP Clear are sent only by gscon_bssmap_clear().
bsc_clear_request() remains in use for legacy code paths in gsm_08_08.c:
- the bsc_filter, i.e. for IMSI filtering;
- in move_to_msc(), from handle_cc_setup(), a code path that is in fact not
entirely clear to me. It seems to be an old functionality to serve multiple
MSCs?
Both of which I personally haven't seen in use, are not tested and should
probably be completely removed.
For now contain legacy code in the static context.
Adjust comment.
Change-Id: Ic89d0afad42e4b11183a13d2dc6b7bbf0b822fd9
Old osmo-bsc-sccplite already supported this, but in the migration
over to libosmo-sigtran and to real 3GPP AoIP, this functionality
got lost.
We now create a UDP proxy socket. Any MGCP commands received via IPA
from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on
this socket. Any responses back from the MGW received on the UDP
socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA
multiplex.
Closes: OS#2536
Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
The library has the declarations since 2011, so it's time to
get them removed from here.
Depends: libosmocore d61d517a2e35f482519561bd325652ee7144679a
Change-Id: I5c8d02605a78c6792f616ad423b4491b83f42545
Run it like this:
COMMIT=master DOCKER_PLAYGROUND=~/scm/osmo/docker-playground OSMO_INTERACT_VTY=~/scm/osmo/osmo-python-tests/scripts/osmo_interact_vty.py ./regen_doc.sh
COMMIT will default to current HEAD.
Change-Id: Iedd1f55d021231d86c19b6f14ff296e3a55148c8
Related: OS#1700
Having different names for the same config setting is misleading, so
let's stick to the one used by osmo-bts.
Change-Id: Ide5ceb5db7403a70313405752579e30d7bb94eac
Since in SCCPlite the BSC-attached MGW is controlled by the MSC, we
don't need this kind of signalling. It's only needed for AoIP.
Related: OS#2551
Change-Id: I802fc65c593e42aaa7a15cecab7a2f2b77ade3ea
Having the helper makes it easier to read/find for transport type checks. It
will be ifurther re-used in forthcoming commits.
Change-Id: Ic0ee4c472e29ec3092049e5e23b744395613616d
the 'p_val' variable should represent he 'probabl cause value' and
nothing else. Let's use other local variables for other things.
Change-Id: Ie79279fc1d42cd57e7478820493b250fe38c2f4f
Add a new VTY command "ccch load-indication-threshold <0-100>"
by which the user can configure the threshold after which the BTS
shall send CCCH LOAD IND. It used to be hard-coded to a
default value of 10.
Change-Id: I059fe4627438e26a06e00d84e342b736ab7af440
When displaying the channel (lchan) load, we are interested in the
dedicated channels as available for communication with mobile
stations. If CBCH is enabled, it "steals" one of the SDCCH slots,
so we have to exclude this channel from the count of available
dedicated channels.
Before this patch, A CBCH would show up as "in use" dedicated channel
(so both the total and the in_use count were incremented).
After this patch, neither "total" nor "use" are affected; The CBCH
slot is completely excluded from load statistics.
Change-Id: I606962e4977f122ff05a2d4e756c04c7f38bdaa0
Now that OsmoBTS is generating CBCH LOAD IND messages, let's avoid
spamming the BSC log with notices about receiving this unimplemented
message.
Change-Id: Ida5045ec7a18c1062a3b80a381db52d5c98e9966
Now that OsmoBTS understands about extended CBCH, let's at least
update the BSC side function to allow for other code to generate
such messages.
Change-Id: I77a16b75ce311d63fb022475c8ff25fbbcee7f55
Commit c997ceb750 which added initial code
did use memset(0) on the structure. However, later commit
b407a8aca4 modifying the code forgot to
initialize it, and as a result most of its fields contain garbage.
This results in an MDCX with strange/incorrect values sent when LCLS
loop breaks, breaking TTCN3 test BSC_Tests_LCLS.TC_lcls_connect_break.
Change-Id: Ib1a7d825690db782a5d14f2d8817acf6cb6a52ea
The CID is sent back to the MSC so it can configure its MGW to send
Osmux frames to the BSC MGW using this CID.
Change-Id: I77dfdd965ae828c39a9818669177aefd22bc02f2
The Osmux CID obtained from the MSC is passed to the co-located BSC MGW
to configure the MSC-side MGW conn of a call leg.
Depends on: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de
Change-Id: I86e7e13fc7921e3209fb764c0e7797e7ec09b79e
In Change-Id If6d40b2407b87aad2227ea7f15533ef01a3771b3 we introduced
the support for both octet-aligned and bandwidth-efficient mode, and
added a related VTY option about it.
However, we accidentially also changed the default behavior. Without
any explicit configuration, we should behave just like we behaved all
those years before: Continue with octet-aligned mode.
Change-Id: I8b6fd8bec05b35d84ad16275d84f9d363e238d2b
Closes: OS#4002
For AoIP, the AoIP Transport Layer Address IE must be included in the Handover
Request Acknowledge message, so the MSC can send RTP to the right place. Add
this IE for AoIP.
Depends: Ia71542ea37d4fd2c9fb9b40357db7aeb111ec576 (libosmocore)
Depends: Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Change-Id: Ia05e37da125eb6e7b7be9b974b73261bd72de1f4
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.
Change-Id: I00c18b78573386145af71c4b39f7f22aec24579b
To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Originally merged as Change-Id I4c7499c8c866ea3ff7b1327edb3615d003d927d3,
reverted because the change broke voice calls. Re-submitting with the fix:
don't forget to set conn->assignment.requires_voice_stream.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I7513d2cbe8b695ba6f031ad11560c63a6535cf2d
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example
I92a9944acc96398acd6649f9c3c5badec5dd6dcc.
Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API
and use libosmocore's osmo_tdef* API instead.
The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be
able to use it in osmo-msc for inter-MSC handover.
When adding osmo_tdef, the new concept of timer groups was added to the API. It
would make sense to apply group names here as well, but do not modify the VTY
configuration for timers. The future might bring separate groups (or not).
Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore)
Change-Id: I66674a5d8403d820038762888c846bae10ceac58
This reverts commit 94c9324fe0.
Multiple ttcn3 handover tests were broken due to this commit. Let's
merge this once all the other commits pertaining to that fix can be
merged as well.
Fixes: OS#3942
Change-Id: I01d93778fb19c601c21f99ec4d2a3ab8a4a48f67
This variable does not seem to be used anywere in OsmoBSC, seems to be a
remnant from OpenBSC times.
Change-Id: I5e4aa352fa5f16f6ff64738f25afd1a844fa4fcb
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.
Change-Id: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff
During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the
Handover Request message. Actually parse this Chosen Encryption Algorithm IE.
Place the chosen algorithm and the CK into lchan_activate_info->encr so that
the new lchan will use the same ciphering on this new BSS as it did on the old
BSS.
Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
For intra-BSC handover, the previous encryption is copied from the old lchan,
which of course is not available during inter-BSC handover. Hence the lchan
activation info needs to include an explicit encryption information, and we
must not rely on the presence of the previous lchan to copy encryption
information from.
Add struct lchan_activate_info.encr to allow passing encryption info through
lchan_activate() without requiring a previous struct gsm_lchan to be present.
Instead of copying from the old lchan, always copy encryption info to
lchan_activate_info, and during activation, just before sending the Channel
Activation, copy the lchan_activate_info.encr to the new lchan.
This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which
obtains the encryption information from an intra-BSC-incoming Handover Request
message.
Related: OS#3842
Related: I5b269f50bd2092516bfdf87746196983d3ac49d1
Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
Instead of counting digits and slashes of the IPA Unit ID manually,
use POSIX regex functions, so the code is easier to maintain and
read. As a bonus, this fixes CID#188854: variable 'remain_slash'
was of type 'uint8_t', so it could never be lower than zero.
Change-Id: Id613bf650833dd38eaad08fdfffdf8dbe2f002b1
Related: CID#188854 Unsigned integer overflow
The 'return' that makes Coverity angry can be safely replaced by 'break'.
Change-Id: Ib3d7519421319fb0e6d65441bba123b7b01f4556
Fixes: CID#188873 Identical code for different branches
Fixes: CID#188850 Identical code for different branches
Fixes: CID#188845 Identical code for different branches
We don't need to know position of matches: just yes or no.
This change would save some computation power.
Change-Id: Ia8414bf83d030adfae806c0aeaa757bc4c8cda2b
At the moment the length field of the bssmap header is not parsed.
Instead the length is computed out of the known header length and the
number of bytes received. This is prone to error, lets make sure that
extranous data at the end of a message is ignored by parsing the bssmap
length correctly.
Change-Id: Idef2e783d2377a2ad1f697ea4d26491a32b3e549
Related: OS#3806
With the FORGET_MGW_ENDPOINT event, the MGW endpoint FSM notifies the gscon
that it has deallocated and that hence the gscon should forget all references
to it (to avoid a use-after-free).
Also do this for the endpoint FSM and endpoint ci pointers in the conn->ho.*
sub struct.
I saw a use-after-free after a Handover Failure message tears down the lchan
and MGW endpoint before triggering the handover_fsm.c cleanup code, which also
tries to clean up an endpoint CI if it was created for the failed Handover.
Change-Id: I6702ccd0df44bea5eb8b26d471d7903c24e6e30b
The symbol GSM0808_SC_CFG_AMR_4_75_5_90_7_40_12_20 is used in
lchan_fsm.c, but gsm_08_08.h, where the symbol is declared is not
included.
Change-Id: I46f910b3e0f2c7d8c78c1681acef30b9419e39f0
MGCP/SDP provides fmtp parameters in order to signal which of the two
available AMR framing modes (octet-aligned or bandwith-efficient) should
be used on the link between BSS and core network. osmo-bsc currently
does not set up this mode which means that the RTP packets from the BTS
are forwared without inspection/modification, which may lead to
malfunction when a BTS is using a framing mode that is not supported by
the other end.
- Add VTY option to setup the framing mode
- Generate related fmtp parameters in SDP
Depends: osmo-mgw I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
Change-Id: If6d40b2407b87aad2227ea7f15533ef01a3771b3
Related OS#3807
Before this patch, all OML GET ATTRIBUTES messages were encoded with
an erroneous OML header length value. The length value was always three
bytes less than the actual message length. This patch fixes the
problem.
Change-Id: I56068de0bb14a99ec39be587e542e27cddb7d1df
Closes: OS#3799
When "Config-NB-Code = 1" is set via the S-bits, then the resulting
multirate configuration IE will contain 12.2K. Since the generator
function is not aware if the lchan is activated for HR or FR it sets the
flag for 12.2k always.
We have to add a check here in order to set the 12.2k flag in the IE
back to 0 so that the active set contains a set of useable rates.
Change-Id: I40e7f568f4822040a2d1e78f22dbba0e49d0167e
Related: SYS#4470
When gsm48_mr_cfg_from_gsm0808_sc_cfg() is used to generate the AMR
multirate configuration IE, make sure that lchan allocation fails in
cases where the multirate configuration IE can not be generated.
Change-Id: Icd3e5674b10b8ae223c0d13ae33fc9ae7e8a8a18
Depends: libosmocore I6fd7f4073b84093742c322752f2fd878d1071e15
Related: SYS#4470
When match_codec_pref() is called and the codec selections from the
ASSIGNMENT COMMAND are matched against the interal capabilities, the
configurations are checked one by one. When a match is found that match
is returned.
However, the implementation currently does not check the AMR S15-S0 bits
when the actual matching happens. This is done afterwards in case AMR
gets picked. Unfortunately if the MSC implementation is not obeying the
settings the MSC has previously communicated in the L3 COMPL message we
may end up with an S15-S0 configuration that has all rate selection
(which eventually end up as active set in RSL) bits set to zero. This is
an invalid configuration and should be prevented. Also the handling of
the S15-S0 bits should happen as part of the matching so that there is a
chance to try the nect codec in the list if AMR is unuseable.
Also S15-S0 has one special setting "Config-NB-Code = 1" (S1 = 1). When
this bit is set, the four (in HR only three) most common rates are
selected into the active set. If there are also other S-bits set besides
S1 we should prefer S1 and discard the other bits.
- Perform handling of S15-S0 while matching
- If S1 is set, prefer this setting and discard all other settings
Change-Id: Ie52376b51fe07ed07056e8df2e9557293ff67a78
Related: SYS#4470
The current configuration for permitted AMR rates on BTS level has been
choosen arbitrarily. Lets choose the possible rates so that they match the
"Config-NB-Code = 1" as defined in 3GPP TS 28.062 Table 7.11.3.1.3-2.
(The current default behavior is not changed since the MSC level
configuration only permits 5.90k by default.)
Change-Id: I916953e3fdb54168671dd13b359e78662fa31059
Related: SYS#4470
This commit breaks voice channel assignment. It results in the
Assignment Complete sent to the MSC for a voice lchan lacking
AoIP Transport Layer Address, Speech Version and Speech Codec.
Hence the MSC cannot complete the Assignment for a voice call.
Let's revisit this patch, test thoroughly and re-merge later.
This reverts commit 4d3a21269b.
Reason for revert: <INSERT REASONING HERE>
Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
This commit aims at better ordering of content in order to get rid of
sigtran stuff in gsm_data. This way we can avoid requiring
libosmo-sigtran when building ipaccess utils.
Change-Id: I8941f059d6e4eb21a971d48d2b66c29ec3355a6d
To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When a new lchan is selected during handover, some of the properties of
the old lchan are inherited by the new lchan. At the moment S15-S0 is
not not inherited so that the value for those bits will always be 0x0000
for the new lchan. Since those bits also define the active set AMR codec
the channel activation will fail because 0x0000 is invalid (active set
with zero rates)
Change-Id: Ifd470397e99985394634da1bb13ccfc5041984d2
Related: OS#3503
When the ASSIGNMENT COMPLETE message is composed,
lchan->ch_mode_rate.s15_s0 is used to fill in the S15-S0 which are
returned to the MSC. This is not correct since the assignment process
may involve multiple lchans, so that at the point where the ASSIGNMENT
COMPLETE is generate, the stored S15-S0 may be lost already because the
lchan has changed. To prevent this, we must use
lchan->activate.info.s15_s0, which is retained throught lchan changes.
Change-Id: I9a7b3ce8646d641569eac24e202f44cdb5f67b3d
Related: OS#3503
When the MSC allocates a channel through the ASSIGNMENT REQUEST, it may
ask for a TCH/H and a TCH/F at the same time and tell which of the two
types it prefers.
The process of channel allocation currently selects, based on the BTS,
MSC and MS capabilites exactly one apropriate codec/rate (e.g. TCH/H)
and then tries to allocate it. If that allocation fails, there is no way
to try the second choice and the assignment fails.
For example: The MSC asks for TCH/F and TCH/H, prefering TCH/F, then the
channel allocator will try TCH/F and if it fails (all TCH/F are
currently in use), then TCH/H is never tried.
Since the BSC currently only trys the first best codec/rate that is
supported it also ignores the preference.
Lets fix those problems by including the preference information and both
possible codec/rate settings into the channel allocation decision.
Change-Id: I5239e05c1cfbcb8af28f43373a58fa6c2d216c51
Related: OS#3503
In some test and debug situations it is useful to have the ability to
lock certain lchans in a way that the BSC can not allocate them. One
application might be to simulate an exhaustion of all TCH/H channels in
order to force the BSC to take one of the available TCH/F.
Lets add a command to the vty which alloes us sen lchans from
LCHAN_ST_UNUSED
to LCHAN_ST_BORKEN and vice versa.
Change-Id: I397e68e26d6a1727890353fa34f4897b54795866
Related: OS#3503
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current
lchan's AMR configuration. However, conn->assignment.* values are only valid
during an ongoing assignment. Those values may be overwritten by any failed
Assignment attempt, at any time, and hence do not reflect the currently
assigned conn->lchan. Those realms must be kept separate.
The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most
sense to store these values in struct gsm_lchan once the lchan activation
succeeded.
Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during
lchan_activate().
In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*.
Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE,
it lets us know that the to-be-released connection related to a CSFB
call.
We as the BSC then subsequently should include the "Cell Selection
Indicator after release of all TCH and SDCCH" IE in the RR RELEASE
message sent to the MS/UE. This IE contains the LTE neighbor cells
that we're configured to broadcast in si2quater.
That in turn will make sure the MS/UE can return very quickly to
the LTE cell.
Closes: OS#3777
Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646
Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07
Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
We meanwhile have chapters about the CTRL interface protocol as well
as the auto-generated list of CTRL interface commands/values, so
let's remove the somewhat redundant information.
Change-Id: I062d7eec3b3fc53c31726be3b3a407a2dd3b8b56
We still haven't re-introduced support for E1 based BTSs, so let's
remove the relevant chapters from the manuals. Also, make sure
we don't call anything OsmoNITB in this manual anymore.
Change-Id: I834d65836731958b6be823a18e35407183398715
It makes a lot of sense to first describe the VTY interface before
going on using it to configure something. Also, configuration related
topics relevant to operators/sysadmins should precede other content
only relevant to developers, like the details of the CTRL or Abis/IP
protocol.
Change-Id: I0872d072bbb06f9409a72b93133d136167f03b38
This adds some instructions on how to configure 3G/4G neighbor
cells within osmo-bsc. I didn't want to add a new top-level
chapter but instead chose to add it to the handover section which
describes also the configuration of 2G neighbors.
Change-Id: I81df1a453858b6fca80c8adf234b1d5b8bf5283d
In GSM specs, the entire interface between two elements is designated
with some letter, like the A interface between BSC and MSC. The
interface uses a variety of protocols stacked on each other.
In the specific case of A, there is no "A" on top of SCCP, but
there's "BSSAP" on top of SCCP.
This is followed somewhat un-orthodox by 3GPP, as "A over IP" is
a violation of that principle. It should have been called "A utilizing
IP", "A based on IP", "A with IP" or something the like.
In any case, at no point do the specs ever claim that "A" is stacked
on top of SCCP, so let's fix this.
Change-Id: Ieb0d8f6c71debe1234aff343a994c2096326da1b
Currently the VTY only displays the lchans that are currently in use
(show lchan summary). In some situations (debugging) it can be useful
to list all lchans, regardless of their state. So lets add a command
for that.
Change-Id: Ie4d763476905fa8f84b4d7cdad4cc7dd879f84a5
Related: OS#3503
* use gsm0808_create_ass_compl2() to add BSS Status IE to Assignment
Complete message
* drop local helpers
Depends-on: (libosmocore) I547c6b8707123aa8c1ef636db88908df112d90a4
Change-Id: I6916928391667cd9c345becf00e7c8561846c295
Related: OS#2487
On rsl_rx_chan_rqd(), so far osmo-bsc tried to preferably assign the lchan type
that was asked for in the RACH. Firstly, this contained a bug, and secondly,
it does not make sense to heed that preference, since we do late assignment.
Ignore the preference for the MS' TCH kind.
We do late assignment to avoid codec mismatches. In the "old days", we would
heed the MS' TCH channel kind, even if the MSC or BSC didn't actually allow
or prefer that channel kind. Hence, in the presence of both TCH/F and TCH/H,
the MS could ask for TCH/F (which we would grant on the MO side) and the BSC
or MSC could prefer TCH/H (which we would apply on the MT side), and hence
fabricate a codec mismatch. Instead, since quite some time now, we *always*
assign an SDCCH first, and only later on do another Assignment to hand out
a proper voice lchan that heeds the MS capability bits as well as MSC's and
BSC's preferences.
By completely ignoring the channel kind the MS asked for in the RACH, we
also eliminate this bug in rsl_rx_chan_rqd():
- If the first "lchan_select_by_type(GSM_LCHAN_SDDCH)" fails (all SDDCH in use),
we should try to fall back to any TCH instead, to serve as SDCCH.
- the first "if (!lchan && lctype != GSM_LCHAN_SDCCH)" was an attempt to prefer
a fallback to the lchan type the MS requested.
- the remaining two "if (!lchan && lctype == GSM_LCHAN_SDCCH)" were obviously
only applied if the MS asked for an SDCCH, and skipped if the type was TCH/*.
- hence, missing was: if the MS asked for a TCH, to also try the *other* TCH
kind that the MS did not ask for. (Example: all SDCCH in use, MS asks for
TCH/F, but BSC has only TCH/H lchans; we should assign TCH/H as SDCCH, instead
we said "no resources")
Change-Id: Ie3684cf071751f9528183d761c588102936e498c
Related: OS#3503
The function lchan_select_by_type() will unsolicitedly select a TCH/F
when it is asked for a TCH/H but a TCH/H is not available. This behavior
is presumably a leftover from before the split. Now every fallback to
another rate must be agreed with the MSC in advance, it is a spec
violation to silently fallback to TCH/F when asked for a TCH/H.
Change-Id: I057e70bc81b3dac470f6d1d2a37533ec3a7a79d0
Related: OS#3503
The function lchan_select_by_chan_mode() is prone to select an half rate
lchan when EFR is used, even though EFR is not defined for half-rate.
Lets protect against that.
Change-Id: I961d9aaba81424053ab1dc04ce7799e716af4cd8
Related: OS#3503
The function lchan_alloc() does not exist anymore, however there is
still a prototype definition in chan_alloc.h and a comment in
abis_rsl.c. Lets remove those.
Change-Id: I36227ea306d28587ac70acbe596c7756b23d88c7
Previously LCHAN_RTP_EV_IPACC_MDCX_ACK was not permitted for
LCHAN_RTP_ST_ESTABLISHED state in lchan FSM. However this message is
normal in case of LCLS loop closed via IPA (as opposed to MGCP). Let's
permit this message and log it to make debug output easier to read.
Change-Id: Ib642df799f3405c4d707eb57b2ebc84386d7f03f
Related: OS#2487
In theroy the function T_def_get_entry() may return a nullpointer. In
this case we would run straight into a nullpointer dereference problem.
However, the requested timer is statically defined and should always be
there. However Coverity still reports this as a problem. Lets put an
OSMO_ASSERT to make clear that there is no problem here.
Fixes: CID#190403
Change-Id: If5238132d9d5a1507b9955a0b2dc4b1bced220e8
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
After this, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint.
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw)
Change-Id: I492023e9dca0233ec0a077032455d9f2e3880f78
There could multiple reason for OML or RSL link towards BTS to be
dropped: ctrl command, vty, new link etc. Introduce "reason" parameter
to corresponding functions and log it on link drop to simplify
troubleshooting issues with more complex setups.
Change-Id: I8c8d8132ba67c31e40dbecdfe2e09be08c744899
Fix crash after AMR configuration fails.
The crash is due to an assertion that finds a non-NULL conn in the lchan, when
re-using an lchan that has failed in AMR configuration earlier on. That is
because the AMR config still happens in state UNUSED.
DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED
...
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324)
Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491
The FSM design idea is that when returning to the UNUSED state, all lchan state
is cleared. However, when calling lchan_activate(), a failure may happen still
in state UNUSED, so that we don't transition *back* to UNUSED properly.
So, first transition out of UNUSED before failures can happen. (Other ways to
solve this would be to invoke lchan clearing even if already in UNUSED, but
semantically, transitioning first makes more sense.)
Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to
WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to
UNUSED and clear the lchan.
Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter().
Also, there is a bit of duplication of members of the lchan->activate (lchan
state) and the lchan_activate_info (passed to lchan_activate()) structs. The
fix for this also removes the dup:
Add struct lchan_activate_info as child struct at lchan->activate.info, drop
the other lchan->activate members that would dup .info.*. Move struct
lchan_activate_info declaration to gsm_data.h.
Apply the new '.info' member struct throughout the code.
Related: OS#3737
Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
* use osmo_lcls struct from libosmocore
* use enum values instead of magic numbers
Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858
Related: OS#3659
According to 3GPP TS 08.58 §8.5.1 BCCH INFORMATION:
"If the Full BCCH information element is not included this indicates that
transmission of the indicated SYSTEM INFORMATION message shall be stopped."
However, some ipaccess nanoBTS firmware versions are known to not support
some SI elements and also to dislike receiving BCCH Information for those SI,
even if received with empty BCCH Information meaning they should not be used.
Upon receival of this kind of message, nanoBTS sends a Failure Report
with following text:
Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149
****
** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (325).
****
This kind of issue only appears with some fw versions, since it's known
to work fine in other ones, so let's not disable this kind of mesage by
default on all BTs of type "nanobts".
Instead, add a VTY command that allows disabling this kind of message in
order to be able to operate those nanoBTS units.
Fixes: OS#3707
Change-Id: Idec1daabc21de4eea5c55edd1dbb0e0775720fc7
Since we actually want to match by IMSI as specified by filter in VTY.
It will allow to match based on other information later.
Change-Id: Ia73fd2f38e42396db8f6d2cc6b2c163aa8f67f3f
Limiting the logging filter only to IMSIs that we have as local
subscriber doesn't make sense for osmo-bsc since all subscribers are
initially unknown.
Create a bsc subscriber and enable logging there. This struct will then
be used and liked to the gsm_subscr_conn when receiving the Location
update.
Related: OS#3641
Change-Id: Ia20bdc15565417020205d7b2b06b04a01c03106c
Currently, we see all subscribers' FSM transitions on NOTICE level even though
the code uses LOGPFSML(LOGL_DEBUG), because LOGPFSML() uses the max loglevel of
the passed level and the FSM instance's level. Too noisy!
By default, start out all gscon FSM instances on DEBUG level, so it is possible
to silence the osmo-bsc log. Individual instances can still be lifted (I
presume using the CTRL interface?).
Change-Id: Ie021483e93ab174abac51357bcca8895756566c4
When an internal handover is done the specification demands to inform
the MSC about the event.
- Add sending of BSSMAP HANDOVER PERFORMED msg.
Change-Id: If26e5807280e0f75a423b3b04f8e3c698c82a351
Depends: libosmocore I825106858bd89afc9837811b8fed2e8accc82441
Related: OS#3645
The current idea of calling gscon_release_lchans is not enough because
the conn is still present.
Insetad pretend we got a disconnect indication from the MSC which will
call gscon_release_lchans as well as terminate the conn state machine
which will clean up conn state as well.
Related: OS#3680
Change-Id: Iccf5f6864ffe238189907c4bb3ea333948621b4c
The idea is to have a base static value which is set like before "timer
t3113 [seconds]", but now have a part of this timeout calculated
dynamically based on BTS channel configuration and channel load.
This patch only implements initial support to calculate based on channel
configuration, but doesn't include code to calculate based on channel
load. To implement the later part, we probably need to keep track of BTS
paging queues per paging group, which we don't do nowadays.
Dynamic calculation is enabled by default, and default static base value
is decreased accordingly. This way, in a typical setup were the default
10 seconds were used, now the calculated final value is 11 seconds.
That's intended because it was observed experimentally in osmo-gsm-tester with
a similar channel setup that sometimes paging response can arrive slightly
later than 10 seconds.
Related: OS#3680
Change-Id: I4fb2969b690151415038631fb6ad059aa6835c7f
When we enter WAIT_RLL_RTP_RELEASED
(lchan_fsm_wait_rll_rtp_released_onenter), we call lchan_do_release()
which in turn dispatches LCHAN_RTP_EV_RELEASE to lchan_rtp_fsm.c, which
will dispatch back an LCHAN_EV_RTP_RELEASED event, which will be handled
by lchan_fsm_wait_rll_rtp_released(), which will change state to
WAIT_BEFORE_RF_RELEASE. When going back the stack (return), we are still
in lchan_fsm_wait_rll_rtp_released_onenter() which again triggers a
change state to WAIT_BEFORE_RF_RELEASE because it checks same conditions
than first one.
20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1388 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: lchan detaches from conn SUBSCR_CONN(conn3)[0x612000002da0]
20181128203727051 DMSC osmo-bsc/lchan_fsm.c:1391 SUBSCR_CONN(conn3)[0x612000002da0]{CLEARING}: lchan lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] detaches from conn
20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1359 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: state_chg to WAIT_RLL_RTP_RELEASED
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:959 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) SAPI[0] = 1
20181128203727052 DRR osmo-bsc/gsm_04_08_rr.c:254 Sending Channel Release: Chan: Number: 0 Type: 2
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:945 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Received Event LCHAN_RTP_EV_RELEASE
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Freeing instance
20181128203727052 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Deallocated
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: Received Event LCHAN_EV_RTP_RELEASED
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:856 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) Still active SAPIs: 0
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:1011 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: state_chg to WAIT_BEFORE_RF_RELEASE
20181128203727052 DRSL osmo-bsc/abis_rsl.c:633 (bts=0,trx=0,ts=6,ss=0) DEACTivate SACCH CMD
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:986 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_BEFORE_RF_RELEASE}: transition to state WAIT_BEFORE_RF_RELEASE not permitted!
Change-Id: I5d95bbd8244cc8e9c1cfb6fe0f76148332386a3d
lchan sends TS_EV_LCHAN_UNUSED to its parent (ts) during release time. It
was experimentally found that it can happen that an lchan can be terminated
while waiting for a PDCH DEACT (N)ACK response.
The fsm definition actually states that this event can be received in
state TS_ST_WAIT_PDCH_DEACT, but it was not handled before and as a result the
process aborted due to the default switch case.
Change-Id: If61493e7d5449bf2c2de9fd34cdf2410625e92ac
When lchan_rtp_fsm instance is allcoated with
osmo_fsm_inst_alloc_child(..., LCHAN_EV_RTP_RELEASED) we already let fsm
code to take care of sending that event ito the parent when the fsm is
terminated (but only if freeing cause is not OSMO_FSM_TERM_PARENT).
The lchan_rtp_fsm cleanup() callback, which is called immediatelly before
sending to the parent the event defined during osmo_gsm_install_alloc_child(),
currently also sends that same event, which ends up in a duplicated
event being sent as shown in log files below.
Let's only send the event in cleanup() if we are in the
cause=OSMO_FSM_TERM_PARENT scenario, to make sure parent always receives the
event, but only once.
20181128193707326 DAS osmo-bsc/assignment_fsm.c:127 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=6,ss=0) Assignment failed
20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Terminating (cause = OSMO_FSM_TERM_ERROR)
20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Removing from parent SUBSCR_CONN(conn4)[0x612000002920]
20181128193707326 DCHAN osmo-bsc/lchan_fsm.c:1333 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Received Event LCHAN_RTP_EV_ROLLBACK
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST)
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]
20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:441 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: notify=NULL
20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:482 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: Scheduling
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:742 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Freeing instance
20181128193707327 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Deallocated
20181128193707327 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED
20181128193707330 DCHAN osmo-bsc/lchan_fsm.c:1347 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: transition to state WAIT_RLL_RTP_RELEASED not permitted!
20181128193707330 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Freeing instance
20181128193707330 DAS fsm.c:381 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Deallocated
Change-Id: I3e95a21e5a5ec6c35b1ab20b7a642fd7eb81e556
Before this patch, TCH lchans waiting for dynamic TS to
switch PDCH->TCH wouldn't be counted.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: I32008859cc23cd2afddd79daae21497d0945fed0
If TS is in state changing from PDCH->TCH, the TCH lchan provoking the
switch would be skipped and not terminated before this patch.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: I9dc2a6e5b15376d049bd2ac5ddfa24340771b5c8
If ts_is_lchan_waiting_for_pchan() wasn't accounting for TCH lchans
waiting for TS to deactive PDCH in order to setup the TS as TCH.
Since now TCH lchan is catched by ts_is_lchan_waiting_for_pchan() when
TS state is TS_ST_WAIT_PDCH_DEACT, there's no need to check for that
case in caller ts_is_pchan_switching(), since it will never hit because
the callee returns true in that case now.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: Ib03e5a91438a5b74a04e69f81fab565842b02b66
Documentation of the function explicitly states that the out
target_pchan param returns the "PCHAN waited for". If we return false,
then no PCHAN is being waited for. The 2 callers of this function only
use this out param if function returns true, so let's simplify the code.
Change-Id: Ib8f9b7e1f584dee885d6823dc043682577572bd8
In general PDCH channels are not handled as lchans in BSC (lchan_fsm.c),
and so when a TS is in ts->pchan_is=GSM_PCHAN_PDCH, no lchan slot is
being used.
However, during Dynamic TS PDCH Deactivation being in progress (state
WAIT_PDCH_DEACT in timeslot_fsm.c), ts->pchan_is =GSM_PCHAN_PDCH, but
an lchan slot of that TS is actually already being used by a TCH lchan:
it's the one who initiated the deactivate in order to be able to use the TS.
While being in WAIT_PDCH_DEACT state and receiving a PDCH DEACT NACK,
ts_fsm_error() was called in order to kill the TS and it was expected
that it would kill any lchan using it (or willing to start using it). In
order to do that, it calls ts_lchans_dispatch() which in turns iterates
over all lchans attached to the TS using ts_for_each_lchan().
However, when the NACK arrived we still had ts->pchan_is=GSM_PCHAN_PDCH,
ts_for_each_lchan ends up calling
ts_as_pchan_for_each_lchan(GSM_PCHAN_PDCH), which in turns calls
pchan_subslots(GSM_PCHAN_PDCH) which returns 0, because we don't manage
lchans in that mode as explained in first paragraph. This means in this
case ts_for_each_lchan() is actually an empty loop while still any of
the TCH channels may be in use, and won't be advertised about the TS
entering in a broken state.
As a result, the lchan won't be released for a while, only after T23001
expires.
Related: OS#3708
Change-Id: I9cedb77d6578597f1febab36c54b2ee427c7a4a2
It will be used further in follow-up patches. It also provides a place
to document its (intricate) logic around it and its possible uses.
Change-Id: Ia1d4bdbfca6b9719f54ee609b6bfadf7f3a4bb43
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: Ief6ce94013612a968183e82abef421f116ed37c3
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: I38bd2bffa24c5b970aa4a42dcfc8d8766bb96046
Every DTAP message coming from the MSC has a header (see struct
dtap_header) that contains message type, length, and link ID.
The link ID indicates SAPI and channel type of a given message.
In dtap_rcvmsg() we allocate a new message buffer and copy the
received message into it. The old message buffer is freed by
the caller then.
The link ID value parsed from DTAP header is usually being stored
in the control buffer of a message buffer (i.e. msgb->cb). Due to
a mistake, it was stored in the old (to be freed) message, while
the new (to be forwarded) message always had link_id = 0x00!
This change resolves the problem with sending SMS during a voice
call, when MT signalling goes through FACCH, while MO signalling
goes through SACCH.
Change-Id: I7675e1ce4436fad836778261ac9d446fa8f81483
Related: OS#3716
follow-up to I9ad094d272254d7aee9b0a676201d4ed8cd727ca because it was merged
before fixeria's code review could be incorporated.
Change-Id: I474cf1a58d1f00ec5b0ae52bd095a60aad763975
If BTS is configured to have only TCH/F_PDCH and TCH/H and a call is
resolved to require TCH/F, don't return the TCH/H which have no use, but
instead let it allocate the TCH/F_PDCH.
20181128185013783 DRLL <0000> lchan_select.c:159 (bts=0) lchan_select_by_type(TCH_F)
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=3,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=4,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=5,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=6,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=7,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/H
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/H
20181128185013784 DRLL <0000> lchan_select.c:86 looking for lchan TCH/H: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) ss=0 is available
20181128185013784 DCHAN <0010> lchan_select.c:253 lchan(0-0-2-TCH_H-0)[0x6120000066a0]{UNUSED}: (type=TCH_H) Selected
Change-Id: I9a73beb0432fab16d5430e5b40d470694e09b189
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in local the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I92c0f771d4ffc2b0401d26e25cb0b3817e6f95ea
Includes from other projects don't work anymore when moving project
specific manuals into other repositories.
Related: OS#3385
Change-Id: I96933dd4dd6cac159847647f1c642215051a9aad
Re-generate bsc_vty_reference.xml from osmo-bsc, including updates to:
- handover and neighbor config
- SCCP timers
- logging
Change-Id: Ia9ba8d5eba531b1156de57573ab42517e0c1ca15
Add chapter "Handover", explaining:
- intra- and
- inter-BSC handover,
- HO algorithm 1 and
- algorithm 2
- new neighbor configuration
Adjust copyright, add revision and add me as author.
Change-Id: I7afb3f66c98abda07fc8acc76e00c46091fe55e2
This is the first update since the libosmocore changes to the 'show
online-help' generated output. Hence the produced document now benefits from
the structural improvements:
- not repeating common commands for every node;
- using section names that match the VTY prompt.
Update bsc_vty_additions.xml to match the new node ID scheme.
Change-Id: I0d856563eee88527fda4c6940aa6cea779175aaa
The initial goal was to make sure we don't have overall FORCE rules causing
unnecessary rebuilds -- annoying while writing documentation. As I looked
through possible dependencies, I finally understood what's going on here.
Remove code dup and nicely sort which belongs where in build/Makefile.*.inc. In
each, describe in a top comment how to use it, and also unify how they are
used:
- Rename Makefile.inc to Makefile.docbook.inc and refactor
- Add Makefile.vty-reference.inc
- Add Makefile.common.inc
Make sure that we accurately pick up all dependencies.
Drop use of the macro called 'command', that silenced the actual command lines
invoked and replaced them with short strings: it obscures what is actually
going on and makes the Makefiles hard to read and understand.
Each manual's makefile is greatly reduced to few definitions and a Makefile
include, e.g. one for asciidoc, one for VTY reference.
Move common/bsc_vty_additions.xml to OsmoBSC/vty/libbsc_vty_additions.xml, link
from OsmoNITB. It applies only to OsmoBSC and OsmoNITB.
Add a script that combines a VTY reference file with *all* additions files
found in a manual's vty/ dir. Call this from Makefile.vty-reference.inc.
Change-Id: I9758e04162a480e28c7dc83475b514cf7fd25ec0
All parts referencing GFDL can be easily disabled by removing the
'gfdl-enabled' attribute from the document.
Change-Id: I2489726ad2e90301bceadfada926e31ae0f85986
According to RFC3435, an RTP bridge forrwarding packets, transcoding
or otherwise, is a single endpoint with two connections. Let's treat
it as such. We introduce the "rtpbridge/" prefix to identify such
special RTP endpoints.
Change-Id: Id1f079307225faf05d298dcb12aa1c421bfa680a
Unfortunately a glob like osmo-x__*.{svg,png} doesn't work, so have the
suffixes in separate globs.
Add dashes to indicate that failure should be ignored.
Change-Id: I6bc4d9ea72b43a573acbc860c23397f748de2c7b
Generate *.check files from asciidoc output and grep for WARNINGs.
Add *.check files to gitignore and to 'make clean'.
Change-Id: Ibccc83a3415930a528f2e8e4e4dda3b81c6d0b64
The manuals existed in different form for several years in an internal
sysmocom repository. However, since they had just recently been
converted from docboox-xml to asciidoc and all files have been
re-shuffled for enabling the public release, there's not much point in
keeping the history with git-filter-branch.
Set flag lchan->activate.immediate_assignment_sent to true when sending, and
omit a reject after that.
lchan->activate gets completely zeroed in lchan_reset(), which sets that flag
back to false whenever an lchan becomes inactive.
Related: OS#3709
Change-Id: I9ad094d272254d7aee9b0a676201d4ed8cd727ca
Add following commands showing only TRX with appropriate RSL link
status:
* show trx connected
* show trx disconnected
This simplifies troubleshooting of complex setup with multiple BTS with
several TRX each.
Change-Id: I48866ce311a3e2c63235f60a497efe97bbd05a4a
This way only formated output is pinted to stdout when using -G and can
be used by other tools (osmo-gsm-tester) to get a json dictionary with interesting
information.
Related: OS#3624
Change-Id: I257bfc8d82b49a3641be6b6777e472ecf561a21e
Add LCLS variant where the loop is closed on BTS level instead of
MGW. The main difference is the handling of connection-related
messages (we use IPA RSL instead of MGCP), the configuration and
correlation logic remains the same.
Change-Id: I7e8379f31037f2c48da69a01919701919a3066a2
Related: OS#3659
In preparation for upcoming LCLS changes we have to split IPA RSL MDCX
generation into separate function with the ability to set destination
explicitly instead of just using the value from lchan which will be used
in follow-up patches.
Change-Id: Iffe2f4f10e841fc36965cce02b4e5f017a5ae6c8
Related: OS#3659
Same type of message parsing is already implemented in code, no need to
keep them.
Related: OS#3624
Change-Id: I715bd9582f9289b5674aaa8d8de1164ebef2fd11
This signal can be used for tools willing to request and parse Attribute Response
and do something with the information. ipaccess-config tool will use
this signal in later patch Change-Id Ida416a969a3309868d6f4e50f34b34f224c32dd6.
Related: OS#3624
Change-Id: I9a121bbfe1b96904d4e16845abc90bb6ef20d2c9
Before libosmocore Change-Id I780d452dcebce385469e32ef2fd844df6033393a,
it avoids stating arfcn 886-954 are compatible when operating under
DC1800. After that Change-Id, avoids aborting the program due to
unexpected behaviour.
Related: OS#3063
Depends: libosmocore Change-Id I780d452dcebce385469e32ef2fd844df6033393a
Change-Id: Ibf5d5ab50b6fc6597244eeedcd27d2ce245278a3
Some nanoBTS firmwares (if not all) are known to not work properly with
SI2ter. If BSC enables SI2ter through RSL, SI3 bit announcing SI2ter
available will be forwarded by nanoBTS to MS, but will still only send
SI2 message instead of expected SI2ter during TC=5 (see GSM 05.02 sec 6.3.4 "Mapping
of BCCH data"). As a result, some MS won't allow registering to the
network.
To avoid this kind of scenario, enable force-combined-si by default on
nanoBTS while still allowing to overwrite the feature through VTY. Other
BTS models are kept with force-combined-si disabled by default as
usually, since they seems to be working fine when SI2ter is enabled.
Related: OS#3063
Change-Id: Ide6e8967de0eedc9e2bcaf4414aaa537b009d72d
3GPP TS 04.08 V7.21.0, section "9.1.34 System information type 2ter"
states:
"""
This message has a L2 pseudo length of 18. This message may be sent
by the network with either a L2 pseudo length of 18 or some other
value. A mobile station that does not ignore this message shall not
discard the message due to a received L2 pseudo length different
from 18.
"""
Change-Id: I45cb217ebdf89b82b0f37f38eef7a1e3a651f541
3GPP TS 04.08 V7.21.0, section "9.1.33 System information type 2bis"
states: "This message has a L2 pseudo length of 21.".
Change-Id: I623c64c446c0973e939e9f1cba0a4d4d2f4f7237
In commit 65c62e5033 a call
to unlink() was erroneously moved up. Since then unlink()
has been called with an uninitialized path variable. The
problem went unnoticed because the return value of unlink()
was never checked.
Ensure that unlink() is called with an initialized argument and
verify success of the unlink() operation if the socket exists.
Related: CID#188836
Change-Id: Ia0c873da305cbb47aef0562f61ec21057363f294
Fixes: 65c62e5033
Before closing or breaking the loop in LCLS we do preliminary
checks. To facilitate adding new LCLS modes it's restructured as
follows:
* move check into dedicated static function
* explicitly check for MGW mode in endpoint check
* check for mode mismatch
Change-Id: I32ba232ad802625d97a0ad9d0511edc6ac7f251c
Related: OS#3659
Coverity points out that abis_nm_rcvmsg_sw() contains a switch
statement with suspicious looking missing break statements.
It is unclear to me if the code intends to process some
types of messages in more than one state, or of all messages
which affect a particular state already appear in the state's
corresponding switch block.
Can someone else tell what is supposed to happen here?
If this code is falling through intentionally, I will suggest
a patch adding /* fallthrough */ comments for clarity.
Change-Id: I1ea4221fadf30074156e9d17d94a5cb065242584
Related: CID#57703
Related: CID#57704
When a gscon wants to send a BSSMAP Clear Request, it makes no sense to do it
conditionally depending on the current conn state. Just send it: don't call
gscon_sigtran_send(), directly go for osmo_bsc_sigtran_send().
In particular, if an incoming inter-BSC handover ends in failure, the gscon
state is still ST_INIT, but if the MSC fails to give us a Clear Command, we may
want to ask with a BSSMAP Clear Request.
Change-Id: I39fae24260a4bb7a6af704ebe760f93fff566536
Otherwise any use of functions in gsm_timers_vty.c will fail because
g_vty_T_defs is never set (so it is NULL).
Change-Id: Ieeb27fdb06c965fa6b70aeb0f3b3f5169b1f2012
Check the return value of gsm48_multirate_config() in function
lchan_set_single_amr_mode(). This prevents an invalid AMR mode
from being configured for a logical channel.
Because the VTY parsier limits the AMR mode range to 0-7 this
is just a theoretical issue. However, this fact is beyond the
understanding of a static code analyzer, and the absence of
error handling was indeed setting a bad example.
Change-Id: I61153a44e8b7a38332bf38718397be9b339d5f25
Related: CID#188940
complete_layer3 returns true if everything succeeded, false otherwise.
However, its caller bsc_compl_l3 returns unix style (0 sucess,
negative error).
This commit has no real effect since only caller of bsc_compl_l3 never
checks return code, but will check it in the future.
Change-Id: I722696c3f6402288b51d6fcf51f478b3b0c9f0f0
In default example network, there's no cells with those arfcn.
Furthermore, having those seem to prevent some MS to register against
nanoBTS configured by a BSC using those lines.
Related: OS#3063
Change-Id: Iebe972da3a8442b6ded6d7f9e61a03b9144a843c
The 'show lchan' command already shows details about timeslot
state, indicating whether a channel is currently being switched
to a different channel type.
However, this information was not shown by 'show timeslot' yet.
There are TTCN3 BSC tests which use 'show timeslot' and are
seeing sporadic failures when 'show timeout' is invoked during a
channel type transition. With this change, VTY sessions recorded
in pcap files for these tests will contain information about the
current channel type transition state.
Change-Id: Ib854945756fb54c0e1c7d4212ea7b8746eec0db5
Related: OS#3690
conn->fi should actually never be NULL, they are allocated and discarded
simultaneously. So check its null from the start and remove some conditions
below, to remove the coverity warning.
Related: CID 189671
Change-Id: I62354aa998832131c86535f39a29294000114adc
Put all lchan release related flags and settings in a sub-struct named
'release' to better indicate what those fields are for. There is no functional
change.
Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sacch = false did so for no good reason.
Drop the do_deact_sacch flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sacch flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
In the case where there is a release in error and we skip immediately to the RF
Release state, send all of Deact SACCH, RR Release messages and also signal the
lchan_rtp_fsm as appropriate.
Move that code to static lchan_do_release() and call from both
lchan_fsm_wait_rll_rtp_released_onenter() in the normal case, as well as
lchan_release() when skipping that.
When releasing in error, but we're already in LCHAN_ST_WAIT_RLL_RTP_RELEASED,
those messages have already been sent and we can skip them.
Change-Id: I648a9826ce56b611359f81462ca03e4ab4c736aa
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b0
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
When reading the log of OS#3686, I wished for explicit logging of when exactly
an lchan disassociates from a conn. Here is the debug logging I would have
liked to see.
I'm not sure whether we really need to merge this patch...
Change-Id: I97558b899e7f2578ba98287e7352dc072d02ce44
lchan_fsm_wait_rf_release_ack_onenter() calls gscon_forget_lchan(). At the
point where the conn has no lchan, the lchan must not have a conn. Make sure
that conn is NULL after gscon_forget_lchan().
I hope this fixes OS#3686, it is the only situation I could find where the
disassociation is potentially one-sided.
I get the feeling that this should be hardcoded in gscon_forget_lchan(), but I
dimly remember other situations that are less trivial, where it doesn't
necessarily make sense to forget reciprocically. So only fixing this one now.
Related: OS#3686
Change-Id: If0c6e495e419b9dbb44443c3fc3f54dd4b714aa5
Right below this call, we invoke lchan_reset(), and the first thing it does is
gscon_forget_lchan(). Drop this redundant invocation.
Change-Id: I503efceb6d34c8df0cdfef3dfc83fa1e61271c47
See following specs for related information:
* 3GPP TS 52.021 §8.11.3 Get Attribute Response
* 3GPP TS 52.021 §9.4.64 Get Attribute Response Info
Related: OS#3624
Change-Id: Ie61d70bc28427d5d879638516a36f590ce98bdc7
Spec compliant format is defined in:
* 3GPP TS 52.021 §8.11.3 "Get Attribute Response"
* 3GPP TS 52.021 §9.4.64 "Get Attribute Response Info".
On nanoBTS, however, reported attribute list is provided directly inside/after
the foh header instead of being enveloped inside the Get Attributes Response Info.
Furthermore, The Get Attributes Response Info can still appear and be at any position
in the reported attribute list, and it only contains the unreported
attribute ID list inside.
Change-Id: I81a613d53bddf432a79fa5cb0bf9d847b4bdee37
nanoBTS actually supports regular formatting. There are a few differences
with spec though:
* The attributes are listed directly in the message instead of being inside
the Get Attributes Response Info after the unsupported attribute ID list.
* The Get Attributes Response Info can be at any position in the
attribute list, and it only contains the unsupported attribute ID list.
As a result, parsing is currently split into 3 main parts or functions:
* Parsing regular (per spec) Get Attributes Response Info attr and get a
pointer to the list of attributes.
* A function that parses the list of attributes, called directly in case
of nanoBTS, and called by the former parser of Get Attributes Response
Info for regular (per spec) OML endpoints.
* A function to parse the unsupported attribute ID list, also used in the
first function to get a pointer to the list of attributes.
Related: OS#3624
Change-Id: I52e9f177c14fec1ec3f5c4ddb244594409008357
* Allow sending Get Attributes message in abis_nm_get_attr.
* Don't try to decode Get Attribute Response Info for nanoBTS, since it
uses a different formatting than the one defined in specs.
Related: OS#3624
Change-Id: I53d01e73791cf5450aa34b1ac8f051730e3a70f9
nanoBTS uses same format for the attribute list from Attribute Response
Info, but without using the later as an evelope. By splitting we can
later reuse the code handling the Attribute list.
While at it, take the chance to remove functions parse_attr_resp_info_*
which expect TLVs following an specific order, which is not mandatory.
Related: OS#3624
Change-Id: Iec7a6e4d27639d0e5adc0d9a01cd3c3e7a46f558
In future commits, nanoBTS support will be added, which implements its
own format not exactly equal to specs Attribute Response Info.
Related: OS#3624
Change-Id: I346dacc58faac70e6d224ca49484f9211cb8a046
This function will be merged into another using a "len" variable. This
change makes diffs easier to follow in future patches.
Change-Id: I1be03e31901ccf284e31237a04bb7448d1f22c07
The function cgi_for_msc() provides an easy way to get a cell global id
for an msc/bts combination. This function is currently statically
defined in gsm_08_08.c. Lets move it to gsm_data.c and make it publicly
available.
Change-Id: I301fac6e83a429ae59b5c586aa283ad7ba54053d
Related: OS#3645
Coverity points out that conditional checks in set_net_timezone()
depend on each other: The value of 'override' depends on 'hourstr'
being non-NULL. Nest these conditional checks such that this
dependency becomes obvious.
No functional change.
Change-Id: I10dece1e1d9e039fb9f03be89b3a202cb077b026
Related: CID#148208
Move code using MDCX via MGCP into separate function to make adding
alternative MDCX variants easier.
Change-Id: I5fafa3b12a39c83bdf64e16e192dd2454d069cf4
Related: OS#3659
These indicators are a legacy of early handover_decision_2.c work, where there
were no separate handover1 and handover2 config commands. No need to restate
the abundantly obvious anymore.
Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
Print IDs and IPs of recently rejected BTS devices. Example output:
OsmoBSC> show rejected-bts
Date Site ID BTS ID IP
------------------- ------- ------ ---------------
2018-10-25 09:36:28 1234 0 192.168.1.37
Related: OS#2841
Change-Id: Iba3bfe8fc9432b7ae8f819df8bd71b35b3ec507e
The commit acd29192de
Change-Id Ifb9212fede2333ad68db94188b5cda4fcabe02f8
introduced a bad change to neighbor_ident.vty. Revert that bit.
Change-Id: I8b80be6daef73f5864ba9f294bf2134c8a76ddb5
The chan mode is figured out per-BTS, but may remain uninitialized. Rather log
info about the channel request, like further above.
Change-Id: I07b89b6101879fb7c070c87be9bd38cc05ffa0b1
Separate the cause value passed to further functions from the log string.
The code tried to be nice by composing the RSL cause string and returning the
RSL cause at the same time, which falls on its face when the string composition
happens only within conditional logging.
Change-Id: Ibadd06102f162bca9182c39b77b0651568d3e6f8
bssmap_handle_cipher_mode() had code paths doing "goto reject" without
setting a meaningful cause value.
Related: OS#3186
Change-Id: Ia608fa34a6a2d3035a66d05fbc38553ac5186804
During the generation of the multirate configuration IE in the channel
activation message that is sent over RSL, all AMR rates except the
highest one are trimmed. This was to ensure that the multirate
configuration IE only contains one codec rate per active set. Lets fix
that and generate a proper IE with threshold and hysteresis values.
- extend lchan_mr_config so that it can generate a full multirate
configuration IE
Change-Id: I7f9f8e8d9e2724cbe3ce2f3599bc0e5185fd8453
Related: OS#3529
The vty already has a well working interface to configure the AMR
mode, threshold and hysteresis parameters. However there are no checks
yet to prevent against misconfiguration.
- Use gsm48_multirate_config() to perform a global check of the overall
configuration
- Add check AMR modes during input (order, duplicates)
Change-Id: I8b9f69b89a39bbf4800d9790f7abe43ce66aeb71
Related: OS#3529
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.
- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL
Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
The function check_codec_pref() currently only does a basic check over
the general codec configuration of bts and msc. However, it does not yet
check if the amr codec rate settings for the BTSs contradict the
allowed/forbidden amr codec rates of the MSC. When the two settings do
contradict AMR would not work, even when everything else is correctly
configured. We need to check this on startup to spot configuration
problems quickly.
- Add function to calculate intersections of struct
gsm48_multi_rate_conf variables.
- Calculate the intersection between the multi rate config of
each BTS with the one of the MSC
Change-Id: I3537d1c89e2520d35cc0e150ba8e6d3693e06710
Related: OS#3529
The function gsm_bts_alloc() does set default values for the amr rates
for a newly allocated bts, but it does not populate the ms_mode and
bts_mode flags which contain hysteresis and threshold. Those values are
currently set to 0 by default, which does not make much sense. Lets
popluate some appropriate default values.
- Make sure that .mode .hysteresis and .threshold are populated for
MS and BTS in full and halfrate
Change-Id: If14843feeeea6584e5991d5c0abb765611dfaa57
Related: OS#3529
Implement basic support for inter-BSC HO from handover_decision_2: do inter-BSC
handover only when rxlev / rxqual / ta drop below the minimum requirements.
I considered adding a vty config flag to disable/enable remote-BSS handover,
but to avoid inter-BSC HO the user can simply refrain from configuring
neighbors for a particular cell.
In collect_assignment_candidate(), it is important to clear out any new
candidate entry. Hence adopt the same pattern as below: first compose a new
(cleared) candidate, then write the entry into the list.
Related: OS#3638
Change-Id: Id78ac1b2016998a2931a23d62ec7a3f37bb764c6
a) Prepare for triggering handover for any candidate, remote or local.
b) drop redundant arguments.
Change-Id: I5ba8b556703010c8e232b516285a837c999f87ef
When COMPLETE LAYER 3 INFORMATION is generated, it may include a speech
codec list that contains 0 elements (which is legal). The specification
requires the speech to be include if the network supports an IP based
user plane interface. It could be argumented that if no codecs are
available, the ip based user plane interface is not supported and
therefore the spec does not require the speech codec list IE to be
included for those cases. Lets check if the speech codec list has 0
elements and if its zero length, lets omit it completely.
- check for zero length speech codec list.
- omit speech codec list if it has zero elements
Change-Id: I07339322a71376e986a2d75b7bc1f552eafd02b5
Related: OS#3657
The COMPLETE LAYER 3 INFORMATION message contains a an Codec List (BSS
Supported). When generating the compl l3 info msg, we check if the
speech codec list that we have generated before has at least one
element. If it has 0 elements we abort immediately. However, speech
codec lists with 0 elements are permitted by the spec, so we should
remove the checks as there are corner cases where voice support is
intentionally unavailable.
- Remove check for zero length speech codec lists.
Change-Id: Id7332e5273ff0efb85043dd1e1bb804cfe2db944
Depends: libosmocore I1eb1f4466b98bdd26d765b0e4cc690b5e89e9dd6
Related: OS#3657
This quickly allows knowing which IP a BTS is using in order to SSH
into it. Example output:
OsmoBSC> show trx
...
Baseband Transceiver NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
ip.access stream ID: 0x00 (r=192.168.1.178:34090<->l=192.168.1.37:3003)
...
OsmoBSC> show bts
...
Paging: 0 pending requests, 50 free slots
OML Link: (r=192.168.1.178:57692<->l=192.168.1.37:3002)
OML Link state: connected 0 days 0 hours 0 min. 17 sec.
...
Related: OS#3145
Change-Id: I37f020fcdb68cafcdbdb621808483d1dd996354f
I believe I have initially misinterpreted the idea behind sending a Cell
Identifier List in BSSMAP Handover Required messages. Instead of associating N
Cell Identifiers with one ARFCN+BSIC, the idea is to add up N separate
ARFCN+BSIC's Cell Identifiers into a list. To keep the door open for future
code simplification, make sure to allow only one Cell Identifier per remote
ARFCN+BSIC on the VTY UI.
Related: OS#3656
Change-Id: Ifb9212fede2333ad68db94188b5cda4fcabe02f8
Inter-BSC outgoing lacked the required BSSMAP HO Failure dispatch.
Not all cases should send BSSMAP HO Failure, name the relevant spec paragraphs
in comments and adjust handling.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I0980cacb9713e41a1eef3a0a7f6cc892e8a20da5
Usually, conn->lchan is set to NULL before/upon releasing it. However, if the
lchan is still associated with a conn upon/after release, make sure the conn
realizes it has no lchan and sends a BSSMAP Clear Request to the MSC.
lchan_reset() is the last step before an lchan is fully unused. In there, make
sure to notify any conn that might still be associated, with
gscon_forget_lchan().
lchan_cleanup() does the same, but in fact this is only called when an lchan is
*deallocated*, but instead it usually merely goes to the UNUSED state.
It may make sense to call gscon_forget_lchan() sooner, e.g. when entering a
releasing state. This here nevertheless is a final safeguard.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I88337a18246c44ba48da64bb611a3cbb647a750e
Clear all lchan->conn pointers when the subscr conn code is choosing to release
an lchan, with gscon_release_lchan().
Rationale: when an lchan releases in error, it should trigger the conn to be
notified and cause a BSSMAP Clear. However, if the conn is actively requesting
for an lchan release, it is already taking care of the situation.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Send a BSSMAP Clear Request only if absolutely no lchan remains associated to
the conn, anywhere (Assignment, Handover as well as primary lchan).
Conceivable would be a situation where e.g. we're in handover and a new lchan
is ready, when just at a time where it doesn't matter anymore the old lchan
fails. We could just carry on with the new one then.
Change-Id: Ibd8e38ccf7759b8834efdedf742c46c227b26e91
Send a BSSMAP Clear Request only if we are not already in ST_CLEARING, i.e.
haven't received a BSSMAP Clear Command yet.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: Idc749068580da45e821e0af04cfa14cc7ce5c432
At the moment codec_pref only checks the codec configuration, but it
does not check if there is actually a matching physical channel
available. This should be checked too we must make sure that the codec
we select fits the physical channels available on the BTS.
Change-Id: I2d29dfed450e5ef93c26ed5ec9fdc0730eb3d7dd
Related: OS#3503
The function match_codec_pref determines whether a permitted speech
value belongs to a half-rate or full-rate codec. Lets seperate this into
a separate function.
Change-Id: Iec1db4621ba5a09bc0e3fc40b66f3a3bc5f54add
Related: OS#3503
In networks with a couple of different BTSs it may be likely that one
accidently sets up a codec configuration (codec-support)) that will be
mutually exclusive towards the codec configuration for the MSC
(codec-list). We need a check that validates the configuration before
start to catch such configuration flaws quickly.
- Add a check that checks each MSC codec-list against each BTS
codec-support setting.
Change-Id: Ice827896bab1a2330741e0fccc731a04f1a07d38
Related: OS#3625
When the user sets no codec-list in the msc node, the configuration will
end up with an empty codec list. This is a useless configuration. There
should be a sane default setting.
- Set all possible codecs as default for codec-list
Change-Id: I3749a65828c788f38c22f0a5314533f4516da3ed
Related: OS#3625
The COMPLETE LAYER 3 INFORMATION message should contain a Codec List
(BSS Supported) IE. The contents of this list depend on the BTS
capabilities and of the MSC configuration (allowed codecs). There may
be cases where (due to miss-configuration) the list is empty. In those
cases the BSC hits an assertion because the encoding of the overall
message fails when the codec list is empty. A check is needed.
- Check codec list before message generation, abort if the coded
list is empty.
Change-Id: I119607047a132b75b3077bbe56c97936d8ae6c96
Related: OS#3625
Opposed to all other codecs that are common in GSM, AMR requires a codec
configuration that is expressed by a bitmask (S0 to S15) in the speech
codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those
configuration in the ASSIGNMENT COMPLETE message.
At the moment osmo-bsc ignores all incoming configuration bits. The bits
in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded.
- Store the configuration bits while parsing the ASSIGNMENT COMPLETE
- Create an intersection with the configuration that is actually
supported by the BSS
- Return the resulting (chosen) configuration bits with the assignment
complete message.
- Use the (highest of the) agreed codec rates in RSL channel activation.
Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
main() was missing a call to rate_ctr_init(). Without it, the counters
increased properly, but the times per second / minute / hour etc. values
would always stay at zero.
Change-Id: I4466a7aec51673c79b67614c9dde987633e379e0
Related: OS#3579
Seen while operating a setup with 2 TRX (2 nanobts):
DNM <0004> abis_nm.c:703 OC=CHANNEL(03) INST=(00,01,04): bts=0 trx=0 Opstart ACK
DTS <0011> bts_ipaccess_nanobts.c:308 timeslot(0-0-4-TCH_F)[0x612000008aa0]{UNUSED}: Received Event TS_EV_OML_READY
DTS <0011> bts_ipaccess_nanobts.c:308 timeslot(0-0-4-TCH_F)[0x612000008aa0]{UNUSED}: Event TS_EV_OML_READY not permitte
As it can be seen, OML log header state correctly it comes from TRX1,
but later content in line expresses TRX0, and that failure is forwarded
up the stack and channels for TRX different than TRX0 are never
initialized.
Related: OS#3560
Fixes: f0ff9a6711
Change-Id: I27e992e419422051247777b048175b724c05323e
After commit https://gerrit.osmocom.org/#/c/libosmo-abis/+/11207/
(Iaa33b793f89f2d16c9d949503c5ecc195bbcd2a4),
input_signal_data->link_type exposes proper enum type, and compiler can
warn about missing cases:
osmo-bsc/bts_ericsson_rbs2000.c: In function ‘inp_sig_cb’:
osmo-bsc/bts_ericsson_rbs2000.c:124:3: error: enumeration value ‘E1INP_SIGN_NONE’ not handled in switch [-Werror=switch]
switch (isd->link_type) {
^~~~~~
Change-Id: Ia407a5072896377b68e914e2a05b5e01292ee8ee
Add missing item in the landscape of VTY commands: allow identifying a local
cell by CGI (besides BTS nr, LAC or LAC+CI, which already exist).
Change-Id: I2d03de6b695904c4a86025bf250358d04f6e47de
When writing the neighbor configuration documentation, I noticed that 'neighbor
add' and 'neighbor del' make sense from an interactive VTY POV, but when
looking at a static config file, it makes more sense to simply name the
neighbors without the 'add' keyword, and to use the 'no' prefix instead of the
'del' keyword. It still makes sense to tweak cosmetics like this before
inter-bsc handover is used anywhere.
First, remove 'add' from all 'neighbor add ...' commands.
Instead, prepend "Add" to the doc string for the cell identification argument
in commands that add a neighbor:
-OsmoBSC(config-net-bts)# neighbor add ?
- bts Neighbor cell by local BTS number
+OsmoBSC(config-net-bts)# neighbor ?
+ bts Add Neighbor cell by local BTS number
(A subsequent patch will rename 'neighbor del' to 'no neighbor'.)
Change-Id: I143f21f6069d1a86096cc8240cf69eb7ea9c8ac8
After previous patch I8dd561d744d8081b5ac5ffa7635f17ac19bcda45, all callers
pass conn->lchan to send_assignment_complete(), so there is no need to pass it
separately from conn.
Change-Id: I3c038d91a53c81d9fcf4ec62f853b59bb1ecd244
In assignment_success(), don't trigger lcls_apply_config() before the
conn->lchan points at the actual new voice lchan. The entire LCLS code relies
on conn->lchan.
The assignment FSM wants to point conn->lchan to the new lchan only after it is
sure that sending the Assignment Complete to the MSC was successful. However, a
failure is a) very unlikely and b) if sending to the MSC fails we might as well
tear the whole conn down anyway. Now, if sending to the MSC fails, release the
lchan and the conn should clean itself up.
Related: OS#1602
Change-Id: I8dd561d744d8081b5ac5ffa7635f17ac19bcda45
When a codec mismatch (lchan type or tch_mode does not match) occurs, we
do not know which of the two lchan had which type or tch_mode. Lets
print that information as well to make debugging easier.
Change-Id: I3fd22fef50d8944ca8c003c6114fdda37417b2ea
Related: OS#1602
In rf_create_socket(), check the result of osmo_strlcpy().
This catches overlong and non-NUL-terminated socket paths.
Change-Id: I4b9ff9146068bf7f53d67c577454f32c02361b86
Related: OS#2673
The COMPLETE LAYER 3 INFORMATION message lacks the Codec List (BSS Supported)
information element. This information element is mandatory for networks
that use an IP based user plane (AoIP).
- Add function to generate the speech codec list from the current codec
settings (Available codecs)
- Generate and embed information element in L3 Compl. message
Depends: libosmocore I4e656731b16621736c7a2f4e64d9ce63b1064e98
Change-Id: Id6f2af3fdab45bf05f06aec03e222734d7a4cf70
Related: OS#3548
At the moment we do not initalize the struct members mr_full and mr_half
in struct gsm_bts. The user still has the option to configure reasonable
values via vty, but when not VTY configuration is made, the flags for
the AMR rates will be all zero. Lets initalize the struct members with
reasonable defaults.
- Make sure gsm_bts_alloc() populates fr_half and fr_full with
reasonable defaults.
Change-Id: I68747ae6dd2582e2a7d60337d9f2c43bd06ac525
Related: OS#3548
The field speech codec (choosen) in the ASSIGNMENT COMPLETE message
has been specified with AoIP. Since sccp-lite has been specified before
AoIP, we should not include the speech codec (choosen) field in the
ASSIGNMENT COMPLETE, when osmo-bsc is connected to an sccp-lite based
network.
- make sure speech codec (choosen) is only included on AoIP based
networks
Change-Id: Ic7f28aacc953d96ebf3aa04f3e1810475458c1a8
If the MSC sends a BSSMAP Classmark Request, send an RR Classmark Enquiry to
the MS.
(The reverse direction, i.e. sending a BSSMAP Classmark Update back to the MSC,
is already implemented.)
Related: OS#3043 (A5/3 encryption)
Related: osmo-ttcn3-hacks Idaab4d568cf986b4897ba008f6262c839d1592fb
Change-Id: If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf
Remove unused gsm_subscriber_connection.user_plane.chan_mode.
There is only one VTY command that displays it along other
parameters, but it is used no where else. Lets remove it.
It was forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I10049c14ea206a4daafbdad01634d57c72a79d7c
Remove unused member gsm_subscriber_connection.user_plane.full_rate.
It was forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I3a14efe0039ff4690e27e3b083eb23c1b2a616c3
gsm_subscriber_connection.user_plane.chan_mode and .full_rate were unused
since and forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
Instead of above unused struct members, use lchan->{full_rate,tch_mode}.
When not explicitly allowed via VTY settings, the LCLS mechanisms will
avoid to locally switch connections with different codecs/rates. For
example GSM HR and GSM FR would not be locally switched.
Change-Id: Idd7117092b1f170d5029303ae5ba0a49e02a8bfb
Related: OS#1602
In function test_codec_support_bts() the switch case statement lacks
break; statements for some cases. This may lead into messed up codec
decisions.
- Add missing break statements
Change-Id: Ib5400a0a0a8a39fa714bd087df345160bed5cc61
The the function make_scl_config() is used to generate realistically
looking speech codec lists to perform the unit tests for codec_pref.c.
This function does not yet populate the S0-S15 bits for AMR codecs. Lets
make sure that at least the default configuration is populated here.
Change-Id: I534239416c038ea856c128659f314aa521f85c15
In case a given channel combination contains a CBCH, it replaces sub-slot 2
with a CBCH, i.e. we must not attempt to allocate the same for SDCCH.
On timeslot initialization, immediately place such an lchan FSM into new state
LCHAN_ST_CBCH, so that it never appears unused and never is picked during
lchan_select(). Also set lchan->type = GSM_LCHAN_CBCH.
Verified by configuring CBCH timeslots and watching 'show lchan summary'.
Immediately after RSL and OML are up, these pchan types show lchan 2 in state
CBCH:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
With a 'phys_chan_config ccch+sdcch4+cbch' and three phones simultaneously
requesting USSD, I see:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 0, Type SDCCH, State ESTABLISHED - L1 MS Power: 14 dBm RXL-FULL-dl: -53 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 1, Type SDCCH, State ESTABLISHED - L1 MS Power: 30 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 3, Type SDCCH, State ESTABLISHED - L1 MS Power: 16 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
With 'phys_chan_config SDCCH8+CBCH' and three phones simultaneously attaching,
I see:
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 0, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 1, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 3, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
i.e. in all cases the CBCH lchan remains occupied and is not allocated as
SDCCH.
Detaching and re-attaching the BTS reliably brings back the CBCH state. Also
verified that changing the osmo-bsc config from telnet vty and dropping oml
followed by the BTS re-attaching brings back the CBCH state.
Change-Id: I2bafc5f696e818e38f8907ad0c8f38494df0623d
Before, this would ignore the failure and hit a timeout instead. Rather handle
the event directly.
Change-Id: I21c43d2907d0413ef18ec43cf27f680ebecf9e82
When the timeslot FSMs were introduced, the function gsm_bts_get_cbch()
was ported to use 'pchan_is'. However, the function is called very
early, before pchan_is is actually initialized.
Let's make sure we're using the _configured_ channel combination
when resolving where the CBCH is (if any) in the BTS.
Ever since merging the timeslot FSMs and before this patch, SI4 would
never indicate the presence of a CBCH.
Change-Id: I6251b5f3e1180ad466e9349a1845e1b91f661c0b
Related: OS#3532
When a CBCH is present in the cell, SI4 contains the channel description
of the CBCH. As SI4 may be generated at a time when the underlying
timeslot is not configured yet, we need to generate the channel
description for the _configured_ channel combination, not the currently
used one.
Change-Id: Idbf9b8e4b1ef0e0348580b83f91355b3236d8609
Closes: OS#3532
gsm48_lchan2chan_desc_as_configured() is similar to gsm48_lchan2chan_desc(),
but uses the *configured* channel combination, rather than the currently
active one.
Change-Id: Id4043218fb770e8420f19a4ef9428680ecdfd286
Related: OS#3532
The function is defined in gsm_data.c, so it should be declared
in gsm_data.h and not in gsm_04_08_rr.h
Change-Id: I5200063fb43c857a984ea8e41a8485d796e49cde
Set msgb->l3h when composing the L3 message. Before this, the unset l3h
resulted in erratic size in the RSL L3 Info IE. This likely fixes inter-BSC
Handover on the outgoing side, to properly forward the RR Handover Command.
Change-Id: Ice37242c90c19adbf0795618fd16fe75f0809317
Before Handover is fully completed, the gscon remains in an INIT state. To send
back the BSSMAP Handover Complete message, use osmo_bsc_sigtran_send() directly
to not thwart the message due to the gscon state.
(The gscon state will change to ACTIVE right after that, once the handover FSM
is done.)
Change-Id: Ic48ae2bb23565015d5e2ccb56308fad09347b51a
Compose the Speech Codec (Chosen) IE not only for AoIP, but also for SCCPlite:
place the code that assigns the codec to sc_ptr outside of the gscon_is_aoip()
if scope.
This way the MSC is told the chosen speech codec, which is mandatory for IP
based user plane, and was missing until now.
Related: OS#3528
Change-Id: Ibedade8d71a7994d25a63bc2faa2a24a10bfffa1
There is a function call to gsm0808_speech_codec_from_chan_type() after
an if construct that checks if we need voice and if we need it if it is
related to an AoIP connection.
However, at the moment we call gsm0808_speech_codec_from_chan_type() all
the time, even when just figured out that we don't need to. Presumably
this is a refactory leftover. Lets remove the excess function call.
Change-Id: I34d9281944b36cd89ad8e1c5774f0ea80fdfadc8
When activating an lchan, the power levels should be maximum and TA zero. Only
if a new lchan is assigned within the same cell does it make sense to take over
the previous power and TA levels.
In LCHAN_EV_ACTIVATE:
- Separate the code that copies previous encryption data. This should happen
regardless of whether we're staying in the same cell or not.
- For the power,TA levels, take over an old lchan's values only when it is
assigning a new lchan in the same cell.
Change-Id: I360b003398487fa6f934296ff03643c33ec61a35
Drop the todo comments about "for_conn->encr". I have intended that as an idea
to store encryption info in the conn instead of the lchan, which might make
sense, but there's no use in these comments.
Change-Id: I47e90062c784dd7919fff3115e2bee3314b30cd5
In lchan state UNUSED, on activating an lchan, we zero out the lchan->mr_ms_lv
and mr_bts_lv. However, in UNUSED's onenter function, we already called
lchan_reset(), clearing out the lchan completely.
Drop two lines of unnecessary code.
Change-Id: I8b38f222f1c8c822e8e5e776850dbc60e30e8b8d
In osmo_bsc_sigtran.c, instead of osmocom/mgcp/mgcp_common.h, include the same
file from mgcp_client/. (mgcp_common.h is identically installed both by
libosmo-mgcp and libosmo-mgcp-client, in their respective include dir.)
Trying to include from mgcp/ breaks the debian package builds, since only
libosmo-mgcp-client is installed as per osmo-bsc dependencies. The error was
introduced by:
commit d8f46c0074
"MGCP: add 'X-Osmo-IGN: C' for SCCPlite by default"
change id I257ad574d8060fef19afce9798bd8a5a7f8c99fe
Change-Id: I917b0c08ed91172ecb68c946aecb02c5109fcced
If inter-BSC HO failed, the conn is by definition not in an active state, and
hence it makes no sense to verify the gscon FSM state before sending. Directly
call osmo_bsc_sigtran_send().
Change-Id: Ic49c94462041800674fa961c4d19c0c045bfe0c0
The flag lchan->activate.concluded prevents entering the
lchan_on_fully_established()/lchan_on_activation_failure() more than once. So
far it was checked by callers, instead place in the functions themselves.
There is a potential functional change here, since during lchan_fail(), the
concluded flag was set only after entering lchan_on_activation_failure(). Now
it is already set at the start and prevents multiple re-entry beyond doubt.
This patch is not a result of an actual observed faulty behavior, just from
reading the code and seeing the slight loophole.
Change-Id: I0c906438b05442d66255203eb816453b7193a6d8
Early on during failure, log which state transition is intended after failure
handling.
If such state is already reached after failure handling, do not log "state
transition not permitted", but rather skip the state change and log "Already in
state X".
Change-Id: I81f53b38637823e62860cb773b7573bb5c21fdb0
lchan_fail_to() is a macro to preserve useful source file:line information in
logging. But a side effect is that its target state argument might evaluate
differently at the end of the macro, if, say, the fi->state has changed.
I hit such an instance on timeout of WAIT_RLL_RTP_ESTABLISH:
lchan_fsm_timer_cb() calls macro lchan_fail(), which calls
lchan_fail_to(lchan_fsm_on_error[fi->state]). Unlike for normal function
invocation, this argument changes as fi->state changes. Since releasing the
lchan_rtp_fsm already transitions the lchan fi into WAIT_RF_RELEASE_ACK, the
final state change of lchan_fail_to() suddenly evaluates to the broken state
instead of the intended WAIT_RF_RELEASE_ACK.
Early in lchan_fail_to(), store the argument's value as of macro invocation.
Change-Id: Id9bf4580a112ee5629f553a8bcb6b5b03b1c5f53
Drop nonsensical legacy code.
The Circuit Identifier Code in A/SCCPlite does *not* indicate the RTP port to
use. Rather, it indicates the MGW endpoint name to use when configuring the
BSC's side of the MGW endpoint, and only the MGW will ever know the RTP port.
Change-Id: I471bd5e5cc2a083dd37290aeaae5c334ca5f7eed
3GPP mandates either Classmark Information 1 or 2 in BSSMAP Handover Request,
but an SCCPlite MSC currently tested does not pass either of them. Make this
missing IE a non-fatal error, continuing anyway should work out.
See 3GPP TS 48.008, 3.2.1.8 HANDOVER REQUEST, where it says "Classmark
Information 1 or Classmark Information 2" with note 6: "One of these two
elements is sent."
Change-Id: I34d64b028210b4df8652fee1a8830ec4a4e3ac11
In the 'lac-ci' and 'cgi' neighbor identity VTY parameters, fix the CI part to
<0-65535>.
Use 65535 as CI in the neighbor_ident.vty test to verify the range.
Change-Id: Ie93bfe176b9d2d9445966e4ab0b928b9aa62a77f
The "bts", "lac" and "lac-ci" VTY parameters and documentation are used more
than once in this file. Define once and re-use.
Prepares cosmetically for a fix of the CI format in upcoming
Ie93bfe176b9d2d9445966e4ab0b928b9aa62a77f.
Change-Id: I88a377c6d77c5f18877343f84f7a26f851a427ff
Use libosmo-mgcp-client's new X-Osmo-IGN header to indicate that CallIDs are
allowed to mismatch.
Add VTY commands 'msc' / 'mgw x-osmo-ign call-id' and 'no mgw x-osmo-ign' to
switch this behavior explicitly.
For SCCPlite MSCs, unless a specific config was issued, always send
'X-Osmo-IGN: C' by default, to ignore CallID mismatches.
Depends: Id7ae275ffde8ea9389270cfe3db087ee8db00b51 (osmo-mgw)
Change-Id: I257ad574d8060fef19afce9798bd8a5a7f8c99fe
ipaccess_drop_oml was being called inside an osmo_fd cb context, were
-EBADF must be returned if the structure holding the osmo_fd is freed.
In the middle of the path (see OS#3495 for path tree) it goes through a
signal dispatch, so it's impossible to make sure we return some value to
the osmo_fd cb. As a result, it is required to defer dropping the OML
Link from current code path and do it through a timer.
Fixes following ASan report:
20180822124927913 <0004> abis_nm.c:787 OC=RADIO-CARRIER(02) INST=(00,00,ff): CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed
20180822124927913 <0004> osmo_bsc_main.c:186 Got CHANGE ADMINISTRATIVE STATE NACK going to drop the OML links.
20180822124927913 <0015> bts_ipaccess_nanobts.c:406 (bts=0) Dropping OML link.
...
=================================================================
==17607==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e000060a68 at pc 0x7f5ea8e27086 bp 0x7ffde92b6d80 sp 0x7ffde92b6d78
READ of size 8 at 0x62e000060a68 thread T0
#0 0x7f5ea8e27085 in handle_ts1_write input/ipaccess.c:371
#1 0x7f5ea8e27085 in ipaccess_fd_cb input/ipaccess.c:391
#2 0x7f5ea9147ca8 in osmo_fd_disp_fds libosmocore/src/select.c:217
#3 0x7f5ea9147ca8 in osmo_select_main libosmocore/src/select.c:257
#4 0x555813ab79d6 in main osmo-bsc/osmo_bsc_main.c:922
#5 0x7f5ea76d02e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#6 0x555813ab84e9 in _start (/bin/osmo-bsc+0x34d4e9)
Fixes: OS#3495
Change-Id: I7c794c763481c28e8c35dc9b11d27969e16feb3c
Release and Rollback events are allowed but unhandled in states
WAIT_MGW_CONFIGURED and ROLLBACK, and hence would result in an assertion. Add
handling in these states.
Change-Id: Iab233c592384902098644eee27bb8445fde3aa6f
LOGPFOH uses the msgb through "foh", so we have to free msgb after
calling it, not before.
Fixes following ASAN report:
[0;m[1;36m20180822120155990 [1;34mDNM[0;m[1;36m <0004> abis_nm.c:1889 OC=CHANNEL(03) INST=(00,01,06): Set Chan Attr (bts=0,trx=1,ts=6)
[0;m=================================================================
==16465==ERROR: AddressSanitizer: heap-use-after-free on address 0x61a00002b3f0 at pc 0x7f587f44c0db bp 0x7ffc59e31df0 sp 0x7ffc59e31de8
READ of size 1 at 0x61a00002b3f0 thread T0
#0 0x7f587f44c0da in abis_nm_dump_foh libosmocore/src/gsm/abis_nm.c:937
#1 0x561e09e1532c in abis_nm_set_channel_attr osmo-bsc/src/osmo-bsc/abis_nm.c:1892
#2 0x561e09efd269 in nm_statechg_event osmo-bsc/src/osmo-bsc/bts_ipaccess_nanobts.c:168
#3 0x561e09efd269 in bts_ipa_nm_sig_cb osmo-bsc/src/osmo-bsc/bts_ipaccess_nanobts.c:335
#4 0x7f587efb3d16 in osmo_signal_dispatch libosmocore/src/signal.c:120
#5 0x561e09e18e31 in abis_nm_rx_statechg_rep osmo-bsc/src/osmo-bsc/abis_nm.c:255
#6 0x561e09e18e31 in abis_nm_rcvmsg_report osmo-bsc/src/osmo-bsc/abis_nm.c:380
#7 0x561e09e18e31 in abis_nm_rcvmsg_fom osmo-bsc/src/osmo-bsc/abis_nm.c:778
#8 0x561e09e1dc19 in abis_nm_rcvmsg osmo-bsc/src/osmo-bsc/abis_nm.c:926
#9 0x7f587ec90cc2 in handle_ts1_read input/ipaccess.c:274
#10 0x7f587ec90cc2 in ipaccess_fd_cb input/ipaccess.c:389
#11 0x7f587efb1ca8 in osmo_fd_disp_fds libosmocore/src/select.c:217
#12 0x7f587efb1ca8 in osmo_select_main libosmocore/src/select.c:257
#13 0x561e09e049d6 in main osmo-bsc/src/osmo-bsc/osmo_bsc_main.c:922
#14 0x7f587d53a2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#15 0x561e09e054e9 in _start (/bin/osmo-bsc+0x34d4e9)
Fixes: OS#3494
Change-Id: I030117abfdcee387516a4dea7e1e6a9bae8055f6
The intention was to use the file's basename, but __BASE_FILE__ means "the root
file that is being parsed and contains #include statements".
If we had a function using __BASE_FILE__ and that was defined in an #included
file, __BASE_FILE__ would indicate the first file where the #include is, and
not the file where the function is defined. __BASE_FILE__ works for us because
we don't ever include function definitions that log something, so __BASE_FILE__
always coincides with __FILE__ for our logging; but still __BASE_FILE__ is
semantically the wrong constant.
Related: OS#2740
Change-Id: Ic6d9dafc96c9d467ae53be2cd41adcf26a4e5125
libosmocore recently had the new API introduced for this purpose.
Depends: libosmocore Change-Id Id58ca18eb826b8f4183a7cf0dbb2b38cba702a09
Change-Id: Id07260635327617f8da5050af1e906891a89c530
The example config file lacks a default port setting for the local
mgcp client port. Lets update that.
Change-Id: I6b1c5097d98ec2ab97d51f99b1105db3de85c75f
Related: OS#2874
It is theoretically possible to LCLS two legs that use different
codecs. However, this requires transcoding capabilities on the
local MGW. If the local MGW lacks transcoding features such a
local circuit should be avoided. Enabeling LCLS under such
coditions should be optional (VTY)
- Add check to avoid LCLS on different codec/rate
- Add VTY-Option to optionally override the check
(MGW is able to transcode)
Change-Id: I157549129a40c64364dc126f67195759e5f1d60f
Related: OS#1602
The API of a_reset.c is currently called with a pointer to struct
reset_ctx. This puts the responsibility of checking the presence of
msc->a.reset_fsm to the caller. It would be much more effective if the
caller would check if msc->a.reset_fsm before dereferencing it.
This also fixes at least one segfault that ocurrs when gscon_timer_cb()
is called but no sccp connection is present yet. Therefore the pointer
to bsc_msc_data would not be populated. This is now detected by
a_reset.c itsself.
- minor code cleanups
- call a_reset.c functions with msc (struct bsc_msc_data)
Change-Id: I0802aaadf0af4e58e41c98999e8c6823838adb61
Related: OS#3447
When no connection is present and had never existed, then
conn->sccp.msc is unpopulated. However, there may be situations where
osmo_bsc_sigtran_send() is executed while no connection is present.
At the moment we assert on conn->sccp.msc, which would cause osmo-bsc
to exit. In order to avoid this, better check conn->sccp.msc and drop
the sccp message when the check is negative.
- Remove assertion, add check.
Change-Id: I4eaa983702224e5995a388ea9890ee04212eb569
Related: OS#3446
The function osmo_bsc_sigtran_send() checks if the MSC is ready by
calling a_reset_conn_ready(). If it is not ready it returns with
-EINVAL. The msg message buffer is not freed, so we leak memory in those
edge cases.
- Make sure msg is freed when MSC is not ready.
- Add a comment that osmo_bsc_sigtran_send() takes ownership of msg
Change-Id: Ib1ff1d20e960a356bcee276b7c1bf9c93283e7af
When building with -Werror=format-security, such as our OBS builds,
it fails like this:
[ 118s] handover_fsm.c: In function 'parse_ho_request':
[ 118s] handover_fsm.c:478:4: error: format not a string literal and no format arguments [-Werror=format-security]
[ 118s] gsm0808_cell_id_name(&req->cell_id_serving));
[ 118s] ^~~~~~~~~~~~~~~~~~~~
[ 118s] handover_fsm.c:489:4: error: format not a string literal and no format arguments [-Werror=format-security]
[ 118s] gsm0808_cell_id_name(&req->cell_id_target));
[ 118s] ^~~~~~~~~~~~~~~~~~~~
[ 120s] cc1: some warnings being treated as errors
Let's make sure we don't call sprintf() and friends without a format
string. In fact, if we only want to copy a string without extra
formatting, use osmo_strlcpy() or OSMO_STRLCPY_ARRAY().
Change-Id: I56cff3618f012f6b019f4fca7e2768814487137a
In libosmocore Change-ID I1834d90fbcdbfcb05f5b8cfe39bfe9543737ef8f
we have introduced ipa_ccm_id_resp_parse() as a bugfixed replacement
of ipa_ccm_idtag_parse().
The main difference is that the returned "value" parts now have
a correct reported "length", whereas before this commit they all
reported a one-byte too-long "length" for each IE.
Change-Id: I7d5ab323989c13d0cc6ff05547306edb918e423f
In cases where a codec has no fixed (IANA) payload type number, a
dynamically coosen payload type number is used. For the route between
BSC and MSC 3GPP as designated certain payload type numbers. However,
beond that, those payload type numbers may not necessarly apply. The
RTP communication between BTS and BSC still might run on a completely
different payload type number.
libosmo-netif contains a header file which payload type numbers
shall be used. Lets use those in order to signal the same payload type
numbers as we actually use in the RTP packets to the MGW.
Change-Id: I507a1b1446c8f140b2950d73cf737797604c1ac3
Related: OS#2728
Related: OS#3384
The function mgcp_pick_codec is responsible to set the codec
information. In cases whee the codec type can not be determined
correctly it sets verb_info->codecs_len = 0, indicating to the caller
that no codocs are set. However, after that it does not return, it sets
an invalid codec anyway.
- Add missing return to keep the no-codec setting in case of error.
Change-Id: I8d1f8553357b6ad328ab1e5d4525fad0dd282a42
I often see "ERROR [ST_CLEARING] Entering ST_CLEARING not permitted!", avoid
the bogus error messages by checking entering ST_CLEARING only if not in it
yet. Still don't allow re-entering, to not restart the timeout.
Change-Id: Ia1f171c08dcbc529f907a20eed43bf5ee3a452b3
Remove as much as possible from bsc_api.h. Use '#pragma once'. Tweak head
comment.
BSC_API_CONN_POL_{ACCEPT,REJECT}: only user is static complete_layer3(), just
use a bool return value instead.
msc_connected(): only used in osmo_bsc_api.c, make static there.
Instead of including gsm_data.h, declare structs opaquely, include stdint.h.
codec_pref_test.c used this as indirect gsm_data.h include via osmo_bsc.h,
include gsm_data.h there directly.
osmo_bsc.h: instead of including bsc_api.h, declare opaque structs.
gsm_04_08_rr.h: declare opaque structs to replace indirect include of
gsm_data.h.
Change-Id: Ia9c0f9828317236048e40ec9ecf9990592e2190a
gsm0808_page() is just a thin wrapper for rsl_paging_cmd(), the only caller is
page_ms() from paging.c. Directly call rsl_paging_cmd() instead.
Move gsm0808_cipher_mode() to the only caller in osmo_bsc_bssap.c, make static.
Change-Id: Ib7ce026b52d4ba3e53a8b2824e74ea92432c48c5
The 'handover any' VTY command is only useful for testing. It is even more
useful if it doesn't always pick the first used lchan but produces more random
handovers.
The algorithm takes a random number as input, iterates over used lchans once,
and if the random number is larger, takes modulo of the nr of used lchans
counted. A second iteration will then produce a match.
Instead of figuring out the lchan type logic in bsc_vty.c, just use
lchan_select_by_type();
Change-Id: I50b70e02d665b967e401db65581e110bc83101e7
If a release event is being handled, ignore other ricocheting release events
until that release handling has concluded.
For example, if an lchan is regularly released, it signals the lchan RTP FSM to
release, which then calls back to say "RTP is released" on termination -- this
should not trigger other state changes than the initial release intends.
Change-Id: Iec41e006b6ab9d0f618d36925341f9536353e5d8
In various FSMs, some events may appear later or earlier without need of
action. Do not indicate these as 'ERROR' (event not permitted), but allow and
ignore them.
Debug-log about some of those.
From the old code, we've taken over the habit to change into
WAIT_BEFORE_RF_RELEASE even before SAPI[0] is released. Hence we may still
receive a SAPI[0] REL_IND in WAIT_BEFORE_RF_RELEASE. Don't show this as error
message, just silently accept it.
Change-Id: Ie320c7c6a1436184aaf2ec5a1843e04f4b3414ab
If PDCH ACT sending fails and we go back to UNUSED, the UNUSED onenter goes
right back to PDCH ACT and we loop. Avoid by going straight to broken state.
Actually, if we can't send messages, the timeslot is obviously broken, so also
enter the broken state if PDCH deactivation fails to be sent out.
Change-Id: Iebaffd0547a9651c5ba435b54dedab99c2cfdd31
Noticed by ttcn3-bsc-test: after TC_ms_rel_ind_does_not_cause_bssmap_reset the
test TC_dyn_pdch_ipa_act_deact would fail because RSL was still indicated as
available, and only OML was properly signalled as down.
Before recent commit I4843d03b3237cdcca0ad2041ef6895ff253d8419 to fix nanobts
and use only flags for RSL and OML presence, the timeslot FSM actually checked
RSL link presence and the lacking RSL DOWN event was not noticed.
Change-Id: I66c7fc5fcc676f4960f3d089b8c2ae5bce37ed99
Before this patch, the timeslot FSM receives OML and RSL ready events.
Afterwards, it relies on examining the RSL and OML status to match the received
events. This doesn't work for the ip.access nanobts, which fails to change the
CHANNEL OM's operational status even though it has sent an Opstart ACK. We
receive OML CHANNEL Opstart ACK, but the mo's state left at OP_STATE=Disabled.
We apparently cannot rely on the gsm_abis_mo state as assumed before this
patch, since changing the state depends on each BTS vendor's OML
implementation.
Also, implementation wise, it is better to not include assumptions on RSL and
OML implementations in the timeslot FSM. Simply receive the OML and RSL ready
events and remember that they arrived in dedicated flags.
Remove the no longer needed oml_is_ts_ready() callback from struct
gsm_bts_model added in:
commit 91aa68f762
"dyn TS: init only when both RSL and the Channel OM are established"
I99f29d2ba079f6f4b77f0af12d9784588d2f56b3
This keeps osmo-bts operational while fixing ip.access nanobts, where the
CHANNEL OM's state prevented the timeslot FSM from entering operation.
Change-Id: I4843d03b3237cdcca0ad2041ef6895ff253d8419
Add FSMs:
- timeslot_fsm: handle dynamic timeslots and OML+RSL availability.
- lchan_fsm: handle an individual lchan activation, RTP stream and release,
signal the appropriate calling FSMs on success, failure, release.
- mgw_endpoint_fsm: handle one entire endpoint with several CI.
- assignment_fsm: BSSMAP Assignment Request.
- handover_fsm: all of intra, inter-MO and inter-MT handover.
Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing
the maximum amount events (32), and it is more logical to treat assignment,
handover and MGW procedures in separate FSMs.
- Add logging macros for each FSM type:
- LOG_TS()
- LOG_LCHAN()
- LOG_MGWEP(), LOG_CI()
- LOG_ASSIGNMENT()
- LOG_HO()
These log with the osmo_fsm_inst where present.
New style decision: logging without a final newline char is awkward,
especially for gsmtap logging and when other logs interleave LOGPC() calls;
we have various cases where the final \n goes missing, and also this invokes
the log category checking N times instead of once.
So I decided to make these macros *always* append a newline, but only if
there is no final newline yet. I hope that the compiler optimizes the
strlen() of the constant format strings away. Thus I can log with or without
typing "\n" and always get an \n termination anyway.
General:
- replace osmo_timers, state enums and program-wide osmo_signal_dispatch()
with dedicated FSM timeouts, states and events.
- introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def.
These can be used (with some macro magic) to define a state's timeout once,
and not make mistakes for each osmo_fsm_inst_state_chg().
Details:
bsc_subscr_conn_fsm.c:
- move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and
mgw_endpoint_fsm.
- There is exactly one state for an ongoing Assignment, with all details
handled in conn->assignment.fi. The state relies on the assignment_fsm's
timeout.
- There is one state for an ongoing Handover; except for an incoming Handover
from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn
are both established.
- move bssmap_add_lcls_status() to osmo_bsc_lcls.c
abis_rsl.c:
- move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in
abis_rsl.c
- reduce some rsl functions to merely send a message, rename to "_tx_".
- rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the
lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function.
- move all timers and error/release handling away into various FSMs.
- tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an
lchan passed, but just mode,type that they require. Rename to
ipacc_speech_mode*() and ipacc_payload_type().
- add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR
message received during BSSMAP Handover Command.
- move various logging to LOG_LCHAN() in order to log with the lchan FSM instance.
One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging
from DRR to DRSL. It might actually make sense to combine those categories.
- lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance.
- handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's
correct).
- gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during
inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS.
assignment_fsm.c:
- the Chan Mode Modify in case of re-using the same lchan is not implemented
yet, because this was also missing in the previous implementation (OS#3357).
osmo_bsc_api.c:
- simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to
lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv
twice, once by member assignment and then again with a memcpy.)
- During handover, we used to copy the MR config from the old lchan. Since we
may handover between FR and HR, rather set the MR Config anew every time, so
that FR rates are always available on FR lchans, and never on HR lchans.
Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore),
I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore)
Change-Id: I82e3f918295daa83274a4cf803f046979f284366
Rationale: bsc_api.c used to be a kind of kitchen sink for various
implementations, we want to dissolve it. Also, combining 0808 and 0408 in the
same c file causes "weird" linking dependencies for utility and test programs.
bsc_api.c will be completely dissolved in upcoming
Ib7ce026b52d4ba3e53a8b2824e74ea92432c48c5.
Change-Id: Ie8ee334145bf7bc3a601d395ea7ab9b2009b61c7
"utils" suggests thin helpers to aid using a proper API, while this .c file
actually *is* the proper RR API. Rename from "utils" to "rr".
Change-Id: I0ffff63d57f03cb324df8e40e41caea5b55a2c85
In certain situations like handover or assignment, DTAP must not go out via RSL
directly but is cached to be submitted later. Make sure that all RSL DTAP
sending adheres to this:
gscon_submit_rsl_dtap() is the new "public" API to request an RSL DTAP to be
sent. Depending on the gscon's state, this ends up in the cache or is sent
directly. When caching, there is no way to tell whether sending will succeed or
not, so semantically it does not make sense to even return a result code. Just
return void. Change all "public" callers to gscon_submit_rsl_dtap().
Merge gsm0808_submit_dtap() and submit_dtap() guts to gsm0808_send_rsl_dtap(),
static in bsc_subscr_conn_fsm.c: directly send DTAP, assume a conn->lchan to be
present, or otherwise trigger a BSSMAP Clear Request.
The static submit_dtap() becomes a thin convenience wrapper.
Move ho_dtap_cache* functions to bsc_subscr_conn_fsm.c and rename to
gscon_dtap_cache_* -- they are not only for handover, also for assignment.
Function gsm0808_submit_dtap() m
Introduce function gscon_submit_rsl_dtap()
Change-Id: I6ffd7aa641c8905292c769400048c96aa0949585
These reflect the plan for refactoring, and will be implemented by
I82e3f918295daa83274a4cf803f046979f284366 and
Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb
Change-Id: I29e31b753e23a4207662e0e385a337e7df836f45
9-bit BSIC exist in the 3GPP specs, but we don't use them anywhere. Rather
remove that choice from the API and UI.
Change-Id: I29b92f47da2636d3a19f073755f9382fa98f9010
The payload constants for AMR, EFR, GSM-FR, and GSM-HR are already
defined in libosmo-netif, there is no need to re-define them locally.
- include rtp.h from libosmo-netif in abis_rsl.c
- remove duplicate payload type constants
Change-Id: Ib6a866b29d863d6875c67748dbe6b6468941ab29
Related: OS#2728
This check is not in all our repos that use git-version-gen. Indeed it
seems to be a leftover of openbsc where I think it wanted to ensure
being called in the openbsc subfolder or something? libosmocore e.g.
doesn't have it.
In any case .git being a directory is not always true (if using git
worktree) so remove this check.
Change-Id: I976dd4ff20cc5b220b244b1fb6192c0528c32638
Legacy compat: we used to not check the BTS codec-pref settings upon assignment
until we added checks for the BTS codec-pref in osmo-bsc
5bc43cd107, change-id
I285234e9c81de74d9fb9907fca2c443b08537435, "codec_pref: check bts codec
support". From that commit onwards, config setups without a 'codec-pref'
potentially stop working (like all osmo-gsm-tester runs just did), because with
no codec-pref settings, now only FR is permitted, while before the patch, we
would allow any codecs as long as MSC and the overall BSC config agree on them.
So, upon BTS initialization, enable all codecs. These get reset to a more fine
grained selection IF a 'codec-support' config appears in the config file (see
bsc_vty.c).
Change-Id: I4650a1f8e350c6f74f48391f43ddfe771be01e1b
The function lchan_free() is supposed to reset the lchan so that
it can be used by another connection. This function does not yet
reset the struct memebers in lchan->abis_ip. This may lead to
confusion if some other end re-uses that lchan and finds old RTP
voice port/ip settings there. Those data must be reset to
ensure it does accidently migrate into an unrelated conext.
- do a memset to 0 on lchan->abis_ip in lchan_free()
Change-Id: I0c99494292cd1d058a19a21413d0ddb51471c6be
Related: OS#3396
The vty option bts->codec-support allows the user to set the supported
codecs per BTS level. However, those values are currently only used to
make the handover decision but the logic that handles the BSSMAP
ASSIGNMENT REQUEST does not check those flags.
- Do not ignore bts->codec-support flags on BSSMAP ASSIGNMENT REQUEST
Change-Id: I285234e9c81de74d9fb9907fca2c443b08537435
Closes: OS#3361
At the moment there are three sources that may advertise a list of
supported audio codec/rate settings. There is the MS that advertises
advertises a speech codec list and the MSC that sends a channel type
information element over A and there are also settings in the bsc
configuration file that may restrict the codec/rate types that are
allowed to use.
The function match_codec_pref() looks at all of the three buckets and
selects a codec that satisfies all three. This is already a somewhat
complicated process, overit is very isolated, so lets give it its own
c-file.
Due to the lack of unit-tests it is very hard to make changes here so
lets add also unit-test to make sure that regressions are catched early.
- Put match_codec_pref() and all its helper functions into a separate
c-file.
- Add a unit test.
Change-Id: Iabedfdcec8b99a319f2d57cbea45c5e36c7b6e29
Related: OS#3361
Before this, a handover request in a conn state that disallows it would leave a
lingering handover state in the conn, also thwarting any future handover
attempts. (It would be deallocated on conn teardown, so no memleak.)
Change-Id: I839a05495ae93c5dbbd1616efa2469e5b1990a61
If an invalid phys_chan_config is specified in osmo-bsc.cfg, raise
a parsing error at program startup.
If an invalid phys_chan_config is specified in in the VTY while
the program is running, show a warning to inform the user that
the configuration change was not applied.
Change-Id: I97baa359464a0e94de2497bc9214b99ed2a24041
Related: OS#1876
xua_msg allocations should not go unnoticed by our root ctx. libosmo-sigtran
recently added this API to fix that.
Depends: I618878680a096a7f7fc2d83098590f2e4cb08870 (libosmo-sccp)
Change-Id: I8d5edda17be82e0cb4a1af3e2a62cbcb3a2ddda3
Fixes following runtime warning:
libosmocore/src/rate_ctr.c:219 counter group 'nat:filter' already exists for index 0, instead using index 1. This is a software bug that needs fixing.
Forward-port from openbsc.git c08d58802e03a45f95b8f7d28b29dc7026f664ba.
Change-Id: I7c5054c374281bb1d4bd1ecd76ddcca7a010d50a
The '.' is illegal character in counter names, as they are exported
via CTRL interface, where '.' has a special meaning that cannot be
used by strings comprising the variable name.
Forward-port from openbsc.git 360284d4d797519faed33559b0ae746b6c17e68a.
Change-Id: I57b78162701a6a101b5cbaf68aaea89d17a0f819
Previous state is harmless because the pointer is stored but not used in
that function. However, it's more clear this way.
Change-Id: I048ebc120306ea30ea973d6ee16ed84c9f341183
While GSCON is setting the codec info when operating on the MGW, LCLS
is not doing that yet. This means that the MDCX messages that are
sent by LCLS do not contain any payload type and also no ptime or
rtpmap fields. This also causes the following TTCN3 tests to fail:
TC_lcls_connect_break
TC_lcls_connect_clear
TC_lcls_gcr_bway_connect
TC_lcls_gcr_bway_dont_connect_csc
- Make mgcp_pick_codec() public as bsc_subscr_pick_codec()
- use bsc_subscr_pick_codec() to set codec info in osmo_bsc_lcls.c
Change-Id: I383d55fa602cda0926dd701ee517a299db578260
Closes: OS#3358
The GSCON FSM does not care about the codec information when performing
interactions with the MGW. Before upgrading the client the codec
information was hardcoded to AMR inside the client. Now the client
offers APIs to set the codec information. Since this feature is new,
osmo-bsc does not set any codec information yet, which causes many of
the TTCN3 tests to fail. So lets add some logic to pick suitable codec
info.
- Hardcode ptime to 20 (is the same for all possible codecs)
- Select a codec according to the flags in userplane
Change-Id: Ibddc3492572b39f166e3a1b8b8120813ce2dadc2
Related: OS#2728
Commit "dyn ts, bts_ipaccess_nanobts.c: init PDCH on Chan OPSTART ACK"
bf7099262a Icf6e25ff068e8a2600562d52726ead65e864ec02
introduced signal S_NM_OPSTART_ACK and passed the FOM header to identify the BTS
by. But the FOM header's BTS number is zero on each Abis/IP link, and the BTS
and TRX are actually identified by msgb->dst == e1inp_sign_link, member trx. So
the initial implementation associated *all* Channel OPSTART ACKs with BTS 0.
Pass the entire msgb as S_NM_OPSTART_ACK signal argument, implement a
abis_nm_get_ts() to retrieve the proper timeslot and use that during timeslot
init.
Related: OS#3351 OS#3205
Change-Id: I45ce5c24cb62d00f350df1af1be6c11104d74193
When we receive a RSL CONN FAIL IND, it may be that this happens
before any RLL is established (and hence a lchan->conn exists),
or after the RLLs have been shut down (and hence a lchan->conn doesn't
exist anymore).
So in this function, it is not legal to unconditionally dereference
lchan->conn.
Change-Id: I6380f5d2cd9364560ce3947517c84247cf4af0d4
Closes: OS#3182
3GPP TS 48.006 section 9.2 states clearly that any SCCP connection
release must be initiated by the MSC.
for bsc_subscr_conn_fsm, this means that even after sending the
BSSMAP CLEAR COMPLETE, we must not terminate the FSM, as this would
cause a N-DISCONNET.req to be sent to the stack for the associated
SCCP connection.
The bsc_subscr_conn_fsm instances will hence stay alive until the MSC
eventually decises to release them.
Change-Id: Iaaca220b598609b77b600fcfc2f9a78b221c1fbb
Closes: OS#3331
We use the newly-introduced logging_vty_add_deprecated_subsys() from
libosmovty to make sure old config files will still parse even after
this change.
Change-Id: Ib4f67bb00e1d5460e643717b53f6a4d81278dc5d
In Change-Id OSI6b7354f3b23a26bb4eab12213ca3d3b614c8154f we introduced
a function called osmo_ss7_asp_rx_unknown() which was supposed ot
override a weak symbol in libosmo-sigtran. However, the related change
in libosmo-sigtran (I8616f914192000df0ec6547ff4ada80e0f9042a2) was
modified later on to use explicit registration of a call-back function
instead of weak symbol override.
Let's adopt the osmo-bsc code to make use of this explict call-back
registration.
Change-Id: Id5880ec90dfa00b29cbb0ffea8c8dd50e24742bd
Related: OS#2012
In Change-Id I6b7354f3b23a26bb4eab12213ca3d3b614c8154f we removed
the "dest" vty command, but we should simply ignore it and print
a related warning during start.
Change-Id: I531825061031918bbb1380e1b485b711e81bcd75
Do not invoke OSMO_STRINGIFY() with arbitrary names, just quote instead.
The idea was that OSMO_STRINGIFY() avoids typos by ensuring well-defined names
are stringified, but this highlights that OSMO_STRINGIFY() is in fact usable
with completely arbitrary arguments and actually lacks the validation part :/
Change-Id: I458cd2cd0d6ddb0e6db3bb8d546a20336ae8c5f1
Add lchan and timeslot FSM charts to illustrate planning of how osmo-bsc should
handle lchan assignment and release.
Modify assignment, handover, lchan-release charts according to the new plan.
Change-Id: I18d60de5ee932c962aad0a532965a55d570bb936
Another small step towards being aware of the subscriber identity.
Any connection initiated by paging will subsequently log the subscriber's
identity -- of course not necessarily the IMSI, if paging was done by TMSI.
This is only for Paging, not the Paging Response; for that see, L3 Complete.
Related: OS#2969
Change-Id: I0ab7bedfe693bb4e42a04fb0585b94a730ff2d9b
This is a tiny step towards being aware of a connection's subscriber identity.
Iff the Layer 3 Complete message contains an IMSI, associate a bsc_subscr with
the conn, so that subsequent logging and possibly meas_feed contains the IMSI.
For any L3 Complete using TMSI, this has no effect whatsoever.
Related: OS#2969
Change-Id: I3b696a0c0932e3abcb682ba231db65755d8c27a6
Keep the bsc_subscr associated with the conn as long as possible, to benefit
logging, which then contains the subscriber identity (if any).
Change-Id: Ifa528b58842a02509bfe0af6915c64bd67058bcd
Instead of silently setting the use count to 1, instead increment with an
explicit bsc_subsct_get(), which then logs the event along with the place that
created the subscriber.
Change-Id: Ia72f8010b7b2e1ca44e3b005c0f2c05f3eeae8d5
The guts of bssap_speech_from_lchan() and lchan_to_chosen_channel() have been
moved to libosmocore; call those instead.
The return value of bssap_speech_from_lchan() used to be -1 on error, now the
error value is 0. The only caller did not handle -1 properly, but fed it
directly to a uint8_t.
On gsm0808_chosen_channel() error, log the error. Proper handling is missing.
Fixing the error handling in send_ass_compl() is a separate issue: currently it
is limited to logging, there is no way to return an error yet, nor any actions
to take on error.
Depends: Icca23940791f97fa64dbc3f2734270b99f9550c1 (libosmocore)
Change-Id: Ib5c940a9dae11c5e26d4b47fa9d95fef889ad2f6
In each code path within rsl_rx_chan_act_nack(), do separate logging of the
NACK to ensure proper termination of each log line.
When receiving a Chan Act NACK, we possibly mixed a LOGP() within an
unterminated other LOGP() that had not been ended with a LOGPC() yet.
Change-Id: Icd2772b21ef3a2ff5af11b7c92dff0ecb4d87ff0
When the BTS responds with a Chan Act NACK, i.e. the lchan could not be
activated, immediately signal Assignment Failure to the MSC (in
handle_chan_nack()).
In handle_chan_nack(), adjust log: instead of waiting for timeout, we now
signal Assignment Failure.
Drop misleading logging from bsc_assign_fail(): instead of transmitting the
Assignment Failure message, it actually signals an FSM event. Leave logging of
that to the FSM logging.
Change-Id: Ib204b4a5272f9b7b60ca5f932cd8a4c857316270
struct bsc_api was used to provide an abstract API for both osmo-bsc and
osmo-msc, between BSC and MSC. That's no longer needed, so get rid of it, to
prevent code turbulences it creates for no reason.
Change-Id: I3fd5888c63a0b4f95520a498320aa105a6d60579
Move all of libbsc/ into osmo-bsc/, and separate/move some implementations to
allow linking from utils/* and ipaccess/* without pulling in unccessary
dependencies.
Some utilities use gsm_network and gsm_bts structs, which already include data
structures for fairly advanced uses. Move initialization that only osmo-bsc
needs into new bsc_network_init() and bsc_bts_alloc_register() functions, so
that the leaner tools can use the old gsm_* versions without the need to link
everything (e.g. handover and lchan alloc code).
In some instances, there need to be stubs if to cut off linking "just before
the RSL level" and prevent dependencies from creeping in.
- abis_rsl_rcvmsg(): the only program currently interpreting RSL messages is
osmo-bsc, the utils are merely concerned with OML, if at all.
- paging_flush_bts(): ip.access nanobts models call this when the RSL link is
dropped. Only osmo-bsc actually needs to do anything there.
- on_gsm_ts_init(): the mechanism to trigger timeslot initialization is related
to OML, while this action to take on init would pull in RSL dependencies.
utils/ and ipaccess/ each have a stubs.c file to implement these stubs. Tests
implement stubs inline where required.
From src/utils/, src/ipaccess/ and tests/*/, link in .o files from osmo-bsc/.
In order for this to work, the osmo-bsc subdir must be built before the other
source trees. (An alternative would be to include the .c files as sources, but
that would re-compile them in every source tree. Not a large burden really, but
unless linking .o files gives problems, let's have the quicker build.)
Minor obvious cleanups creep in with this patch, I will not bother to name them
individually now unless code review asks me to.
Rationale:
1) libbsc has been separate to use it for osmo-nitb and osmo-bsc in the old
openbsc.git. This is no longer required, and spreading over libbsc and osmo-bsc
is distracting.
2) Recently, ridiculous linking requirements have made adding new functions
cumbersome, because libbsc has started depending on osmo-bsc/*.c
implementations: on gscon FSM and bssap functions. For example, neither
bs11_config nor ipaccess-config nor bts_test need handover_cfg or BSSMAP
message composition. It makes no sense to link the entire osmo-bsc to it, nor
do we want to keep adding stubs to each linking realm.
Change-Id: I36a586726f5818121abe54d25654819fc451d3bf
The TEST_SCAN_TO_MSC is completely unused, but still the code linked
bsc_scan_bts_msg() for the unused code path. This is unlikely to ever be
expanded. Remove TEST_SCAN_TO_MSC and reduce linking requirements.
(I am this close to dropping the test entirely to avoid continuous linking
annoyance, but ok, since nothing else tests timezones AFAIK, keeping it.)
Change-Id: I27521950432e412f919cde811c9473557d0ec25e
Rationale: channel_test is trivial and useless, probably only exists as a
legacy from openbsc.git.
- it tests two printf()s of "(bts=45,trx=0,ts=3,ss=4)", hardly useful.
- it tests ts_subslots() behavior for dyn ts, which will soon be replaced by a
most trivial mapping that does no longer need complex dyn ts state
evaluation (when introducing the new timeslot FSM to handle dyn TS switchover).
Change-Id: Ib2232da8e7fa964b92492d7b778320401dc97703
Rationale:
- All it does is compose four Paging Requests and feed it into the osmo-bsc
bssap_udt, and expects the cell identifier to be decoded properly.
- To do so it employs a comparatively huge linking effort. This linking effort
is becoming annoying in my ongoing work and is just not worth it.
- We have comprehensive cell identifier tests in ttcn3, verifying that the
proper cells are paged, and that actually for *all* cell identifier types.
Change-Id: I07cf23b66de36cfa1142a11b9f85e9c0190ee314
Only count paging responses which can be mapped to an active paging.
Unsolicited paging responses which do not correspond to an active paging
would increment the 'paging response' counter. This means the number of
paging attempts could be smaller than the number of paging responses,
which can look confusing in the 'show statistics' VTY command.
Change-Id: I7cfc7c29fb7570d41e3ac23cca17f5b98b303506
Related: OS#66
If we receive a BSSMAP ASSIGNMENT REQ for a speech channel
containing only a CIC but no AoIP transport layer address, then that's
illegal and must be rejected.
In Change-Id If362a0084de452727cd063063dfb645eca2f9beb we re-introduced
accepting CIC-only ASSIGNMENT REQ, but we failed to verify that this
actually only happens over a SCCPlite A interface.
This fixes the BSC_Tests.TC_assignment_cic_only testcase.
Change-Id: Ia6e3897edca48b9f838ea69939d9b8be7185abf8
The user might not want to enable LCLS support for administrative
reasons. So let's keep it disabled by default, until somebody
explicitly enables it with "lcls-mode mgw-loop".
In the future, we may want to introduce a "lcls-mode bts-loop" where we
don't loop at the BSC-colocated MGW, but where we instruct the BTSs to
feed the RTP directly to each other. This would require a
falt/transparent IP routing between the BTSs in the RAN.
Change-Id: Ied7985056c8cd182bf16119007a08cc5be14459b
Related: OS#1602
This code contains the following code:
* receive/parse/interpret LCLS specific BSSMAP IEs and PDUs
* osmo_fsm handling the various states and their transitions
* call leg correlation (finding the other subscr_conn with same GCR)
* communication between the two call-leg LCLS FSMs
* detection of supported / unsupported LCLS configurations
* display of GCR / LCLS information in "show conns"
* switch the media streams locally using MDCX to the MGW
Closes: OS#1602
Change-Id: I614fade62834def5cafc94c4d2578cd747a3f9f7
We now print information such as
* SCCP connection ID
* MSC number
* handover decision2 fail count
* channel mode (SIGN/SPEECH)
* MGW endpoint
* secondary lchan (if any, e.g. during assignment)
* don't crash if conn->lchan == NULL
Change-Id: I2f8000844afc9da93ca39976399e5f76a45530de
In doc/, add two message sequence charts with lots of implementation specifics,
to clarify the current code state. Mark various problems in red notes.
This chart and others should help to illustrate future code changes as I go
along refactoring handover, lchan allocation and adding inter-BSC handover.
Change-Id: I20999e938441d4fed2d37462b262b74a696f616d
Right now, it's impossible to see any ACC Ramping information unless RSL
category is set to DEBUG. Barring and Allowing Access Control Class is
an important event which should be printed in most cases.
Increase log levels of messages printed during some error conditions to
be handled as errors.
Change-Id: I5404e91fe7c0b3209e8033594e659387bbc924d6
It's not a good idea to keep extern declarations copied over
half a dozen C files. Let's move it to a header.
Change-Id: I6f643f1393ba0955d9c0cf1cf78d5c604e7b9451
The bsc_msc_connection dates back to the old pre-libosmo-sigtran
days, and 90% of the field members weren't used at all (even the
new sigtran specific ones!). Let's merge what remains into struct
bsc_msc_data.
As a side effect, the already dysfunctional "dest A.B.C.D" VTY
command has been removed from the MSC node.
There's quite a bit of fall-out in the CTRL interface, which was
the code with strongest ties to bsc_msc_connection. This was
resolved by properly porting CTRL handling over to libosmo-sigtran,
meaning that an IPA/SCCPlite connected MSC can now again send CTRL
GET/SET commands, and can also receive those selective few TRAPs
that old osmo-bsc-sccplite also sent to its MSC[s].
Change-Id: I6b7354f3b23a26bb4eab12213ca3d3b614c8154f
Related: OS#2012
osmo-bsc_nat is too heavily tied into legacy SCCPlite code, as it
is not using libosmo-sigtran/osmo_ss7 so far. It's also full of
customer-specific code and it's shared use of some libbsc code here
has been complicating osmo-bsc development.
The current plan is to continue to use osmo-bsc_nat from openbsc.git
for those legacy users that need it, and not use osmo-bsc_nat in
new 3GPP AoIP setups. Should we ever get a strong demand for an AoIP
based bsc_nat, we can still revisit this later.
Change-Id: Ia05dc76336a64a7f08962843b9a7cc19f2c83387
In IPA/SCCPlite, the MSC is handling MGCP to the BSC-MGW directly
and the BSC only takes care of the BTS-side MGCP connection. We
achieve this by transitioning directly from WAIT_MDCX_BTS into ACTIVE
in this case.
Change-Id: I96179b4324b976bded36023a8ccbdc007b6b3e05
Related: OS#2544
In IPA/SCCPlite, we have to use the CIC to construct the MGCP
endpoint name instead of the usual dynamic endpoint allocation.
Change-Id: I03e2cdbc8e40169e52df3720c40b66734e880525
Also: Move mgcp_timeslot_to_port() next to it, as they are
more or less the inverse transformation of each other.
Change-Id: Ica908e2bb8fc4e59e0d146b428c93a9efc385688
We used to have hard-coded M3UA. Let's allow the user to configure
this per MSC using a new "asp-protocol (m3ua|sua|ipa)" VTY command.
For SUA this should just work 1:1 without any trouble. For IPA,
this of course only changes the underlying transport without reflecting
the various differences in terms of BSSMAP ASSIGNMENT, MGCP handling,
etc.
Change-Id: I0800c709e574cedd7f5dd98be81c78782245cd13
Related: OS#2544
In gscon_fsm_wait_mdcx_bts() we try to allocate conn->user_plane.fi_msc
but then check whether conn->user_plane.fi_bts is set, possibly due to
a copy+paste error. Let's fix that.
Change-Id: I1f515910f67492257866791588f32b350fadf815
Use memcpy() to avoid unaligned access, instead of writing through a
pointer cast to uint32_t. Problem spotted by address sanitizer:
abis_nm.c:2802:24: runtime error: store to misaligned address 0x7ffc95396706
for type 'uint32_t', which requires 4 byte alignment
0x7ffc95396706: note: pointer points here
81 0b bb 80 00 00 00 00 ed 79 28 56 00 00 e0 9c 00 00 a0 61 00 00 ...
^
Related: OS#3196
Change-Id: I8e591a56ae522b371da01ea968151a7e6fa24bb9
The state ST_WAIT_MODE_MODIFY_ACK can never be reached by the
current FSM model.
- Remove ST_WAIT_MODE_MODIFY_ACK and all related code
Change-Id: Iacaae2ee50ca1956066b7dce4517bbc9c2b0897e
Related: OS#2762
* Check the message length once at the start, before any other actions.
* Use only one local gsm48_hdr pointer.
* Read the cause value once near the top, re-use it.
* Log "ASSIGNMENT COMPLETE" always, not only during handover.
* Fully initialize local struct lchan_signal_data.
Change-Id: Idcfd932d3dfb0b621ed6d8c4f92c0231abcdcec8
bsc_api.c notoriously lacks log context. Provide gsm_lchan_name() and/or
bsc_subscr_name() in roughly a million instances, using new LOGPLCHAN macro.
Add LOGPLCHAN() to gsm_data.h, to encourage use of it in other .c files.
Change-Id: If469defcc6fe8950dac5df61db3f39d297893318
Default usage values are defined in mgcp node, and can be per-BSC
overriden on each bsc node.
This commit is a forward-port of openbsc.git Change-Id
Ibf3932adc07442fb5e9c7a06404853f9d0a20959.
Depends on osmo-mgw.git Change-Id Ie19a64ac09f9d51f2434ad0d7925610fc919a90e.
Change-Id: Ie07b8a577caf731d59d68e3b3510ae2f9fd3dc93
Add a global counter to the BSC which shows the number of failed
connections attempts due to a unit_id mismatch between the BSC
and the BTS.
Change-Id: I58866aff36a1c8463bf84b4392a5124ffeaa32ea
Related: OS#3245
The 'show statistics' VTY command was not showing all counters
maintained by osmo-bsc. Instead of printing just two counters
related to paging, print all available counters in a generic way.
Adjust descriptions of some counters for nicer display.
After startup (all counters are zero) is now looks like this:
OsmoBSC# show statistics
handover:attempted: 0 Received handover attempts.
handover:no_channel: 0 Sent no channel available responses.
handover:timeout: 0 Timeouts of timer T3103.
handover:completed: 0 Received handover completed.
handover:failed: 0 Received HO FAIL messages.
paging:attempted: 0 Paging attempts for a subscriber.
paging:detached: 0 Paging request send failures because no responsible BTS was found.
paging:responded: 0 Paging attempts with successful response.
OsmoBSC#
Change-Id: I58ae04e1960774d760e3ebb54a4f307c9f753655
Related: OS#3245
The function a_reset_free() is not used anywhere at the code. The
reason for this is that a BSC instance is never cleared once it
is started up. Also the timer number is not according to the spec.
- Remove a_reset_free()
- Fix timer identification number (T4)
- use fi->priv to hold context info
- Fix sourcecode formatting
Change-Id: I72095d52304c520e383755eee6c889bce492cbd4
Related: OS#3102
Reshuffle the decision not to activate PDCH when GPRS is off:
Even though all current callers should avoid passing a PDCH activation in case
GPRS is off, it's a better idea to not assert on it and crash osmo-bsc.
Move the decision to omit PDCH activation and logging about it into the actual
functions that do PDCH activation. If PDCH activation is skipped, the lchan
then just stays as it was, and that's what it should anyway be doing.
Change-Id: Ib26642f08044d71a2469e6dbabf1e6fbcb02044d
In osmo-nitb, the way TCH lchans were assigned often resulted in mismatching
TCH kinds, causing problems in the lack of transcoding. Hence
dyn_ts_allow_tch_f was introduced as a workaround.
Now however, we always assign an SDCCH to a requesting MS first, and only later
assign a TCH channel, which then adheres to the codec list configured at 'msc'
in the vty config. Hence it is now considerably harder to obtain a mismatch.
Furthermore, forcing specific codecs is possible by simply omitting the
unwanted ones from the msc config's codec-list. The equivalent of
'dyn_ts_allow_tch_f 0' could be e.g. 'codec-list hr3 hr2 hr1'.
Change-Id: Ib2335d02ea545aff837aadd49f15b2fdb418c46e
In rsl_chan_activate_lchan(), remove a condition to also allow switching pchan
modes when not in PDCH mode, which is actually not needed and would hinder
switching from pchan=NONE or between TCH/F <-> TCH/H.
Refactor the part where lchan_alloc() decides to switch a pchan mode into a
separate function, ts_usable_as_pchan(), which transparently checks both dyn TS
kinds for:
- Already in switchover? (missing check for ip.access style dyn TS)
- Is the lchan->state in error? (missing check for ip.access style dyn TS)
- Switch from pchan=NONE? (missing feature for Osmocom style dyn TS, for proper
handling with gprs mode none)
- Switch between TCH/F <-> TCH/H when all subslots are unused?
(missing feature for Osmocom style dyn TS, also useful for gprs mode none)
Always pass the desired pchan in the dyn_as_pchan argument to the _lc_find_*
functions to make switchover decisions transparent. Use the _lc_dyn_find_bts()
function for ip.access style dyn TS for the same reason.
Related: OS#3244
Change-Id: I72d5d833b186b1e1925d513885b405d8c19aa496
Recent Icf6e25ff068e8a2600562d52726ead65e864ec02 changed the dyn_ts_init() hook
from bootstrap_rsl() to the Channel OPSTART ACK, but this is not sufficient.
Now RBS2k never calls dyn_ts_init(), and we may need to wait for RSL:
Dyn TS should actually be initialized only when *both* OML opstart and RSL link
are established. To that end, introduce a generalized API to query OML and RSL
status and to trigger a timeslot init at the appropriate time.
Add gsm_ts_check_init() to be called both when RSL and OML opstart are
established: trigger gsm_ts_init() only when both are given.
Add gsm_bts_trx_ts->initialized flag to mark whether initialization has already
taken place. Add gsm_bts_mark_all_ts_uninitialized() to conveniently clear this
flag for all TS in a BTS.
Add gsm_bts_model.oml_is_ts_ready() callback so that each BTS implementation
can return the OML status of a timeslot in its own OML implementation.
Actually, currently all BTS models that need this init mechanism store the TS'
OML status in ts->mo.nm_state. While we would in practice correctly init dyn TS
by just looking at ts->mo.nm_state, semantically, the decision whether the TS
is ready is up to the BTS models' specific OML implementations.
From bootstrap_rsl(), call gsm_ts_check_init(), in case the TS OML Opstart has
happened before RSL is established -- applies to all BTS models.
For all BTS models:
- call gsm_{bts,trx}_mark_all_ts_uninitialized() when OM is torn down, to make
sure the TS init mechanism will work a second time.
For all BTS models supporting dyn TS, i.e. osmo-bts, nanobts and RBS2k:
- implement oml_is_ts_ready().
- call gsm_ts_check_init() when a Channel OM is taken into operation.
Any BTS models that don't set oml_is_ts_ready() will see a ts init as soon as
RSL is bootstrapped (incidentally, the old dyn TS behavior before recent
Icf6e25ff068e8a2600562d52726ead65e864ec02).
This firstly fixes dyn TS for RBS2k by re-adding the initial switch to PDCH,
and furthermore does so only after both OML TS opstart and RSL are through.
This fixes the ttcn3-bsc-tests around dyn TS, since for the osmo-bts-virtual,
the RSL is established only after OML opstart on the TS, which was broken by
Icf6e25ff068e8a2600562d52726ead65e864ec02.
Nokia Site and Siemens BS11 practically do not require this init mechanism,
since all that happens there so far is dyn TS init, and these BTS models do not
support dyn TS of any kind. A future patch may add oml_is_ts_ready().
Related: OS#3205
Change-Id: I99f29d2ba079f6f4b77f0af12d9784588d2f56b3
Previously the MGW configuration was ignored during writing
of the MSC configuration. Let's fix this by calling the
mgcp_client_config_write() function.
Change-Id: I7d1eedb782a4f30bd089838969ce54f27cde060d
Typically, an lchan that is released should no longer be associated with
subscriber connection. If that is the case, an S_LCHAN_UNEXPECTED_RELEASE is
triggered, which aborts, e.g., an ongoing assignment.
However, with dynamic timeslots, we may set lchan->conn and then start to
switch over from PDCH to a TCH mode, in which case it is perfectly fine to
release an lchan that is associated to a conn.
In lchan_free(), do not fire S_LCHAN_UNEXPECTED_RELEASE for a dyn TS that is
currently in switchover.
This is the second and last part to fix dynamic timeslots handling of the
gscon.
Related: OS#3211
Change-Id: Id7d9dd06451722eb328db77bb586826c954bd85c
Set lchan->state to LCHAN_S_ACT_REQ in rsl_chan_activate_lchan(), not in
handle_new_assignment().
This is the first part of a fix for dynamic timeslots handling in the gscon.
Rationale:
In rsl_chan_activate_lchan(), we may choose to set the lchan state to
LCHAN_S_REL_REQ and wait for dyn TS switchover from PDCH.
So the caller from bsc_api.c handle_new_assignment() must not bluntly set the
state to LCHAN_S_ACT_REQ, which is not accurate in the case of dyn TS
switchover.
In case of dyn TS switchover, a later release ack received from the BTS will
cause rsl_chan_activate_lchan() to be called again, at which point we may
accurately set state LCHAN_S_ACT_REQ, and continue the Assignment.
Related: OS#3211
Change-Id: Iedb4fb63bf1959d5f1d2c6edb6a7f5097ff16bd7
Sending PDCH activation upon RSL bootstrap is too early. Introduce OPSTART ACK
handling to call dyn_ts_init() only when the dynamic timeslot is indeed ready
to receive a PDCH activation.
Related: OS#3205
Change-Id: Icf6e25ff068e8a2600562d52726ead65e864ec02
At this point, meas-feed is usable again, however, osmo-bsc is not able to
include the IMSI in every report like osmo-nitb did.
In consequence, the meas-vis and meas-web tools are unable to handle the
current measurement reports: these so far use the IMSI to list reports, and all
reports without an IMSI are collapsed onto the same line, swapping values.
So though osmo-bsc now sends usable measurement reports via meas-feed, two
avenues to improve should be pursued:
OS#3192: the visualization tools should use bts,ts,ss numbers, not IMSI.
OS#2969: osmo-bsc should always know a mobile identity.
Related: OS#2968
Change-Id: I186c7a995dd2b81746c32a58b55da64ed195a1ce
gsm0808_assign_req() checks if the new channel mode is compatible
with the new mode. If it is, it does a gsm48_lchan_modify(), but
it does not actually check if the new mode is equal to the current
mode.
- skip when the channel is compatible and the new mode is equal to
the old mode.
- send the ASSIGNMENT COMPLETE directly from ST_ACTIVE when no
mode modify was necessary.
Change-Id: I86a2d52836c54d2dbd77441b182f757327ec7262
Related: OS#2936
meas_feed.c used to live in libmsc, to send out measurement reports to external
entities for evaluation. When splitting osmo-bsc and osmo-msc from openbsc.git,
meas_feed.c should have moved to osmo-bsc.git, but was dropped with libmsc.
Re-add the old meas_feed.c now into libbsc. This is the latest version that
existed in libmsc, and will not compile as-is here. Modifications to
incorporate in the osmo-bsc build will follow with subsequent patches.
Change-Id: Ic070d82e61c122061fe7297a8c5aabbbcef6b301
Flush the paging queue if the link to TRX 0 is dropped from a BTS.
This should prevent stale paging requests sent to the BTS when it
disconnects or reconnects, as seen in the TTCN3 BSC_Tests test suite.
Also, add entries to the log when RSL or OML links are dropped so
that related error messages in the log can be interpreted in context.
Change-Id: If4401c1139cd01faf5ff374301a9a701898c3777
Related: OS#2901
Move to its own function, store pointer to proper header format and use
the already defined IE define from libosmocore instead of using
hardcoded values.
Depends on: Change-Id I7cb65f3ff1cfdbe4eee97b7545bcd13a38c72e25
Change-Id: I845fd3f0c6ff31f268f68a31e1d55981f7ec6129
If the OML link is found down while a paging request is issued,
no paging message is sent. However, we were still counting such
pagings as an actual attempt, and counted them towards the number
of available slots on the paging request queue.
Move the OML link check to the caller of page_ms() where the
accounting steps can be properly skipped as they should be.
Change-Id: I5b6db681da7d45c49e1f2f99d7789c8a29372ef3
Related: OS#2901
On the assignmen of signalling channels, the voice related fields
do not play a role. However the function send_ass_compl() that
generates the assignment complete message is very strict about the
presence of those voice related parameters.
- Add a parameter to function send_ass_compl() to generate the
different types of assignment complete messages
Change-Id: I316ebcb1f27b668e17fe48fff028e047aac47f76
Related: OS#2762
Since libosmocore 7c0031fc8063771e604976233fb7b46d2b85c077, the cmd
param passed to handlers in ctrl_handle_msg is always freed afterwards,
thus it is owned by the same function. Avoid keeping it alive and
accessing it later when it has already been freed.
Related: OS#3157
Change-Id: I764917f641b170597e405f1865b0f7b94bae1597
The SUBSCR_CONN (GSCON) fsm starts a timer (993210, 20sec.) when the
CR to the MSC is made. When the timer reaches its timeout, then the
SUBSC_CONN FSM terminates. Such a timeout event is also an indicator
for a bad SCCP connection so we should call a_reset_conn_fail() to
inform the A-RESET FSM about the event in order to cause a BSSMAP
reset when too many timeouts occurr consecutively
- Call a_reset_conn_fail() when 993210 expires
Change-Id: I836a552f2ad37c160081246579f842d104d0dd35
Related: OS#3102
Take both the operative and administrative states into account
when deciding whether to start ACC ramping, and examine old/new
state values to avoid triggering ramping for a no-op state change.
This requires a fix to gsm_trx_lock_rf(): This function overwrote
the old administrative state of a trx before enqueuing a state
change request towards the BTS.
The BTS will confirm this request with an ACK, at which time a
signal is generated which the ACC ramp code listens to. We must
not overwrite the old state value until the signal has been handled,
otherwise the signal handler cannot tell what the old state was.
Tested with a virtphy setup, nanobts, and osmo-bts.
Change-Id: Ib3291439655598fb5ddc891a3e4cc35b0bad250f
Related: OS#2591
Starting an ACC ramping process while TRX 0 is unusable or locked is
pointless. For instance, after loading a config with 'rf_locked 1'
for trx 0, the ramping process was started as soon as the BTS
established RSL, even though the air interface was still down.
ACC ramping should instead be triggered once TRX 0 is unlocked.
Change-Id: I054829a936f0aa1e3fa34fad6466a1cd6150e307
Related: OS#2591
Trigger ACC ramping not only when an Administrative State Change
ACK is received from a BTS, but also when an administrative state
change is reported for TRX 0 in a State Changed Event Report.
This should allow ACC ramping to work with any BTS which reports
an administrative state change to 'unlock' using either of these
OML messages.
Tested with a sysmobts and a nanobts.
The sysmobts only reports TRX locked/unlock changes in Administrative
State Change ACKs, not via State Changed Event Reports.
The nanobts is known to send both of these OML messages in quick
succession, so do not re-trigger ramping if it's already in progress.
Change-Id: I097a113a3a63de02bcb8277020beb59cf485b176
Related: OS#2591
The word 'enabled' was used in two contexts: Whether ACC ramp is
enabled as a feature, and whether a particular access control class
is permantly allowed/disallowed via VTY configuration.
Rename some helper functions to avoid the use of the word 'enabled'
in the latter context.
Change-Id: Ia67e84270cd50f4c55b8cf616ca38b00482f765c
Related: OS#2591
Make ACC ramping listen to network management signals and trigger
or abort ACC ramping based on the RF locked state of TRX 0.
This works as expected with a virtphy setup when RF lock state is
changed via VTY. However, this change still needs to be tested with
a nanobts. It's also not quite clear yet whether operational state
changes, as opposed to administrative ones, should be taken into
account as well.
Change-Id: I4124f1da3dadec003de45c1da8435506ee8f0a34
Depends: Ia25bff85d9e5c277da76bffa11d31972e9fdc323
There are plans to register signal handlers in acc_ramp_init(). Once we
do that, the acc_ramp_init() function should only be called once to
avoid duplicate signal handlers on the handler list.
However, the acc_ramp_init() function currently serves a dual-purpose:
1) Initialize the acc_ramp structure for a bts
2) Enable or disable ACC ramping
Add new functions to support use case 2, and call acc_ramp_init()
just once while reading the configuration file. The VTY commands
which enable/disable ACC ramping use the new APIs instead.
Also, rename acc_ramp_start() to acc_ramp_trigger() and tweak its
semantics so that it can always be called regardless of what the
current configuration settings are. This prepares us for triggering
ACC ramping upon events other than "RSL link-up".
Change-Id: Ia25bff85d9e5c277da76bffa11d31972e9fdc323
Related: OS2591
It can be obtained from cmd field, so no need to store it in pending.
This way we simplify the ad-hoc struct bsc_cmd_list.
Change-Id: I6de64fc128ad623ca30b9e6cebebaff8de18f95d
Silence log messages about no-op changes to access granted to access
control classes. For example, these always occur while configuration
files are being loaded.
Change-Id: I37580f4058f6e3a21d338234b1e22ea46f9538c6
Related: OS#2591
Remove a redundant call to acc_ramp_init() during bootstrap_bts().
ACC ramping state is already initialized during VTY config parsing,
and bootstrap_bts() accidentally disabled ACC ramping again even
if it was enabled in the configuration.
This bug was introduced in last-minute refactoring during
review of https://gerrit.osmocom.org/#/c/6324/ when the
acc_ramping_enabled flag was moved from struct gsm_bts to
the acc_ramp structure itself.
Also remove an acc_ramp_init() call in bootstrap_rsl().
It is no longer needed as it serves no purpose other than
initializing the bitmasks of barred ACCs. To ensure that
ACC ramping configuration provided to the BTS via system
information stays correct, we move the call to acc_ramp_start(),
which has the same effect on barred ACCs, further up.
Change-Id: Ib7d99c9d3d5d424e21bb7710f719c42f9aef3e95
Fixes: 6442e4327b
Related: OS#2591
In a debug log message, an unsigned 64-bit value was printed with
%lu but it should be printed with PRIu64 from inttypes.h instead.
Change-Id: I09bb519e68886e650647b1369fd49d1964e76c7e
So far we only used to show the current mode of the timeslot for IPA
style dynamic PDCH, but not for osmocom-style.
Old output for osmocom-style dyn PDCH:
BTS 0, TRX 0, Timeslot 6, phys cfg TCH/F_TCH/H_PDCH, TSC 7
NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
new output with this patch:
BTS 0, TRX 0, Timeslot 6, phys cfg TCH/F_TCH/H_PDCH, TSC 7 (PDCH mode)
NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
where "PDCH mode" changes from "NONE mode" to "TCH/F mode" to "TCH/H mode"
depending on the current state.
Change-Id: If5044d6bec76b869bd6a7c0260a4c77e229dcd0d
Related: OS#3099
We used to start the dynamic PDCH initialization right after the
respective OML initialization of the related timeslot. However, this
is problematic as the RSL link may very well not even be up yet at
that point. So let's do this at RSL link esetablishment time, not
from OML.
Change-Id: I8ac30ca075a1db4b624dc38a423d844d705fda7e
Closes: OS#1841
The S_L_INP_TEI_UP signal was generated when the first message from a BTS
arrives on the OML/RSL link, rather than when the OML/RSL link comes up.
Instead, generate this signal when the link is brought up, so we
intitialize state regardless of how a particular BTS behaves.
Tested with osmo-bts-virtual and virtphy/mobile programs,
and with a sysmobts.
This was already committed in faf0982ae2
but subsequently reverted in 383a059a12
because it introduced a regression. The underlying problem causing this
regression has now been addressed by https://gerrit.osmocom.org/#/c/7462/
(libosmo-abis commit 49917c129b1456585258b0ebe89a513ecef823a8).
Change-Id: I78a152671a00b95c997830f7161fca92bb898fa3
Depends: I52f7c903212b38e9c87e4d45e52b231b6f1ae9f5
Related: OS#2719
Legacy VTY commands were removed in commit
c74a5616bf
== I5cf3fec31cc774c902f3cfe6d16fb85ef301694a
Removing the dead VTY commands currently breaks our ttcn3-bts-test and is
likely to create problems with users of osmo-bsc, when their config osmo-bsc
stops working with a mere upgrade.
Instead, add deprecated dummy commands that don't do anything, to not break
existing configs.
Catch all of these legacy commands:
timeout-ping <number>
timeout-pong <number>
timeout-ping advanced
no timeout-ping
no timeout-ping advanced
by defining
timeout-ping ARG
timeout-pong ARG
no timeout-ping [ARG]
I verified manually that starting osmo-bsc with all the abovementioned VTY
commands in the config file works (and produces the deprecation messages).
Change-Id: I95a5bad1ade66ded849cfc20bebb7fc522aecc38
There is a lot of dead code in osmo_bsc_msc.c that used to handle
the IPA multiplexed SSCP lite A interface.
- remove portions of the dead code
- remove IPA Ping related VTY commands
Change-Id: I5cf3fec31cc774c902f3cfe6d16fb85ef301694a
Fix various sanitizer complaints about memory leaks using a sanitizer build
with gcc (Debian 7.3.0-12) 7.3.0.
Also fix deprecation warnings on osmo_init_logging().
Depends: I216837780e9405fdaec8059c63d10699c695b360 (libosmocore)
Change-Id: I970c6f8a0e36a8b63e42349dbc92baff649e5cef
gsm_bts_alloc() ought to do all static initialization, so that e.g. unit tests
can use an initialized bts struct that is fully usable, just not registered at
the gsm_network.
For example, two INIT_LLIST_HEAD() and various system information data pointers
(pointing to proper places within the same bts struct) should definitely never
be omitted.
This fixes the remaining errors of gsm0408_test's SI tests, as revealed by a
sanitizer build using gcc (Debian 7.3.0-12) 7.3.0.
Fixes:
../../../../src/osmo-bsc/src/libbsc/system_information.c:613:3: runtime error: null pointer passed as argument 1, which is declared to never be null
Initializing the bts->si_common.rach_control results in different expected
bytes for SI2. The initialized values are
bts->si_common.rach_control.re = 1; /* no re-establishment */
bts->si_common.rach_control.tx_integer = 9; /* 12 slots spread - 217/115 slots delay */
bts->si_common.rach_control.max_trans = 3; /* 7 retransmissions */
bts->si_common.rach_control.t2 = 4; /* no emergency calls */
Causing a change to e5 04. 04 is t2 = 4, and the remaining values are verified by:
uint8_t re :1,
cell_bar :1,
tx_integer :4,
max_trans :2;
>>> hex(1 + (9 << 2) + (3 << 6))
'0xe5'
Change-Id: I13ef24bbe0f1fbe49465e67a0b67d6fd69fff3b1
Add missing deletion of osmo_stat_item_group_free(bts->bts_statg).
Add missing bts free after test_si_ba_ind().
Log deallocation, update expected test output.
This fixes some of the errors of gsm0408_test's SI tests, as revealed by a
sanitizer build using gcc (Debian 7.3.0-12) 7.3.0.
Fixes:
=================================================================
==19273==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000004b8 at pc 0x7f1561a94621 bp 0x7ffe7a7a64a0 sp 0x7ffe7a7a6498
WRITE of size 8 at 0x60d0000004b8 thread T0
#0 0x7f1561a94620 in __llist_add ../../../src/libosmocore/include/osmocom/core/linuxlist.h:75
#1 0x7f1561a94620 in llist_add ../../../src/libosmocore/include/osmocom/core/linuxlist.h:90
#2 0x7f1561a94620 in osmo_stat_item_group_alloc ../../../src/libosmocore/src/stat_item.c:141
#3 0x5574f6a19935 in gsm_bts_alloc ../../../../src/osmo-bsc/src/libbsc/gsm_data.c:728
#4 0x5574f6a12920 in bts_init ../../../../src/osmo-bsc/tests/gsm0408/gsm0408_test.c:123
#5 0x5574f6a0ddb3 in test_si2q_e ../../../../src/osmo-bsc/tests/gsm0408/gsm0408_test.c:192
#6 0x5574f6a0ddb3 in main ../../../../src/osmo-bsc/tests/gsm0408/gsm0408_test.c:824
#7 0x7f156061aa86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#8 0x5574f6a10339 in _start (/n/s/dev/make/osmo-bsc/tests/gsm0408/gsm0408_test+0xfc339)
Change-Id: I1ebbd8cc0622ce1a061e933813829b1f770072dc
If size <= 1, avoid allocating arfcns_left[size / 2], which results in a zero
size and causes, with gcc 7.3.0 sanitizer, runtime errors:
../../../../src/osmo-bsc/src/libbsc/arfcn_range_encode.c:95:6: runtime error: variable length array bound evaluates to non-positive value 0
../../../../src/osmo-bsc/src/libbsc/arfcn_range_encode.c:96:6: runtime error: variable length array bound evaluates to non-positive value 0
This fixes some of the errors of gsm0408_test, as revealed by a sanitizer build
using gcc (Debian 7.3.0-12) 7.3.0.
Change-Id: Idab2a194fb9d7c41ed3367f935080eaae4ce367f
We deliberately ignore errors from page_subscriber() so there is
no point in having a non-void return value.
Provide more context in the error message logged if paging failed.
Add a comment in an implementation override of base_grace_paging_request()
in the test suite to make return value semantics more clear.
Change-Id: Ie18c2ba53d2055d3eaff8c9ed939eb844af6dd2e
Related: I48f5efbcddd98e15256edfca06ba0ae6acb5bab1
The GSCON fsm has two illegal state transions. The transions
themselves are logically legal but theur respective entries
in out_state_mask are missing.
- remove unnecessary transition from ST_ACTIVE to ST_ACTIVE
- Add ST_CLEARING to the out_state_mask of ST_WAIT_HO_COMPL
Change-Id: I165c3e8b4b268b50e5f4a482b0fe890e940637b3
Closes: OS#3109
Fixes following compilation warning:
bts_nokia_site.c:1248:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return ret;
This could happen if parameter len is passed with value 0.
If we reach the end of the function, it means everything went fine, so
we can return 0 instead of using ret, which is only used to store error
code before returning.
Change-Id: Ic60c8c632a6ddadb8f197d56cc68c2dbfc121d05
The BS-11 related tool bs11_config is currently not built due
to dependancy issues added by GSCON FSM.
- Re-Add bs11_config to makefile.am
- Add dependencies and stubs
Change-Id: I77ee8d2d36813ad98542317d003a9057c4f84e75
Related: OS#2823
The nanobts related tool ipaccess-config is currently not built due
to dependancy issues added by GSCON FSM.
- Re-Add ipacces-config to makefile.am
- Add dependencies and stubs
Change-Id: I1d0a45bed61b45352ed305b6b1fd8d9b3d3cecae
Related: OS#2823
The LAI encoding test in gsm0408_test.c uses deprecated API, and a more
thorough test for LAI encoding has been added in libosmocore/test/gsm0408/.
Change-Id: I8a55d717ab15ba23943a2639accaadc33a4f731a
Correctly compute the TS 48.008 "speech mode" (codec) for AMR on TCH/F.
There are way too many different ways how to express a given voice
codec. There are two different schemes in TS 48.008 alone, plus one
on TS 48.058 and one in 04.08 / 44.018. Let's avoid unneeded
conversion (that we might get wrong) and avoid storing information in
a sub-struct of the lchan if we can simply derive it from the lchan
at the time we need it.
Also, move BSSAP related encoding/conversion functions closer to the
user (osmo_bsc_bssap), rather than in libbsc.
Without this patch, TCH/F with AMR was erroneously reported as TCH/H
with AMR in the BSSMAP ASSIGNMENT COMPLETE. After this patch, it's
reported correctly.
Change-Id: I6feebfae77fdc93a7ce333a25dd9b9267c5a4a2e
Related: OS#3094
Related: OS#3095
Related: OS#3096
The first argument is the channel mode (codec), the second one is
a flag whether or not it's a full-rate channel.
Before this patch the two arguments are reversed, resulting in
* all assignments being TCH/F in general
* all assignments have FR1 as codec, as the full_Rate=1 is interpreted as FR1
Change-Id: I80f2a016a7646252bce8d86ed0bab236f3adbfca
Related: OS#3094
In AMR-type cahnels, the gsm0808_speech_codec doesn't only include
the codec (like EFR/FR/AMR) but also the specific codec configuration,
i.e. the sub-set of AMR modes.
Hence, we cannot convert from a channel type (just the codec) to the
full gsm0808_speech_codec and then memcmp() that with the codec config
received from the MSC. Rather, we must only compare the *type*.
Change-Id: I0a3f362667a689135d5b62d151d491490dfd2976
Related: OS#3094
The order of the arguments for forward_dtap() differs from
submit_dtap() and sigtran_send()
- bring arguments into a uniform order for all three functions
Change-Id: Ida77c82e600f99d690ffa1850450925359e33ae8
Related: OS#2823
Preceding commit I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8 changed the
ipac_bcch_info.cgi type to osmo_cell_global_id, but did not carry out
corresponding changes in ipaccess/network_listen.c.
The reason this was not caught is that recent commit
I68286d26e2014048b054f39ef29c35fef420cc97 adding the new gscon FSM actually
disables ipaccess-config in the build.
Fix the build, given that ipaccess-config were re-enabled.
Change-Id: I15cd58e8ba0563ce4e42a61e79d01394b61593dd
Instead of a local redefinition, use osmo_cell_global_id.
This change is cosmetic because the decoded PLMN is currently actually never
used.
Change-Id: I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8
This error message suggested that parsing a cell identifier list
failed because the list was too short. While, in fact, this code
has no insight into the reason behind the parsing failure.
A generic error message is more appropriate.
Change-Id: I033747e2183984159f1505e772d7c9494b759058
Related: OS#3073
This code is among the oldest surviving parts of old bsc_hack/OpenBSC,
and it shows. We used arcane constructs to puzzle together log
messages, attempting to switch the log level between a LOGP and LOPGC
[which doesn't work], not properly used log levels in general, ...
Let's fix this up by using the new abis_nm_dump_foh() function
introduced in libosmocore I9b2c2afec28882b817d104d5b062651ade7aadd8
Change-Id: Ibd757836c39edd2d1ce59e528342f8923a9e75e4
Fixes following compilation warning:
osmo-bsc/tests/handover/handover_test.c:48:83: warning:
‘struct mgcp_conn_peer’ declared inside parameter list will not be visible outside of this definition or declaration
int __real_mgcp_conn_modify(struct osmo_fsm_inst *fi, uint32_t parent_evt, struct mgcp_conn_peer *conn_peer);
^~~~~~~~~~~~~~
Change-Id: I1b5e91adee3daaec71122a7691a214aa8240bce2
Print a clear error when the format in not correct. I was in the
situation several times in which I was passing "123" instead of
"123/0/0", and spent a while seeing what was wrong.
Change-Id: I70906939b3320473c56a87929c4886aac9d7d064
Interestingly, SO_BINDTODEVICE used to bind to a specific iface
requires root permissions. However, the same target can be accomplished
by binding to a local IP addr set on the target interface, which doesn't
require root permissions in this case.
Change-Id: Ie123c45005d68b186cb06538f7bd31f3b2513007
In the current implementation of osmo-bsc, the subscriber connection is
not handled (very) statefully. However, there is some state keeping in the
code that handles the mgcp connection, but there are still to much loose ends
which allow odd situations to happen, which then lead severe error situations
(see also closes tags at the end) This commit adds a number of improvements
to fix those problems.
- Use an osmo-fsm to control the gsm_subscriber_connection state and
make sure that certain operations can only take place at certain states
(e.g let connection oriented SCCP traffic only pass when an SCCP connection
actually exists.
Remove the old osmo_bsc_mgcp.c code. Use the recently developed MGCP client
FSM to handle the MGCP connections.
Also make sure that stuff that already works does not break. This in
particular refers to the internal handover capability and the respective
unit-tests.
See also OS#2823, OS#2768 and OS#2898
- Fix logic to permit assignment to a signalling channel. (OS#2762)
- Introduce T993210 to release lchan + subscr_conn if MSC fails to respond
The GSM specs don't have an explicit timer for this, so let's introdcue
a custom timer (hence starting with 99).
This timeout catches the following situation:
* we send a SCCP CR with COMPL_L3_INFO from the MS to the MSC,
* the MSC doesn't respond (e.g. SCCP routing failure, program down, ...)
The MS is supposed to timeout with T3210, 3220 or 3230. But the BSC
shouldn't trust the MS but have some timer on its own.
SCCP would have a timer T(conn est), but that one is specified to be
1-2min and hence rather long.
See also: OS#2775
- Terminate bsc_subscr_conn_fsm on SCCP N-DISC.ind from MSC
If the MSC is disconnecting the SCCP channel, we must terminate the FSM
which in turn will release all lchan's and other state.
This makes TC_chan_rel_hard_rlsd pass, see also OS#2731
As a side-effect, this fixes TC_chan_act_ack_est_ind_refused(),
where the MSC is answering with CREF to our CR/COMPL_L3.
- Release subscriber connection on RLL RELEASE IND of SAPI0 on main DCCH
The subscriber connection isn't really useful for anything after the
SAPI0 main signalling link has been released. We could try to
re-establish, but our best option is probably simply releasing the
subscriber_conn and anything related to it.
This will make TC_chan_rel_rll_rel_ind pass, see also OS#2730
This commit has been tested using the BSC_Tests TTCN3 testsuit and the
following tests were passed:
TC_chan_act_noreply
TC_chan_act_ack_noest
TC_chan_act_ack_est_ind_noreply
TC_chan_act_ack_est_ind_refused
TC_chan_act_nack
TC_chan_exhaustion
TC_ctrl
TC_chan_rel_conn_fail
TC_chan_rel_hard_clear
TC_chan_rel_hard_rlsd
TC_chan_rel_a_reset
TC_rll_est_ind_inact_lchan
TC_rll_est_ind_inval_sapi1
TC_rll_est_ind_inval_sapi3
TC_rll_est_ind_inval_sacch
TC_assignment_cic_only
TC_assignment_csd
TC_assignment_ctm
TC_assignment_fr_a5_0
TC_assignment_fr_a5_1_codec_missing
TC_assignment_fr_a5_1
TC_assignment_fr_a5_3
TC_assignment_fr_a5_4
TC_paging_imsi_nochan
TC_paging_tmsi_nochan
TC_paging_tmsi_any
TC_paging_tmsi_sdcch
TC_paging_tmsi_tch_f
TC_paging_tmsi_tch_hf
TC_paging_imsi_nochan_cgi
TC_paging_imsi_nochan_lac_ci
TC_paging_imsi_nochan_ci
TC_paging_imsi_nochan_lai
TC_paging_imsi_nochan_lac
TC_paging_imsi_nochan_all
TC_paging_imsi_nochan_plmn_lac_rnc
TC_paging_imsi_nochan_rnc
TC_paging_imsi_nochan_lac_rnc
TC_paging_imsi_nochan_lacs
TC_paging_imsi_nochan_lacs_empty
TC_paging_imsi_a_reset
TC_paging_counter
TC_rsl_drop_counter
TC_classmark
TC_unsol_ass_fail
TC_unsol_ass_compl
TC_unsol_ho_fail
TC_err_82_short_msg
TC_ho_int
Authors:
Harald Welte <laforge@gnumonks.org>
Philipp Maier <pmaier@sysmocom.de>
Neels Hofmeyr <neels@hofmeyr.de>
Closes: OS#2730
Closes: OS#2731
Closes: OS#2762
Closes: OS#2768
Closes: OS#2775
Closes: OS#2823
Closes: OS#2898
Closes: OS#2936
Change-Id: I68286d26e2014048b054f39ef29c35fef420cc97
This replaces custom cell identifier parsing in the paging code with
calls to the new cell identifier parser implementation in libosmocore
(which was derived from the code that is now being replaced here).
The bssap tests will fail unless this other change is merged to
libosmocore as well: https://gerrit.osmocom.org/#/c/7288/
Related: OS#2847
Change-Id: I9e2002fbbe135287e9ce09caa3f0a85a84529463
Depends: I7f3e8ace26176e9cbfe2542961d2a95662aa4d97
Check exact number of parameters to avoid explicit void params ("") to
be used as BTS IP by an incorrect caller.
Exit successfully if firmware analysis is requested and there's no BTS
IP provided (meaning no BTS set up is required).
Save BTS IP into bts_ip variable as using optind is tricky.
Use new bts_ip variable to print the IP of the BTS we are trying to
connect to.
Change-Id: I8071aaf2be217207261ad698f87344f7ca15ccc4
log_parse_category_mask is preventing errors from being printed, which
makes debugging issues with the application harder.
Change-Id: I69ee2de921979f8bfaa8b501c6b05db1717b0c36
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: I8cf0f135131c348d0b43f25b1d444af5827f148d
This format outputs json format which can be more easily parsed if
launched by scripting launguage with json support like python.
Change-Id: Ib2d461c79fbc242141dc342578467c3e9c6ed5fc
If list-view is not enabled, then a line with the new BTS is printed to
stdout buffer. That's fine if stdout goes to the terminal, since it's
line buffered, but if abisip-find write to a pite or to a file, then the
buffer won't be flushed until a full page is full, which may take a
while, and produce delays in scripts using abisip-find.
Change-Id: I19f8c7f747fa7a130a436e5e07a8648932404bf0
When the BTS answers, it uses the src addr used by abisip-find to send
the boardcast packets. This way a different IP than the one
automatically specified by default routing can be used.
An extra benefit: more than one abisip-find process can now be run in
parallel on the same interface.
Change-Id: I6b805f22d261003239d7002d9e568ea4797a2b0b
The command show bts displays all kind of BTS related info, but it
does not display the bts features yet.
- display bts specific features in vty-command show bts
Change-Id: I650133563436349d4ce55f292ea683dbb2ae68d7
In order to avoid code duplication the feature list (bit masks) and
the desciptive value strings as well as the function to set and get
the feature bits have been moved to libosmocore.
- use feature list functionality provided by libosmocore
Depends: libosmocore Change-Id Id0c35aef11aa49aa40abe7deef1f9dbd12210776
Change-Id: I3e80517539cc5d0e5d8189d434a5e3cc0fdea1a0
Fixes a regression in the code generating SI5* and SI6 on SACCH,
where the L@ pseudo-length is not part of the 'struct' definition
we have in gsm_04_08.h and hence has to be encoded manually into
the first byte of the SI buffer.
We were doing this correctly until April 2017, when the following
patch was merged:
> commit 6f0e50c833
> Author: Max <msuraev@sysmocom.de>
> Date: Wed Apr 12 15:30:54 2017 +0200
>
> Prepare for extended SI2quater support
This patch cacidentially overwrote the l2_plen that was just enoded,
as the 'struct' was no longer pointing to 'output' (si_buf+1), but
now directly to the start of the si_buf.
NOTE: The Wireshark RSL dissector (and more recently also LAPDm)
contain a similar bug, so the SACCH will not be decoded correctly
after applying this patch. Nevertheless, it's correct.
Change-Id: Ie8c907b1317566670aeb68f933ceefd552c17565
Closes: #3059
Related: #2963
Add the mnc_3_digits member to the info_ind.
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: I78f30aef7aa224b2e9db54c3a844d8f520b3aee0
In some scenarios osmo-bsc is not required, only abisip-find to do the
initial set-up of the BTS, so no need to install osmo-bsc with it.
Change-Id: If3d476a1bd67abcb9cff241ab5989db923873986
Until now, handover_test simply defines an abis_rsl_sendmsg() function to
override the one from libosmo-babis. To me this amounts to implicit linker
magic (aka luck).
The common pattern we're using for this scenario is to explicitly wrap an
existing function by instructing the linker. Also do this for
abis_rsl_sendmsg() in handover_test.c to clarify.
Change-Id: I05ce33a4e42bc82b9ce5060e2f811033f5a1f8d8
Set mr->num_cell to 0 if the bits reflect 0x7, which means that no neighbor
cell measurements are enclosed in the report.
The code in gsm48_parse_meas_rep() acknowledges that, but nevertheless left
num_cell == 7, and evaluating code commonly runs into the mistake of assuming
that actually seven neighbors are being reported on, like:
MEASUREMENT REPORT
0: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
1: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
2: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
3: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
4: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
5: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
6: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
There are only up to 6 slots for neighbors, the above listing actually printed
7, because num_cell == 7, which is a potential segfault. (sometimes it printed
uninitialized values instead of 0)
We could fix all meas rep consumers to know what num_cell == 7 means, but
instead setting it to 0 trivially fixes all of them.
Change-Id: Ie12210660a04f2d664ddc92e7ad7fc39ee474180
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
The changes to abis_test and gsm0408_test show that this code now handles
3-digit MNC correctly, by not dropping the leading zero as 0xf in the encoded
PLMN.
Re-implement CTRL commands 'mcc', 'mnc' and 'mcc-mnc-apply' to preserve the
presence of the third digit of the MNC. Always reply with all leading zeros.
Adjust the expected results in ctrl_test_runner.py, to show that it works.
In VTY and CTRL, the parsing of MCC and MNC is inherently made stricter by use
of osmo_{mcc,mnc}_from_str() -- they will no longer allow surplus characters
and detect errno returned by strtol() (in contrast to atoi()).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore),
I020a4f11791c61742a3d795f782805f7b7e8733e (libosmocore)
Change-Id: I8e722103344186fde118b26d8353db95a4581daa
If an out of range 'Last Valid Block' value for 'smscb-command'
is passed, a 'last_block' of the 'rsl_ie_cb_cmd_type' struct
could be uninitialized. Let's prevent this.
Found using Clang Static Analyzer.
Change-Id: I57635f2f482ff476ab697b1b9e872ce90aafb999
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ic16bc0bab3f2d4721e86a1a04f9d9f988d777df2
Move from using deprecated gsm48_construct_ra(), which uses a buf, to
gsm48_encode_ra(), which uses a gsm48_ra_id argument. Pass struct gsm48_ra_id
around instead of a buf.
struct gsm48_ra_id is the "encoded" representation of the bytes in a typical
MCC-MNC-LAC-RAC (04.08 Routing Area Id IE, 3GPP TS 24.008 § 10.5.5.15). Using
the struct spares using magic numbers for byte offsets.
In the process, fix a sanitizer warning for unaligned access by using memcpy()
instead of pointer assignment:
osmo-bsc/src/libbsc/abis_nm.c:2857:27: runtime error: store to misaligned address 0x7ffe8e0d6695 for type 'uint16_t', which requires 2 byte alignment
Note that (besides removing a now unnecessary cast) the gsm0408_test and
abis_test tests of RAI / CGI encoding remain stable, which indicates that the
new code is still correct.
Change-Id: I0d3908fb8ca1e2e669d257b5d59b40675fa85d06
Expand MCC-MNC test cases: show that the CTRL interface currently does not
preserve the third digit of the MNC if it is zero. These will be fixed by
I8e722103344186fde118b26d8353db95a4581daa
Change-Id: I5b097dbb6329f284e3b4914a744d5c3ad628f715
This reverts commit faf0982ae2, as it
introduces a severe regression: No more BCCH FILL / SACCH INFO are sent
upon RSL establishment to the BTS. See OS#2719 for more details
Change-Id: I8a4f3be9928bc3a0b61f23dc3e41200105204651
Related: OS#2719
The FSM lacks a proper definition of the FSM event names. This
causes problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Change-Id: Ief1eff45a896d6191bdc64c232be69e85bfc63dc
Related: OS#2924
After recent libosmocore commit "implement support for 3-digit MNC with leading
zeros" c4fce1425e19d604c199c895e227dc2519110456
Id2240f7f518494c9df6c8bda52c0d5092f90f221, struct gprs_ra_id has a new member,
namely mnc_3_digits. In gprs_ra_id_by_bts(), this new member is now not
initialized and may end up having an arbitrary value, which then may amount to
mnc_3_digits == true. Hence the resulting BCD representation of the MCC-MNC may
inadvertently and randomly indicate a leading zero on the MNC.
Use a struct assignment so that all members are guaranteed to be set, and so
that mnc_3_digits will be zero in all cases.
Since above libosmocore commit, nanobts_omlattr_test fails "randomly", fixed by
this patch.
Change-Id: I872ae3b2b0a0cd8f932f3a5fbc77c0dbfcb28bbf
The S_L_INP_TEI_UP signal was generated when the first message from a BTS
arrives on the OML/RSL link, rather than when the OML/RSL link comes up.
Instead, generate this signal when the link is brought up, so we
intitialize state regardless of how a particular BTS behaves.
Tested with osmo-bts-virtual and virtphy/mobile programs,
and with a sysmobts.
Change-Id: I3b76ae6b00043e706dddc78209311e00ace85bb7
Related: OS#2719
We already have other commands that operate on a given bts/trx/ts/ss,
let's make sure they have a shared/common syntax for consistency.
This also fixes the issue that the handover/assignment commands were
active already in VIEW_NODE, while they should only have been in
ENABLE_NODE.
Change-Id: I1f31e9adf9c75348809ebf9f40f6c69fab248e43
Access Control Class (ACC) ramping is used to slowly make the cell
available to an increasing number of MS. This avoids overload at
startup time in cases where a lot of MS would discover the new
cell and try to connect to it all at once.
Ramping behaviour can be configured with new VTY commands:
[no] access-control-class-ramping
access-control-class-ramping-step-interval (<30-600>|dynamic)
access-control-class-ramping-step-size (<1-10>)
(The minimum and maximum values for these parameters are hard-coded,
but could be changed if they are found to be inadequate.)
The VTY command 'show bts' has been extended to display the
current ACC ramping configuration.
By default, ACC ramping is disabled.
When enabled, the default behaviour is to enable one ACC per
ramping step with a 'dynamic' step interval. This means the
ramping interval (time between steps) is scaled to the channel
load average of the BTS, i.e. the number of used vs. available
channels measured over a certain amount of time.
Below is an example of debug log output with ACC ramping enabled,
while many 'mobile' programs are concurrently trying to connect
to the network via an osmo-bts-virtual BTS. Initially, all ACCs
are barred, and then only one class is allowed. Then the current
BTS channel load average is consulted for scheduling the next
ramping step. While the channel load average is low, ramping
proceeds faster, and while it is is high, ramping proceeds slower:
(bts=0) ACC RAMP: barring Access Control Class 0
(bts=0) ACC RAMP: barring Access Control Class 1
(bts=0) ACC RAMP: barring Access Control Class 2
(bts=0) ACC RAMP: barring Access Control Class 3
(bts=0) ACC RAMP: barring Access Control Class 4
(bts=0) ACC RAMP: barring Access Control Class 5
(bts=0) ACC RAMP: barring Access Control Class 6
(bts=0) ACC RAMP: barring Access Control Class 7
(bts=0) ACC RAMP: barring Access Control Class 8
(bts=0) ACC RAMP: barring Access Control Class 9
(bts=0) ACC RAMP: allowing Access Control Class 0
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 1
(bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 2
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 3
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
Change-Id: I0a5ac3a08f992f326435944f17e0a9171911afb0
Related: OS#2591
In the past we used to set this to "-10 dBm" which means that basically
no RACH ever passed that treshold and in the associated CCCH LOAD IND
the number of busy slots was always zero.
Let's set the default to -90dBm. The user can of course always
configure a different value in the VTY.
This means that now any RACH slot signal level >= 90 dBm counts as
"busy" in those CCCH LOAD IND (RACH).
Change-Id: Ib9cbb786d19acc74f0951930b0dc9284854c6000
Closes: OS#3004
Related: OS#3003
The rate counter BSC_CTR_PAGING_ATTEMPTED does not increment when
a paging request is sent to the BSC. The reson for this is that the
function call to rate_ctr_inc() is located in a dead code section.
- Move the function call to rate_ctr_inc() to osmo_bsc_bssmap.c.
incremanet on any paging attempt (valid or not) that is recived
on the A-Interface.
- Remove dead code from paging.c
Change-Id: Iec3eb6724bc655806c3ce3c28448069590d99f91
When the cell identifier list of the BSSMAP paging contains an
"No cell is associated with the transaction." entry then the
paging is dropped and no paging is started at all. This is not
correct. When no cell is associated, the BSS should page the
whole BSS instead.
- Replace respective error case with a paging request to all
bts.
Change-Id: Id85e3a7540bdc13cd0e780e7870f16c35c6a6a50
Radio Resource (RR) handling is entirely done inside the BSC. However,
the current implementation forwards unknown RR messages to the MSC.
This is not compliant to the specification.
- Remove the forwarding and drop any unknown RR message.
Change-Id: I0a4d311f6939a4fcee59129daa18da4a2ab510ae
handover_decision_2:
- lchan->conn should never be NULL, but if it is, don't crash in LOGPHO*
macros.
- make certain to avoid modulo-zero. It's cosmetic since that config item is
not allowed to be zero.
handover_test:
- check return value of gsm_generate_si().
- safer evaluation of main()'s argv.
Fixes: CID#182929, CID#182928, CID#182927, CID#182926
Change-Id: I68e8ed3a1e8659edb47ac3e8a10508f17a3f5670
The file meas_proc.c seems to be an earlier stage of development of the meas
rep handling now in handover_decision.c, and to have been inadvertently added
to the git tree in:
commit 9af6ddfcec
Date: Sat Jan 1 15:25:50 2011 +0100
License change: We are now AGPLv3+ instead of GPLv2+
The file has never been part of Makefile.am.
Change-Id: If30724e3c638b191d20d00b897731762fb4896d5
Fix undefined references during link stage when building handover_test.
The archive libbsc.a needs to be listed before the various .so files.
Change-Id: Ie7e1d4815d72b8e0bbc6ccd68078a78de19d73b0
The ALIAS_DEPRECATED causes the legacy commands to no longer show up in the
command listing, hence making it more clear which commands are general and
which are for hodec1 only:
== BEFORE: ==
OsmoBSC(config-net)# list
...
handover (0|1|default)
handover algorithm (1|2|default)
handover1 window rxlev averaging (<1-10>|default)
...
handover2 window rxlev averaging (<1-10>|default)
...
handover2 retries (<0-9>|default)
handover window rxlev averaging (<1-10>|default) <-- legacy
handover window rxqual averaging (<1-10>|default)
handover window rxlev neighbor averaging (<1-10>|default)
handover power budget interval (<1-99>|default)
handover power budget hysteresis (<0-999>|default)
handover maximum distance (<0-9999>|default)
handover2 congestion-check (disabled|<1-999>|now)
OsmoBSC(config-net)# handover ?
0 Disable in-call handover
1 Enable in-call handover
default Enable/disable handover: Use default (0), remove explicit setting on this node
algorithm Choose algorithm for handover decision
window Measurement averaging settings <-- legacy
power Neighbor cell power triggering
maximum Maximum Timing-Advance value (i.e. MS distance) before triggering HO
OsmoBSC(config-net)# handover?
handover Handover general config <-- unchanged
== AFTER: ==
OsmoBSC(config-net)# list
...
handover (0|1|default)
handover algorithm (1|2|default)
handover1 window rxlev averaging (<1-10>|default)
...
handover2 window rxlev averaging (<1-10>|default)
...
handover2 retries (<0-9>|default)
handover2 congestion-check (disabled|<1-999>|now) <-- no more legacy
OsmoBSC(config-net)# handover ?
0 Disable in-call handover
1 Enable in-call handover
default Enable/disable handover: Use default (0), remove explicit setting on this node
algorithm Choose algorithm for handover decision
<-- no more legacy
OsmoBSC(config-net)# handover?
handover Handover general config <-- unchanged
The "Legacy" doc string actually never shows on the VTY console, but it will
show in the reference manual.
(Even with ALIAS(), a 'handover?' would only show the "Handover general config"
doc string, so no loss there from using ALIAS_DEPRECATED().)
Change-Id: I86be674d82242f9ca73a4d0040015c1c79f2422d
Handover decision 2 arguments are now configured by 'handover2 foo'. To match
that scheme, rename the previously 'handover foo' args for handover decision 1
to 'handover1 foo'.
For backwards compatibility, still provide aliases of the original VTY
commands. Writing back the config will result in 'handover1' though.
Change-Id: I7305ae7c04cc70082cd80d42b2ba32ffa399f51a
Instead of reacting on S_LCHAN* signals in the handover decision code,
introduce callbacks for the handover decision to be invoked by handover_logic.c
at the appropriate time.
The rationale is explained in a comment to struct handover_decision_callbacks,
quoting:
"
All events that are interesting for handover decision are actually communicated
by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate
those. However, handover_logic.c cleans up handover operation state upon
receiving some of these signals. To allow a handover decision algorithm to take
advantage of e.g. the struct bsc_handover before it is discarded, the handover
decision event handler needs to be invoked before handover_logic.c discards the
state. For example, if the handover decision wants to place a penalty timer
upon a handover failure, it still needs to know which target cell the handover
failed for; handover_logic.c erases that knowledge on handover failure, since
it needs to clean up the lchan's handover state.
The most explicit and safest way to ensure the correct order of event handling
is to invoke the handover decision algorithm's actions from handover_logic.c
itself, before cleaning up. This struct provides the callback functions for
this purpose.
For consistency, also handle signals in this way that aren't actually in danger
of interference from handover_logic.c (which also saves repeated lookup of
handover state for lchans). Thus, handover decision algorithms should not
register any signal handler at all.
"
Also:
- Publish struct bsc_handover to use it as argument to above callbacks.
- Add enum hodec_id to struct bsc_handover, to be able to signal the
appropriate hodec algorithm per event.
- Add hodec_id argument to bsc_handover_start*() to be placed in the
bsc_handover struct.
- Publish the LOGPHO logging macros in handover.h along with struct
bsc_handover, convenient for logging in callback implementations.
Replace handover_decision.c's signal handler with a registered
handover_decision_callbacks instance.
(Upcoming handover_decision_2 will use all of the callbacks introduced here.)
Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
The function's return value is ignored. An upcoming patch will use this as
callback function and requires a void return.
Change-Id: Id455a8becbb43884e8205d87b0371b216d0119fc
The conn's penalty timers will be used only for handover decision 2, make it
clear by a sub-struct.
hodec2 will also initialize the penalty timer list on demand only, so no need
to always initialize.
Change-Id: Ie6c2bc2b10dc424dfd94a9e11a9a62f51c48aa10
Handover decision 2 will also store the last seen mr nr for neighbor cell
measurements and hence can tell whether a neighbor's measurement is outdated.
Change-Id: Ic1148364597f91b5a55666c80c758b61fa56f582
Do not share config items between the current handover decision and the
upcoming handover_decision_2.
Rename current handover config items to hodec2_* and duplicate the ones
relevant to handover decision algorithm 1 with name prefix of hodec1_*.
I considered moving hodec2 parameters to an entirely separate .c file and
struct, but that causes considerable code bloat. Rather use the nice
handover_cfg net/bts level mechanism as-is, and simply prefix the names.
In the VTY, the hodec1 parameters are configurable by 'handover foo 23'
commands, while the hodec2 parameters are by 'handover2 foo 23'. The generic
VTY commands to enable/disable handover and to choose the algorithm are still
'handover (0|1)' and 'handover algorithm (1|2)'.
(Note, a subsequent commit will rename the 'handover foo' for hodec1 to
'handover1 foo' and add backwards-compat aliases.)
For example, the 'window rxlev averaging 5' command now exists both for
handover decision 1 and handover decision 2, and its values are independent.
This is valid config:
network
# set up handover decision algorithm 1
# (pending rename of these items to 'handover1 ...')
handover window rxlev averaging 5
handover window rxlev neighbor averaging 5
# set up handover decision algorithm 2
handover2 window rxlev averaging 7
handover2 window rxlev neighbor averaging 7
handover2 penalty-time max-distance 10
# enable handover
handover 1
bts 0
handover algorithm 1
bts 1
handover algorithm 2
In this example, bts 0 uses algo 1 with rxlev averaging of 5, while bts 1 uses
algorithm 2 where rxlev averaging of 7 is in effect.
Change-Id: I6475b2543b18d21710a6d774b214cb484f36ec8e
chan_compat_with_mode() currently only considered the requirements of
voice/csd services. It failed to realize that GSM48_CMODE_SIGN
can also be performed over a SDCCH, resulting in unneeded channel
allocation/assignment to TCH type channels, e.g. for SMS.
This makes TC_assignment_sign pass.
Change-Id: I85ffcbd32ccd2617c897edb3b904f56bacd0684f
Closes: OS#2762
The BSSMAP Cause value should give a clear indication of why a given
operation failed. Previously we were unconditionally sending
GSM0808_CAUSE_NO_RADIO_RESOURCE_AVAILABLE even in cases where mandatory
IEs were missing or other errors occurred unrelated to resource
availability.
Closes: OS#2759
Change-Id: I86adcae2950cbea6dcac4551cfde1054cb0abad1
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
The bit-mask of permitted ciphers from the MSC (sent in ASSIGNMENT
COMMAND) is intersected with the vty-configured mask a the BSC.
Finally, the best (highest) possible cipher is chosen.
Change-Id: I1d1c8131855bcab2392b4f27f6216bdb2fae10e0
Closes: OS#2461
About half of our log categories/subsystems were inherited from
OsmoNITB, and are no longer used but may confuse the user.
Change-Id: I8b39429f71c0faefdf8158a82093cfb19f44809e
osmo_bsc_sigtran.c uses DRANAP instead of DMSC in two places,
this is not correct.
- change wrong DRANAP to DMSC
Change-Id: I1594d1906cf7d053d00fff52e9dc0ddfd097ed6e
Once upon a time, in the old osmo-bsc-sccplite, there was a restriction
of not being able to handle configurations with both TCH/F and TCH/H
type codecs. This time is long gone, so let's remove this constraint.
Change-Id: Iba0822f57c41cedeeb7f069be540f3a851752a23
Closes: OS#2763
There was always a 1:1 correspondence between gsm_subscriber_connection
and osmo_bsc_sccp_con, so there's really no point in having two separate
dynamically allocated data structures with pointers back and forth and
another linked list around.
Let's merge osmo_bsc_sccp_con into gsm_subscriber_connection for
simplicity.
The resulting code might not be elegant in places, but I've tried to
do only the most simple changes in this patch, while further
simplifications can be done in later subsequent patches.
As a side-effect, this patch also fixes lchan clearing if the MSC
(or the local SCCP provider) hard-disconnects the SCCP connection.
Change-Id: Idd2b733477ee90d24dec369755a00f1c39c93f39
Have expicitly named vty write functions for bts and net levels, so that it is
trivial to add commands that exist only on one of each (like the upcoming
congestion check timer config for hodec2).
Change-Id: Ibea4c20abc50c3d655f6bbb1a643477dfc722c8e
On BSSMAP Assignment Request received from the MSC, store the Speech Codec List
in the subscr conn, so that we may evaluate available codecs during handover
decision. (Will be used, e.g., by handover_decision_2.)
Change-Id: I8222d73085eb777696e365c94214c05d56e6d129
Separate penalty timers API from specific struct members and move to own .h/.c
file, so that future code may re-use the API arbitrarily.
Change-Id: Ife975a1c7c17a500b1693be620475a8bea72f86f
Explicitly log "Handover" or "Assignment", add more info to existing log
statements and add more log statements.
Log ho failure both on RR and HO log categories: RR receives the HO failure
message, while the HO failure is an important event to note when watching the
HO category.
Change-Id: Ia3999755cdd4e0c2861582b20e2dbb7e1538e074
For re-assignment within the same cell, keep the same MS power. But for
handover to another cell, start off with that cell's configured maximum MS
power.
Change-Id: Ia91766d8bb8f543f514726ce9508b7747bb2bcb5
To keep this cosmetic change apart from subsequent functional changes:
have a local do_assigment flag and a local network pointer.
Change-Id: I09684dcf2a00e3d930e058cc1c925ad6e59b1468
Upcoming handover_decision_2 will want to be able to handover to a differing
TCH type, hence add a parameter to bsc_handover_start(); adjust current callers
to pass the old lchan type.
Tweak the 'bts' argument to 'new_bts'.
Change-Id: I4478ebcaada00897cc38c5a299e07661139ed3c5
memcpy obviously needs the byte size, not the ARRAY_SIZE. For the uint8_t
arrays, these are incidentally the same number, but semantically it should be
sizeof.
Change-Id: I97b6ac05192ad477b246a23ce00c5c91abfd938a
In commit [1], the channel activation kind was modified out-of-context to use
Immediate Assignment in case of intra-cell re-assignment. This so far hasn't
worked out in tests, so instead stay with the strategy to use
RSL_ACT_INTER_ASYNC also for re-assignment within the same cell. We may move to
RSL_ACT_INTRA_IMM_ASS in a separate patch after proper testing.
[1]: 5eaa4fb821,
I2d91765c1f9719c64fd99426a872cecc724215db
"HO: add indicators for inter-cell and async ho, use for chan act type",
Note that so far, no re-assignment within cells is triggered by the current
handover decision algorithm, so the effect will be really noticeable with
handover decision 2 that is coming up.
See feature OS#2949 which asks for implementing actual RR Assignment to
handover within a cell.
Related: OS#2949
Change-Id: Ia3d979094fa16620f1acc5933418797829710ba8
For unconnected BTS, the channel load would report a "bogus channel load
sample" every second (on RLL debug). Instead, skip unusable BTS.
This follows up on commit 6cee893a0f /
I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec
'Make "waiting indicator" of IMMEDIATE ASSIGN REJECT dynamic.'
Change-Id: I627fe10e1f5c1f2f23745c906320871024b5c8c3
This leaves common_cs.h practically empty. Leave its removal to the next patch,
which removes libcommon-cs entirely
(I07d4a48af3154ee4d904686f230a51b8b8a94ff9).
Change-Id: Ic3233f03580aa8c0ab178dfd33e68ecab5b9f042
The gsm_network VTY was partly shared between libmsc and libbsc in the old
openbsc.git; now osmo-bsc.git has its own copy, so merge all of it into
bsc_vty.c.
This leaves common_cs_vty.c practically empty; leave removal of the file to
later, when we drop the entire libcommon-cs in
I07d4a48af3154ee4d904686f230a51b8b8a94ff9.
Note that gsmnet_from_vty() is also already declared in bsc/vty.h.
Change-Id: I6f3a596f31762b48afed39a85a343c400826300f
These functions were originally shared between libmsc and libbsc in the old
openbsc.git; now osmo-bsc.git has its own copies, so move them into libbsc.
Change-Id: Ie411c2ce8008accee54782a442d6361e50777a54
Some part of the network init was common between libbsc and libmsc in the old
openbsc.git repository. Now osmo-bsc.git is independent with its own copy of
the gsm_network initialization. So move it over to libbsc.
Change-Id: I8968787a5f0b078619264f0cb42349a9bc7943af
a_reset.c was originally used by both libmsc and libbsc in the old openbsc.git
repository. Now osmo-msc.git has its own copy, and the idea of sharing
libcommon-cs is no longer applicable. Move it to libbsc where it belongs.
Change-Id: I30e4b5dab9c6d761d20a3a0e5b9ec2d65e64ebc5
Move gsm_data.c and handover_cfg.c to libbsc, where they belong.
This leaves libcommon utterly empty, drop it.
Change-Id: I6178061fa30c7e1a4c22c29d3c8f508b1033569f
The separation of gsm_data_shared.* from gsm_data.* historically allowed
compiling parts of it into osmo-bts, which we have dropped since (osmo-bts has
its own copy now). Even though gsm_data.* now becomes rather large by it,
remove the legacy separation to get rid of the "shared" naming, which is no
longer meaningful. A future patch might separate into meaningful smaller bits,
if we get the time.
Change-Id: Ie247bc492efb331871d970c56700595ad3f7e201
Curiously, ipaccess-proxy.c is able to define its own tall_bsc_ctx even though
the same should already be linked from gsm_data.c. Declare it extern instead
and hence use the one from gsm_data.c.
A linking error actually occured as soon as I joined gsm_data_shared.c into
gsm_data.c, which is how my attention was drawn to this. I assume that linking
didn't necessarily pull in gsm_data.c before and a separate tall_bsc_ctx was
permitted. As soon as the next commit merges those files
(Ie247bc492efb331871d970c56700595ad3f7e201), it becomes impossible to define a
second tall_bsc_ctx in ipaccess-proxy.c.
Change-Id: I9c9c8540419876696e65a690717144d497d60fb2
Interestingly enough, talloc_ctx_init() actually had not a single caller.
While dropping it, see to it that the few contexts that are actually used in
osmo-bsc.git are indeed initialized in all the main scopes.
Also initialize two void* ctxts as NULL explicitly, to allocate under the NULL
context in case some main scope forgets to branch it off another root context.
(That's bsc, fle and paging, all others actually come in from other libraries.)
Change-Id: I344a3d07e146999e154824837ed95db2b9879356
Replace calls to make_sock() with osmo_sock_init_ofd().
Shame on me for not testing every single one in practice, I hope for peer
review to confirm that this should be correct... Read closely please!
The IPPROTO_GRE define seems to be unused (at least in osmo-bsc.git), drop it
completely.
Change-Id: Ia6e4e0e1eed3328fa25b3b90be376d532ad0e56b
Provide concise log categories for each main scope.
Move the complete log categories 1:1 to osmo_bsc_main.c.
In bsc_nat.c, omit obviously unused log categories.
In tests, omit almost all log categories, except for those explicitly tested as
the expected output.
Note: should any logging occur for a log category that is omitted by accident,
such will end up being logged as DLGLOBAL, so it will show up and we can fix
it, and it will not get lost silently.
Change-Id: Ib524e49ec211662e0dfde8161495a72aa8ad76cf
Move bsc_vty_go_parent() to osmo_bsc_main.c and bsc_nat.c, and drop those nodes
that aren't used in the respective main scope.
Change-Id: I22ebb76742e9c5ab9dd608ac089a5c558aceeb36
If a BTS/TRX does not respond to the "IPA RSL Connect" command,
pretend that the BTS has sent a NACK for the connection.
To ensure that osmo_timer_del(&trx->rsl_connection_timeout) is not called
before this timer is initialized with osmo_timer_setup(), the E1 layer now
drops incoming RSL messages from a BTS/TRX in LOCKED administrative state.
We cancel the timeout if we receive an RSL Connect ACK or NACK from the BTS,
and if the underlying E1 link does down.
While here, add a missing message buffer free() in bts_isdn_sign_link().
The callers do not free it.
Change-Id: Ia72b65a0f15f47dcb8a6f944f6c3695a4a64b923
Related: OS#2716
osmo-msc does currently not check if an MS attemts to establish an
SACCH link on SAPI=0. This combination is not permitted and should
be dropped.
- Make sure that establish indication for SAPI=0 and channel-type=SACCH
is not permitted
See also TTCN3 Testcase:
BSC_Tests.TC_rll_est_ind_inval_sacch
Change-Id: I12962072c0ea689d2b9b5c2899ffb59be9310dcb
Closes: OS#2750
When the first EstablishInd (DCCH) is made by the MS, then it must by
definition happen on SAPI=0. The MS may establish multiple connection
on other SAPIs afterwards. At the moment osmo-bsc does not check the
SAPI when an EstablishInd message is received.
- For SAPIs other than 0, check if SAPI=0 has already been
established
See also TTCN3 testcases:
BSC_Tests.TC_rll_est_ind_inval_sapi1
BSC_Tests.TC_rll_est_ind_inval_sapi3
Change-Id: Ibf4fca0bd42dfe5bc63e8b08754ebbe0a5e252c3
Closes: OS#2750
In addition to logging the current values of a BTS's channel load
average and T3122 override, maintain stat items for these values.
This allows for plotting these values over time, for instance.
These values show up in the VTY under 'show stats' like this:
base transceiver station:
Channel load average.: 25 %
T3122 IMMEDIATE ASSIGNMENT REJECT wait indicator.: 32 s
Change-Id: Icace0176e8b1d23d7c7b4816f7c67c65312844fa
Suggested-by: laforge
The IMMEDIATE ASSIGN REJECT message contains a wait indicator which
tells an MS requesting a channel to wait for a specified amount of
time before trying to request a channel again, i.e. the wait indicator
controls the T3122 timeout value in the MS.
Previously, the wait indicator was fixed to 10 seconds.
This is not sufficient if there are a lot of MS requesting channels
because the MS will retry too soon. Instead of using a fixed value,
maintain a dynamic wait indicator value based on average channel load.
The load (used vs. available channels on a BTS) is sampled once per
second, and once 8 samples have been collected we update a BTS-specific
T3122 wait indicator based on the measured load.
While the wait indicator could go up to 255 seconds, this initial
implementation keeps it in the range from 10 to 128 seconds.
Further experimentation and testing will show whether higher wait
indicator values are desirable, if the sampling rate needs to change,
or if the function mapping the load measurement to a wait indicator
value should change (currently we map the load average linearly into
the range [10, 128] inclusive).
Change-Id: I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec
Related: OS#2592
This member was merely a cache for conn->lchan->ts->trx->bts,
so let's avoid having to keep copies of the same data (which needs
to be kept up to date).
Change-Id: Id3bff8b18425ef5d45eb460ac9eb620023013ba0
The decision on how to further process the request depends significantly
on the contents of the only mandatory IE of the ASSIGNMENT REQ. Let's
decode it first.
Change-Id: I030b5ad6f4fc33da9155c8a6061fd982312b20fb
There's nothing wrong with passing the TLVP_VAL/TLVP_LEN directly into
the gsm0808 decoder functions, let's avoid variables that get assigned
and used only once - particularly with such generic names.
Change-Id: I8557b4a9ff4de28b76c7d618631a4700176a8669
This error message is now contained in a loop, and the current iteration
does not know whether paging will fail entirely or if later iterations
will succeed. Update the error message accordingly.
This also makes the error message consistent with the one in page_cgi().
Change-Id: I8ec229702343343dedcbb242b6d0ed170c858511
This penalty timer is used to temporarily block cells where handover
or assignment failed or where handover is not allowed. This is usefull
to prevent repeated handover attempts to broken cells or cells that have
limited allowed distance.
Change-Id: I95cb7e3211b2470b773965e7aa94d8eb6c8c1a3a
When averaging measurements, only the valid reports are used. If there is
no valid report in the averaging window at all, an error is returned.
Change-Id: I33056225ead788340755e98113d72e1cbf3ebce6
Add ho_dtap_cache to gsm_subscriber_connection, a stock msgb queue to be used
with msgb_enqueue() and msgb_dequeue().
Keep a counter of queue length, to enforce a sane maximum counter for cached
messages. So far a hardcoded maximum of 23 messages will be cached.
Have balanced ho_dtap_cache_add() and ho_dtap_cache_flush() functions.
The original patch was by jolly, but I have basically completely replaced it
with the simpler msgb queue pattern.
Change-Id: I6e4d93628befb3d97e5cee0343cd9f8ba0b8620c
The name sounds like it is looking up neighbors, instead it simply traverses
the global list of BTSes. Rename to reflect what it does.
Move FIXME comment to its logical place: at the invocation of
bts_by_arfcn_bsic().
Change-Id: I063870d09f782a4f18e85d87c7cd17fe660cb3fd
This is needed for handover algorithm to balance free slots and to prevent
congestion of one cell, while other cells still have free capacities.
Change-Id: Ic8bee8a515ee8aa9a99af71756fe60b8dd8f868b
If we want to average over up to 10 measurement reports (as configurable
at VTY), we need a history of at least 10 measurements.
Change-Id: Ia7cfac073bdc464092ca3e51dec319ac30401dd1
The given value is 10 * ms, so 13 is used instead of 128.
If T3105 is set at config to something greater 0, it is used instead of
the default value.
Adjusst nanobts_omlattr_test.c accordingly.
Change-Id: I3d9687619ba4de35f5d2eff3026d903534b2bbd4
This makes sense, if silent call is used. Assignment allows to change from
SDCCH (or whatever was available) to given TCH rate.
Change-Id: I2efe9d7ab429e902581ebb9e0e006f2aec6d8972
This can happen, if a TCH/H was requested, but because it is not available,
a TCH/F is allocated. If the old channel was TCH/F already, it makes no
sense to assign it.
Change-Id: I284125483fc14b8f82e32ee61aa3866746238eae
The up-to-date rqd_ta is required for assignment command. If the phone
moves, the timing advance might change. The rqd_ta will be updated by
each measurement report.
Change-Id: If1a592e590cfed55ff3dca5be89e2946e8017a22
Always start with a counter of 0 for a new measurement report. If the
neigh_meas_avg is caluclated over the given window, the window is
reduced, if there are less measurement reports received so far.
Change-Id: I1c74f27f9663a3083610c985a080fca331c19bd3
get_meas_rep_avg will return -EINVAL, if the required number of
measurements are not reached. There will be no handover possible until the
given number of measurements are available.
Change-Id: Ibc4410b4e162cdb6c070128d2c63946bb79d6d65
In case of current channel equals TCH/F and we request half rate, we
must return 0, so the calling function will trigger assignment.
Change-Id: Ibb4cb9aef1a1146f984d7c969bfba53c647cae07
This is needed, so channel can be negotiated before the actual channel
type is assigned.
In case there is no SDCCH available, try to assign what ever the MS requested.
If this is not possible try to assign TCH/F. If this is still not possible,
reject channel request.
Change-Id: I10fc9f60c58c6b7ed424a86ce23bf6b9802c9eb1
The static ho_ref seems to be implicitly initialized to zero, but let's make it
explicit for code readability.
Change-Id: I00493bcb7ef3e38fb8e0077c60c5bac7199f1073
In order to keep processing power at BTS at a defined level, the handover
decision might want to limit maximum number of slots that require RACH
detection.
Change-Id: I8908e37fe0d8d2eda906cc6301ba0969b25a5575
This is needed, if the channel mode should change when doing handover.
A change in channel mode makes sense, if available resources at the new
BTS are different.
Change-Id: Ib6b17a9be252f1655006ab6773483868017d7926
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
Do not instruct the MGW to move the RTP to the new lchan before we have
received a HANDOVER DETECT.
Before:
Chan Activ
Chan Activ Ack
IPACC-CRCX
-ACK
IPACC-MDCX
-ACK
MGCP MDCX --> MGW
...
HANDOVER DETECT
Call continues on new lchan
In above sequence, if the HANDOVER DETECT times out, the MGW has moved to the
new lchan which never becomes used and is released. Furthermore, from the IPACC
MDCX until the HANDOVER DETECT, the RTP stream would break off momentarily.
After:
Chan Activ
Chan Activ Ack
IPACC-CRCX
-ACK
IPACC-MDCX
-ACK
...
HANDOVER DETECT
MGCP MDCX --> MGW
Call continues on new lchan
If the HANDOVER DETECT times out, the call happily continues on the old lchan.
This change is inspired by Ivan Kluchnikov's HO work, who implemented a similar
fix in the openbsc.git codebase (branch fairwaves/master-rebase): his patch
moves ipacc_mdcx() to connect RTP to the new lchan from switch_for_handover()
(which triggered on S_ABISIP_CRCX_ACK, i.e. creation of the new lchan) to later
on in ho_detect() a.k.a. the S_LCHAN_HANDOVER_DETECT signal handler:
http://git.osmocom.org/openbsc/commit/?h=fairwaves/master-rebase&id=9507a7a1ea627e07370c9d264816bb190b3b91b8
This patch does essentially the same: remove the mgcp_handover() call from the
MDCX-ACK handling (creation of the new lchan), and add a signal handler for
S_LCHAN_HANDOVER_DETECT to osmo_bsc_mgcp.c to effect the MGW switchover.
Note, it would have been possible to call mgcp_handover() directly from rx of
the HANDOVER DETECT message, but that produces linking fallout in some utils/
projects, which then need to link the mgcp code as well. That is because those
aren't properly separated from the more complex parts of libbsc. Using the
signal is a bit bloaty, but saves the linking hell for now. I've faced a
similar problem twice recently, it would pay off to separate out the simpler
utils/ and ipaccess/ tools so that they don't need to link all of libbsc and
osmo-bsc, at some point (TM).
Change-Id: Iec58c5fcc5697f1775da7ec0111135108ed1fc8f
A subsequent patch will add registration of a signal; cosmetically prepare by
creating a common mgcp_init() function. It makes sense for the FSM registration
to move to it.
Change-Id: I510e1081171706eb3d9fb2db50a9aa4f768929b5
Even thought the lchan number range depends on the pchan, using LCHAN_NR allows
passing arbitrary arguments. Limit it to 0-7.
Change-Id: I2c078b420b6183862acb5c18d1230cf8f6c9f0ce
A lower-case argument is a keyword, not a variable placeholder. Hence the user
would not be able to pass a number, just the "lchan_nr" string itself, hence
this would never work.
Depending on pchan, lchans can range 0..7, so use that instead.
Change-Id: Ib9a0b43b68c4682cd6de24d01c0de421c9ce957a
This is mostly no-op code refactoring which makes it easier to maintain the
code for each paging case and reduces the scope of several local variables.
Also, ensure that paging failures where no matching BTS was found are logged
consistently in all cases. The log level changes from ERROR to NOTICE since
this is not necessarily a fatal condition.
Change-Id: If8fdf425145791f4904a70e295bdc3c7d0f4d5f6
Handover attempt for power budget case should be performed every N SACCH frames,
where N = Power Budget Interval.
First measurement report with mr->nr = 0 was used for the first handover attempt
in this case, which is not correct, because first usable report should have
mr->nr = net->handover.pwr_interval-1.
Moreover using the first measurement report with mr->nr = 0 for handover attempt
could lead to unnecessary handover, because usually av_rxlev for first measurement report
from MS is worse than for following reports.
Change-Id: If7f54a4cb179eaa9e5eb147b9477633ac618e69e
This is a simple combination of the LAC and CI cases which have
already been implemented.
The BSC_Tests.TC_paging_imsi_nochan_lac_ci ttcn3 test passes.
The switch statement in bssmap_handle_paging() is getting a bit large,
and scoping of local variables could be improved. I will focus on
cleaning this up later once paging functionality is complete.
Change-Id: If7f596663a97a1db1a00f115a366f4a5a271c127
Depends: Id83f8b3b1ce80a39417176d99fd09f3b394fd19c
Related: OS#2752
This is essentially a case which combines paging by LAI and CI.
Depends: Ic1c72c7f83e53988eb9fedf314b1dc459836833d
Change-Id: Id83f8b3b1ce80a39417176d99fd09f3b394fd19c
Related: OS#2751
We can now either page an invidual BTS directly or page several BTS in a
given location area. This decision is taken based on the contents of the
cell identifier list in the paging request. Select a set of BTS for paging
while processing the cell identifier list, rather than requiring the
paging layer to loop over all BTS in the MSC.
This change requires some adjustment in bssap_test. In particular,
this test must now add a BTS to its network in order to pass.
The purpose of this change is to make the layering a bit cleaner.
There is one functional change: We no longer abort paging if paging fails
for a particular BTS. Instead, we keep trying to page on other BTS.
Change-Id: Ic1c72c7f83e53988eb9fedf314b1dc459836833d
Suggested-by: Harald Welte
Depends: Ic7772e75c3d7fb0df6e17e118bb33b3248352d4d
Related: OS#2753
The stow-enabled jenkins builds are currently failing like below:
make[3]: Entering directory '/build/src/libcommon'
CC bsc_version.o
CC common_vty.o
CC debug.o
CC gsm_data.o
In file included from debug.c:34:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
In file included from common_vty.c:27:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
In file included from gsm_data.c:37:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
Let's make sure the common gsm_data.h have all required CFLAGS to compile.
Change-Id: I30b75db6ffba227b05b5413b84b15f69e0c213f2
This builds upon https://gerrit.osmocom.org/#/c/5698/ which implements
support for paging by LAI.
The ttcn3 test TC_paging_imsi_nochan_ci passes with this code when
run in isolation. It does not pass if another paging test (such as
TC_paging_imsi_nochan_lai) is executed beforehand. This problem
looks similar to the scenario tested in TC_paging_imsi_a_reset.
Change-Id: Ic7772e75c3d7fb0df6e17e118bb33b3248352d4d
Depends: Ic3c62ff0fccea586794ea4b3c275a0685cc9326e
Related: OS#2753
This change removes a few USSD specific declarations, which are
not actually used now, and probably accidentally migrated from
legacy OpenBSC.
Change-Id: I060223349971a7fce169a018bf16eb91f0e20342
do not print an additional log lines when the mgcp FSM gets
halted. This is already done by osmo-fsm
Change-Id: I5aebbcacb68eab3c6afb19991dbf63a02524e4d7
When the FSM runs into an error condition handle_error() is called with
a cause code. The information about the error is then printed by handle_error(),
by this we do not get the sourcecode line of the location where the error
actually happend.
Convey the source code line number of the actual error in handle_error()
Change-Id: Ifa7f2a655474826630988572616cd26e1e2f3464
Add a new control command 'msc.N.connection_status' which can be used
to query the connection status of a particular MSC with number N.
Keep the old control command 'msc_connection_status', which always
queries MSC 0, for backwards compatibility.
Change-Id: Ibd41474a1be80e782b19ec337c856b5efc593fa8
Related: OS#2729
Since 39f62bbcbf the msc_connection_status
variable in osmo_bsc_ctrl.c is no longer updated. Query the connection's
status from the is_connected flag in struct bsc_msc_connection instead.
Makes test BSC_Tests.TC_ctrl_msc_connection_status in ttcn3-bsc-test pass.
However, we only query the connection status of the first MSC. Adapting
the control command to work with mulitple MSCs is left for future work.
Change-Id: I8ab8aac83ef6b7831b6136f7e9e3eddfbb43ecaa
Related: OS#2729
T3109 is started when the BSS sends a RR CHAN REL to the MS and stops
downlink SACCH generation. Stopped when the MS successfully releases the
LAPDm link. After stop or timeout, the radio channel is released using
RSL RF CHAN REL.
Recommended values in literature are 1-2s + RadioLinkTimeout*0.48s or
5s, while we had the absurdly high 19s timeout. This means we occupy
the radio channel way longer than needed in situations where the MS is
no longer able to properly release Layer2 (LAPDm DISC) due to loss of
signal or the like.
See also: https://osmocom.org/projects/osmobsc/wiki/Timers
Change-Id: I7416b4118e5b73c6ffb98e3546bc62a36c7a967a
Closes: OS#2734
The SMS address encoding can fail due to gsm48_encode_bcd_number() which
was not checked for because wrong type was used. Fix this by using
correct type, checking for error and propagating it to the caller.
Change-Id: I9fc16e24f7df5ebad6f4f1b389b2c5e861be95d7
Fixes: CID57882
The code triggers following error:
abisip-find.c:317:3: error: format not a string literal and no format
arguments [-Werror=format-security]
The error was introduced in 5bf1e15c55.
Change-Id: I613781495edbc53916ca70ff7b78d28ffabd3f5d
This facilitates the use of programs like uftrace. It's disabled by
default due to associated overhead.
Change-Id: Ia5a48a38962fc99446887a34008c40efd8344d9b
This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
The libosmocore version requirements are fine already but for jenkins
tests to pass we have to have Ic77866ce65acf524b768882c751a4f9c0635740b
merged into libosmocore master.
Change-Id: Ia57bf1300525cf3c247284fe966b1c415c2d53e2
Related: OS#1694
To get an overview of what base stations are present in a network, particularly
with many base stations being present, it is particularly useful to get a list
of connected base stations instead of just output of received replies.
Keep a sorted list of known base stations, which time out after 10 seconds.
Print additions and removals, and total amount of replies received. On each
change, print the entire list.
Output a running total of replies received, to provide comfort to the reader
that something is still happening, and to confirm that the shown listing is
still up-to-date (updated on the same line by means of '\r').
It looks like:
----- Mon Dec 25 18:59:43 2017
0: MAC_Address='00:02:95:07:dc:bd' IP_Address='192.168.0.124' Unit_ID='1/1/1' Location_1='Unknown' Location_2='3GAP' Equipment_Version='237B015_C' Software_Version='unknown' Unit_Name='Unknown' Serial_Number='000295-0000152614'
1: MAC_Address='00:02:95:07:dd:57' IP_Address='192.168.0.15' Unit_ID='1/1/1' Location_1='Unknown' Location_2='3GAP' Equipment_Version='237B015_C' Software_Version='unknown' Unit_Name='Unknown' Serial_Number='000295-0000154153'
Total: 2
RX: 11
----- Mon Dec 25 19:00:12 2017
LOST:
MAC_Address='00:02:95:07:dd:57' IP_Address='192.168.0.15' Unit_ID='1/1/1' Location_1='Unknown' Location_2='3GAP' Equipment_Version='237B015_C' Software_Version='unknown' Unit_Name='Unknown' Serial_Number='000295-0000154153'
----- Mon Dec 25 19:00:12 2017
0: MAC_Address='00:02:95:07:dc:bd' IP_Address='192.168.0.124' Unit_ID='1/1/1' Location_1='Unknown' Location_2='3GAP' Equipment_Version='237B015_C' Software_Version='unknown' Unit_Name='Unknown' Serial_Number='000295-0000152614'
Total: 1
RX: 15
----- Mon Dec 25 19:00:28 2017
New:
MAC_Address='00:02:95:07:dd:57' IP_Address='192.168.0.15' Unit_ID='1/1/1' Location_1='Unknown' Location_2='3GAP' Equipment_Version='237B015_C' Software_Version='unknown' Unit_Name='Unknown' Serial_Number='000295-0000154153'
----- Mon Dec 25 19:00:28 2017
0: MAC_Address='00:02:95:07:dc:bd' IP_Address='192.168.0.124' Unit_ID='1/1/1' Location_1='Unknown' Location_2='3GAP' Equipment_Version='237B015_C' Software_Version='unknown' Unit_Name='Unknown' Serial_Number='000295-0000152614'
1: MAC_Address='00:02:95:07:dd:57' IP_Address='192.168.0.15' Unit_ID='1/1/1' Location_1='Unknown' Location_2='3GAP' Equipment_Version='237B015_C' Software_Version='unknown' Unit_Name='Unknown' Serial_Number='000295-0000154153'
RX: 18
Change-Id: I4201876431029b303dbd10e46492228379c9782a
Subsequent patch I4201876431029b303dbd10e46492228379c9782a will add the -l
cmdline option. Add getopt in a separate step here to keep the patch lean.
Change-Id: Idba1a89753510fe6d409277b20c2db86c1b8f7f8
This is a new inline function that hides all accesses to conn->bts.
A follow-up patch will then point this to conn->lchan->ts->trx->bts
to get rid of the bts field.
Change-Id: Ib6cf7097ced34eebe80441c29ab1534f21956a33
don't mock them, simply call the respective functions to get
a gsm_network and a gsm_bts with all its subordinate members.
Change-Id: I8bdf009d3c7e2473dd42da02762039a19430d6ce
The OsmoBSC code contained a refcount leak on bsc_subscr in the paging
code. For every PAGING command received from the MSC we consistently
leaked one refcount, resulting in a resulting memory leak.
Change-Id: I3d0fb406ca2a1042c6c3424e0dd263c1933b0d50
Closes: OS#2780
This command lists the currently-active bsc_subscr and their contents,
the format looks like this:
OsmoBSC> show subscriber all
IMSI TMSI LAC Use
001010123456789 ffffffff 65534 3
001010100000001 a1b2c301 65534 1
Change-Id: Ib9c0c31a0a5a91b42fd832fa0df3460b1a440733
Currently the pasing results from the RTP ip/port are fed into
inet_addr without checking the results.
Check the return code of inet_addr to be sure that the IP-Address
got properly decoded.
Change-Id: I1d0aa7e9b8480e1bef57269e3904399cb99815bb
when a transaction to the MGW times out, then the context
information is freed. Unfortunately the client is not informed
about this and will try to execute the callback anyway.
explicitly cancel the transaction in order to prevent access
to already freed data structures.
Change-Id: I40794dff7d10e2b6a96863a2da7e9fbd5662a1bf
libosmo-sccp is the old sccp-lite-focused SCCP implementation that we
used before libosmo-sigtran was created. The new osmo-bsc in this
repository is using libosmo-sigtran and shouldn't be using parts of
libosmo-sccp anymore.
We only keep it around in configure.ac and Makefile.am for osmo-bsc_nat,
which is not even built in this repository anymore (or 'again yet'?)
Change-Id: I8f274be7d196cd7a5b1ec9ada949130fb06e984d
RRLP is handled in OsmoMSC after the split from NITB, so let's remove
any bogus VTY commands left over in the BSC.
Change-Id: Ib626f43a3a3ca69dfc127afe5832eb58f7fb6a38
There still is a lot of dead code that we inherited from the NITB
days, let's remove more of it.
libtrau will be re-introduced as part of osmo-mgw later.
Change-Id: I8e0af56a158f25a4f1384d667c03eb20e72df5b8
The ipa.py has been moved to osmo-python-tests as osmo_ipa - use it for
vty and ctrl tests instead of local copy. The soap.py and twisted_ipa.py
are not BSC-specific: leftovers from repository split which are now
available in osmo-python-tests as well.
Change-Id: Ia4285b18b152b070c148228604d1e61a8adedba1
Recent change lin libosmocore disallow registering rate_ctr with the
same name and indexing multiple times. To accommodate to this:
* allocate network struct once and use it for all tests
* deregister rate_ctr group after each test
* free bts struct after each test
Related: OS#2757
Change-Id: Ie1537a1ee9ee812eaaf9f58dc4bc86d4add8c31f
Properly match up any A5/N with the MSC's list of permitted algos.
Properly set the reject cause in case of mismatching algorithm choices.
Actually allow choosing A5/1 thru 3 as configured on the VTY, by passing
a5_encryption through to gsm0808_cipher_mode() (instead of a hardcoded 1).
Properly handle failure rc of gsm0808_cipher_mode() by sending a reject
message.
Cosmetically clarify which GSM0808_IE_ENCRYPTION_INFORMATION bits mean what by
means of local variables; add some comments on expected encryption formats; add
comment that the BSC should be able to have more than one a5_encryption.
Related: OS#2745 OS#2755
Change-Id: Ide8a615905555e35be4584b458d4d40345686175
Those NACKs shouldn't happen in production, and if they do, you probably
want to have a more persistent figure than a line in the log file about
it. Having counters allows the user to monitor this efficiently.
Change-Id: Ic82c6baaf4cb88d07bc5cdc200f8279cf130f396
Those NACKs (CRCX/MDCX/PDCH_ACT) shouldn't happen in production, and
if they do, you probably want to have a more persistent figure than
a line in the log file about it. Having counters allows the user
to monitor this efficiently.
Change-Id: I5edf979c9a2b4c9a5a60eef9f66c26da54f2bddf
Our T3113 timer default of 60s was set early in the development of
OpenBSC, where we didn't really know what values to use and used
excessively large/safe values. Paging the same MS for 60 seconds (even
if there's no paging response) will however create a lot of PCH load for
no good reason.
It seems there's no clear guidance as to what the value should be. Other
implementations use something in the order of 10 seconds (OpenBTS,
yateBTS), which seems more realistic. THe Siemens BS-11 has a default of
5 seconds.
Let's be conservative and go to 10s as a default, which is already 6
times less potential PCH usage than our default so far...
Closes: OS#2756
Change-Id: If9c8441939c6fdcf6e2b9ede8cc576eb86296209
Counting the number of T3113 expirations (one per subscriber per BTS)
vs the number of paging attempts (Bsc global) is a ueseless figure,
as you cannot relate each other.
We count on the BSC level:
* how many PAGING we received from the MSC (total)
* how many of those were for cells/LACs we don't serve
* how many of those resulted in PAGING RESPONSE
We count on the BTS leve:
* how many PAGING CMD we sent to the BTS (total)
* how many of those we ignored as we were already paging
* how many of those resulted in PAGING RESPONSE
* how many were expired due to T3113 expiring
Change-Id: I410bbcbb2621f95f11238f7a5da01ab438f5fee1
I discovered that the per-BTS counter group could only be requested
for BTS 0 but didn't work for any further BTSs.
This is a bug introduced in Change-Id I5bd9e6e333b1c396beae46630986b17e7f8b82ef
where we introudce the per-BTS counters,t but allocate all of them with
index '0'.
Change-Id: I1b56f8d7b47597ed263e6808074483edca0895de
The BSSMAP reset causes the paging requests to be flushed. When
this happens right after startup then calling paging_flush_bts()
may be called when the list bts->paging.pending_requests is not
yet initalized, which causes a segfault.
Call paging_init_if_needed() to be sure that the list is
inizalized (like the other functions also do)
Change-Id: I42ddbfdec6f9d74d858ad13cc38b5b64061d08dc
Initialize the llist head gsm_bts->paging.pending_requests at the time gsm_bts
is allocated, not only at paging_init_if_needed().
The gsm_bts->paging sub-struct is invalid as long as gsm_bts->paging.bts
doesn't point back to bts. Hence the recently added iteration of
gsm_bts->paging.pending_requests should have checked whether bts is NULL. The
llist_head pending_requests is not initialized unless paging_init_if_needed()
has been called (and paging.bts is hence set). However, this fix is a safer way
to prevent errors like this in general.
The segfault was introduced by d382bf63e2 /
If3f53d3bb66ad2dc02db823cb813590c6b59c700
Related: OS#2747
Change-Id: Idfafac4e2c0e0a241a62aecbbdc22be71febf840
According to the spec it's an empty 1-byte element reserved for future
extension but we still have to generate padding properly. Add stub
function similar to the used for SI2ter and adjust test output
accordingly.
Related: OS#2711
Change-Id: I3c278c57880a173df3c4648c9724339d23ce94fd
When the MSC has lost its state and issues a RESET, we should not only
clear all ongoing radio connections, but we should also stop any paging.
There's no point in paging a subscriber if the MSC doesn't know about
this paging anymore.
Change-Id: If3f53d3bb66ad2dc02db823cb813590c6b59c700
Closes: OS#2736
The call-back was needed inside the NITB to determine which part (CC,
SMS, ...) had triggered a given paging. A pure BSC doesn't need that
feature, so let's get rid of it.
The 'void *cbfn_data' is replaced with a 'struct bsc_msc_data *', as
all callers use it with that type.
Change-Id: I8839e8338d3ad1a91b41e687e8412fcdca3fd9ab
This was created during code review towards some upcoming fix for
OS#2736. However, it's not really related to that.
Change-Id: I68d4fc8baaedd1d64cd628b2441c57ebc64ecebc
This timer is started when a channel is allocated with an IMMEDIATE
ASSIGNMENT message. It is stopped when the MS has correctly seized the
channel. Ever since the early days of development we were using a very
long timeout to be on the safe side. However, in production networks
this is a terrible waste of resources, as we will occupy 10s worth
of air-time on one of our channels for each RACH request we receive.
The only scenarios where you might need something absurdly high as 10s
would be if you have 8s of RTT between your BTS and the BSC.
See also https://osmocom.org/projects/osmobsc/wiki/Timers
Change-Id: If3c52a7cf0c06d074c44a2fc414679279189aab9
Closes: OS#2733
Previously we simply omitted SI2ter Rest Octets which is spec violation
which lead to 'Malformed Packet' error in Wireshark RSL dissector. Fix
this by generating empty 'no rest octets' with proper padding. Adjust
test output accordingly.
Change-Id: Ie4419aaaf93a462f501f8d8f7bf2677d37c58f94
Fixes: OS#2711
- use unique enum/struct fsm struct names
- use macro to shift bits in FSM description
- use OSMO_STRINGIFY to generate the state names
- remove duplicate logging of states and events
- remove unnecessary space in log strings
- prefix hexadecimal enpoint ids with
- remove unnecessary log messages
- rename bsc_mgcp_cause_codes_str to bsc_mgcp_cause_codes_names
Change-Id: I663e03046cde3c786af72d15681bf7497330d7f9
* check GPRS state: if GPRS is enabled for the BTS but NSE, CELL or both
NSVC are locked than report it as degraded
* check TRX usability: use already available function to check that TRX
is actually usable when reporting OML status via CTRL
* fix tests linking: libbsc is using gsm48_create_mm_serv_rej() which is
defined in libcommon-cs but neither libbsc itself nor tests using it
are actually linked against libcommon-cs
Related: OS#2486
Change-Id: I9dce1d3b0cabe149a90cfca58a3fe55f8d6a72bc
This is left over from the OsmoNITB days. We're defining and allocating
these MSC counters, but never actually using them. This also means that
the automatic counter export will list them, raising the expectation at
users that such counters could be used in OsmoBSC.
Let's remove them. They are in OsmoMSC, but not OsmoBSC.
Change-Id: I5bd9e6e333b1c396beae46630986b17e7f8b82ef
In more recent versions of libosmocore, we are converting any '.'
in [rate] counter names to ':' to avoid clashes with the special
meaning of '.' in the CTRL interface. Let's avoid any conversion
and use the proper name already here.
This also changes the codec_foo counters to codec:foo to follow the
notation of other counters.
Change-Id: I18916abbfc706b86bd211e7cca1a0ca3099826e9
We used to have a lot of counters only globlly per BSC, but they're
much more useful on a per-BTS level.
Change-Id: I954b9dda72b83b91d46a934c221a8b3375743599
Make it future compatible for changes. Otherwise it will break
when additional enums are adding to chreq in libosmocore.
Depends on libosmocore Id67ba8de89dd6288e449197438e9e1c5d7f5a134
Change-Id: I2acab2af8d67bccb2bc495512c1f259ae649a832
the parameter list of osmo-fsm callbacks contains a pointer
to the fsm instance. Use this pointer instead of reaching
out for mgcp_ctx->fsm.
Change-Id: I05ff62e7e2de64c2dbf5ea2736f5e58faf16df0b
the log messages have prefixes that mark important phases (CRCX/BTS,
etc...). Some lines lack the prefix.
Add missing prefixes.
Change-Id: Iea5ea9e54f4b5c998b1d5fe18a98a94abd7b728b
The log output of the reset FSM duplicates lots of the built in
FSM log output.
Remove duplicate logging, use more expressive log messages where
needed.
Change-Id: Ia5af309207476291f88af47878dc1d32b2dada06
The snprintf() that is used to compose the fsm name on an assignment
request may cause a silent failure. The buffer is large enough to
take the string under all circumstances. If snprintf() fails, this
would mean we have some other serious problem.
use OSMO_ASSERT in case the snprintf() fails, so the failure
gets noticed.
Change-Id: I3c36df8cfd0880c524244048a993cd136be41f56
In the beginning of the CRCX phase for the network does not distinguish
between EV_MDCX_BTS_RES and EV_TEARDOWN, so a Teardown due to an error
could be misinterpreted as a successful MGW response.
Add missing case statement to distinguish CV_MDCX_BTS_RES from
EV_TEARDOWN.
Change-Id: I9bf49df167d94b33ad65d8b9382a01f160b5aec0
osmo-mgw assigns connection identifiers which are returned with
the response to the CRCX.
store the assigned connection identifiers and use them to identify
the connections.
Depends: osmo-mgw Iab6a6038e7610c62f34e642cd49c93d11151252c
Closes: OS#2648
Change-Id: Ib379a6f40875bb8f2cf29038a5b5b7a40a21adab
The current implementation of osmo-mgw parses the numerical
digit inside the endpoint name as hexadecimal number.
also use hexadecimal numbers in endpoint names.
Change-Id: I64a970d300b7290d50ec84b0640d5a321d903f5e
authentication (optional|required) is no longer needed, the
related decisions are now made in the HLR.
Change-Id: Ib6c6331cc86004c4862067031e4fcb12a6975b63
The following structs are no longer used/needed:
- gsm_auth_algo
- gsm_auth_info
- gsm_auth_tuple
- gsm_security_operation
Change-Id: I93873a6cb980a54e03e719170e27a7e397236b77
the functions mgcp_timeslot_to_endpoint() and rtp_calculate_port()
which are used to calculate the port in the sccp-lite / non AoIP
case are part of libosmo-legacy-mgcp. Unfortunately libosmo-mgcp
and libosmo-legacy-mgcp cause problems when used at the same
time.
Replace the functions mgcp_timeslot_to_endpoint() and rtp_calculate_port()
with a local helper function.
Change-Id: Id10311332aeabd8fd3ba1922198e34708e04cef9
Prepare for a future change that accesses bts->network during gsm_bts_alloc().
Currently, gsm_bts_alloc() takes a ctx parameter, and gsm_bts_alloc_register()
then gets the gsm_network pointer and sets bts->network to it. All callers
anyway pass gsm_network as ctx to gsm_bts_alloc(), and anything else would not
make sense anyway. So enforce passing exactly gsm_network to gsm_bts_alloc()
and already set the bts->network pointer from there.
Prepares-for: I00870a5828703cf397776668d3301c0c3a4e033a
Change-Id: Ie590c14aa08df4c4f345596b23e5226c5577057a
An upcoming VTY test requires a cfg that doesn't have handover values set.
Prepare for that by adding a minimal BSC config. It is a version further
stripped down from the Osmocom Network In The Box wiki page.
Prepares-for: I00870a5828703cf397776668d3301c0c3a4e033a
Change-Id: Ib68b550a0e9fbb7041e554f358054c0a7931404e
Use new #pragma style instead of #ifndef dance.
Forward-declare all structs we're using pointers of.
Move function comments to their definitions in the .c file.
Change-Id: I3d43ec01897c0ef9eaf506e68d5a1ec1977f70ea
While this header was still shared among several code trees, we had this ROLE
construct in place to exclude some parts in some trees. Since we're having one
copy per code base now, the ROLE #ifdefs were dropped, also drop void *role.
Change-Id: I4f0c337779d8e7266b6e02815d886728c4826bb9
Constify in- and output arguments for Parse Attribute Response Info chain to
avoid compiler warnings, and more clearly indicate const data in the first
place.
Change-Id: Ib7d069fe1fda69e89dfd171cd76b1ed6d6db0ceb
* change return type to bool
* constify parameters
The nm_is_running(), trx_is_usable() and ts_is_usable() always return
boolean value and are always used as such anyway. The also do not change
their parameters.
Change-Id: I6a572fc78371c69f5308edbad0ebe15e143d0505
Authentication is no longer done in the BSC, the variables that
set the authentication policy and the IMSI regex have no longer
any effect.
Remove auth policy and authorized-regexp
Change-Id: Ie31b921b5fd0af5501ec0c77c0f08089c10075e2
It's leftover from the time when gsm_data_shared.* was actually shared
with OsmoBTS. Nowadays ROLE_BSC is always defined so we can just drop it
entirely and make working with gsm_data_shared.h slightly easier.
Change-Id: I34fc9ee5955c14bbbde68d5499cf2acfd329afbc
In state prior to this patch, "3G Early Classmark Sending Restriction"
bit in SI3 rest octets was always set to H, which is a sane default as
the policy to send the information is then controlled by "Early
Classmark Sending Control" bit in the same octet.
However, it seems Quortus SoftCore can have some issues decoding the
option, so let's add a vty cmd to be able to disable it for those
having any issues.
Related: SYS#4021
Change-Id: Ic1afe071038a3bb5871d7ff40f665c8644f801ec
According to documentation (and personal experience), AM_PATH_PYTHON
selects the highest version of python, no matter if major version is
different, which means if both python2 and 3 are available, 3 will be
chosen an PYTHON will point to "/.../python" which is python3. Apparently,
the macro cannot be easily used to pick highest python2 version.
As {vty,ctrl}_test_runner.py require python2 and are incompatible with
python3, let's instead rely on the system having a "python2" binary
available, which is the case in most distros.
Change-Id: Id22e157d1bee453babdfa7ed04c506390b0f17bb
First off, there are "global" and "local" IMSI black/whitelist levels:
"global" "local"
VTY 'bsc' 'msc' for osmo-bsc
VTY 'nat' 'bsc' for osmo-bsc_nat
Both in osmo-bsc and osmo-bsc-nat, the "global" IMSI filter so far completely
ignores all 'imsi-allow' rules it may contain. A comment in imsi_allow()
proclaims actions that are missing in the code. Notably, in our example config
osmo-bsc_nat.cfg, there is an imsi-allow on the 'nat' level, which with the
code before this patch cannot have been effective in any way.
Furthermore, on the "local" level the order is to check imsi-allow first, and
imsi-deny after that. The comment says to do that in reverse order on the
"global" level. There is no apparent reason for reversing.
Add evaluation of imsi-allow directives on the "global" level, i.e. 'bsc' in
osmo-bsc and 'nat' in osmo-bsc-nat, in the same order as on "local" level, to
avoid confusion. Swap the comment to be consistent.
Before this patch, to have effective imsi-allow, this config would be necessary
for osmo-bsc:
bsc
access-list acl imsi-allow 999999999999999
access-list acl imsi-allow 9017.*
access-list acl imsi-deny .*
msc 0
access-list-name acl
...
msc 1
access-list-name acl
...
With this patch, imsi-allow also works on the "global" level:
bsc
access-list acl imsi-allow 999999999999999
access-list acl imsi-allow 9017.*
access-list acl imsi-deny .*
access-list-name acl
msc 0
...
msc 1
...
Change-Id: Idb6c8dd62aa90666ba6fcd213f59d79f5498da3f
src/libbsc/bsc_init.c: In function ‘rsl_si’:
src/libbsc/bsc_init.c:153:2: error: ‘rc’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return rc;
^
Change-Id: Iedad1efcb477c77db8c741777ea076761658c7d1
osmo-bsc now uses osmo-mgw to switch the RTP streams, but there
is no example configuration yet.
Add the missing example configuration.
Change-Id: I4d4ed401bee6c3dfdec2b584bf7248ffb02bddbf
The reset context contains a string buffer to allow for setting
a human readable name, that is then displayed in the logs. Since
OSMO-FSMs already have such a feature there is no need for an
extra name variable.
Use LOGPFSML and the name parameter of osmo_fsm_inst_alloc()
to display the name of the FSM
Fixes: Coverity CID#178664
Change-Id: I34511698923abec7545a6f3defd595f97b4bbeb1
When we receive unimplemented/unhandled message types, we shouldn't
simply silently discard them, but print a log message for the
benefit of the user.
Change-Id: I65489578b1c214f193b1ce0e9ba59432dcd42a3e
The function handle_error asserts mgcp_ctx->conn to be non null,
but it does not access it otherwise.
remove unused variable conn
Change-Id: I09851c957395d1ddb2f9471b99ffc091bc250404
Even in the very early ST_CRCX_BTS phase, the error handler may
decide to go to ST_CALL in order to initate the termination of
a possibly half open connection.
Add ST_CALL to the out state list in ST_CRCX_BTS
Change-Id: Ic67aa7c67a4e98a38bff156be3ebf612012eb842
the switch statement in fsm_send_assignment_complete() has the
default case at the beginning.
Move the default case to the end to match common coding style
rules
Change-Id: I360842fe899b95972c44da3cb74a3dc51b379fdc
We recently started to use some symbols that were not available in
libosmo-mgcp-client-dev 1.0.0 or even 1.1.0. Let's depend on a newly
tagged version of libosmo-mgcp-client.
Change-Id: Ic5d3add1c69181aabbdb684a01a6ba7bcea1fe2c
So far, the config would log an error upon config parsing, and then continue to
use defaults, which is super easy to miss. On errors, return CMD_ERR_INCOMPLETE
to abort the program in a config parsing error.
Be fatal for non-existing addressbook entries and for using address book
entries from mismatching cs7 instances.
Though it is mixing in cosmetic changes, add "Error:" to the output and arrange
the erratic name to the end of the message, as is customary for error messages.
Related: libosmo-sccp I2f71b9c4dd30f919d2054da81283dd7035f44f60
Change-Id: Ia4e58902a2d3757b266cf35ac89f256cfb8f0eec
So far, if the user entered an invalid SCCP address in the config, the
osmo_bsc_sigtran_init() code simply replaced that with the default, i.e.
running with a completely different address than the user may intend.
Use the default SCCP addresses only when they are unset by the user.
Default MSC addr: set directly, do not detour via cs7 instance PC. The default
MSC SCCP addr is just a point code + SSN, deriving it from the cs7 instance
first is a confusing step. Just set the PC and SSN, and done.
Using default addresses does not constitute an "auto configuration": if we set
up a cs7 instance automatically, we do not want to have to create a second one
automatically, to prevent "auto-confusion", and want to bail instead. But for
each MSC on its own, using default SCCP addresses makes sense and is orthogonal
to automatic cs7 instance creation. Hence drop the auto config semantics from
the default SCCP address parts.
Always validate the SCCP addresses we will end up using, and bail immediately
if they are erratic. i.e. don't overwrite a non-empty invalid SCCP address with
defaults, but straight bail.
Beneficial side effects:
- Fix some grammar ultra confusion in log messages.
- Add context: log the MSC number the logging refers to.
- Drop code dup: since we're always logging the used SCCP addresses, might as
well log those once, unconditionally, in the end.
Change-Id: Iadbc2e9740457e1b389b7e7ad9c94274e7d8cb11
Use distinctive struct names: s/fsm_/fsm_bsc_reset/. They only exist
in the static context and it works fine, but the mad fsm-to-dot.py script
breaks with identical struct names. Can't hurt to have unique names.
Change-Id: I986377a74ccd83ca3b52e7f058bbc9115f05f741
Since Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a, osmo-bsc
uses osmo-mgw and utilizes libosmo-mgcp-client to talk to it, so
let's make sure the Debian control file states that dependency.
Unfortuantely, this still won't make the osmo-bsc debian package
build again, as in fact the above commit uses symbols not even present
in 1.0.0 or 1.1.0 releases of libosmo-mgcp-client :( So we first
need a new release of that library, and we need to update the
configure.ac and debian/control version requirements in osmo-bsc
before this is fixed. This needs to be automatized in the future.
Change-Id: I41a0378d069f5383904cf92cc415c19beba26168
After the bssap test in Ie934c5d229140a89763bf2efff86d6a3766cd351, the
subsequent commit Ia2882b7ca31a3219c676986e85045fa08a425d7a was not tested
against the latest head, and its breaking bssap_test was not caught.
Fix current master of osmo-bsc's 'make check' target: add osmo_bsc_mgcp.c and
libosmo-mgcp-client dependencies to bssap_test linkage.
Change-Id: I28719d267452f66d65581c43433e24a9f46cf7dc
osmo-bsc currently negotiates the RTP stream directly with the
BTS and reports back the RTP IP/Port on the BTS. This works fine
for a single BTS, but for Handover the port/ip pointing to the
MSC side must not change, so an entity in between the BTSs and
the MSC is required.
Integrate the mgcp-client and use osmo-mgw to switch the RTP
streams.
Depends: osmo-mgw Ib5fcc72775bf72b489ff79ade36fb345d8d20736
Depends: osmo-mgw I44b338b09de45e1675cedf9737fa72dde72e979a
Depends: osmo-mgw I29c5e2fb972896faeb771ba040f015592487fcbe
Change-Id: Ia2882b7ca31a3219c676986e85045fa08a425d7a
3GPP TS § 08.08 defines various types of Cell Identifier List IEs, but we only
implement "entire BSS" and "one LAC". If the MSC sends a Cell Identifier List
that we don't implement, it is best for interoperability to page the entire BSS
and post a log message instead of rejecting the paging altogether. Apart from
resource management, it is not harmful to page more than the MSC requested; if
use of resources becomes an issue, the log message will guide towards the
solution of providing an actually implemented Cell Identifier List IE.
Upon IE length that is other than we expect, log the error, but also fall back
to paging the entire BSS. Overall message length correctness has been checked
earlier.
The particular case observed is that a Huwaei MSC sends a LAI for Cell
Identifier List (MCC+MNC in bcd, followed by a LAC), parsing of which we may
want to add later.
Improve logging: identify the subscriber that is being paged.
Coding style: use a switch() statement to clarify flow and provide a place to
add more implementations later.
Add regression test bssap_test.c: fabricates BSSAP Paging messages with the two
implemented Cell Identifier List IEs as well as the unimplemented LAI
identifier, verify the resulting paging LAC in wrapped function and stderr.
Change-Id: Ie934c5d229140a89763bf2efff86d6a3766cd351
To properly decide if a given OML link is degraded we have to use
BTS-specific information about MO state.
* move check function into BTS-specific part
* add generic wrapper
Related: OS#2486
Change-Id: Iddc7a4d20fbb95a6566eed1487a12733e5adb9e2
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: If2edf59a687a78d6db6bc73117a27509374b0fc6
In Change-Id I469909ad7c597cde3d7a7d2ec86101a9f41d3aa6 we accidentially
also removed the libssl-dev dependency. osmo-bsc_nat still uses
RAND_getbytes directly, so we have to keep it for now, until we switch
to a future libosmocore-based mechanism that's in the works.
Change-Id: I3be26c566baf05278ba51b835a72e14ce6ecf3d0
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I9b6afb59f0a8037d1510a7fddb63927f10d653e5
This fixes the following dpkg-shlibdeps warning:
Change-Id: Iea00c209652e8070a59942504bef660db0999e86
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bsc-nat/usr/bin/osmo-bsc_nat was not linked against libosmoabis.so.6 (it uses none of the library's symbols)
We don't want to pacakge osmo-bsc_nat from osmo-bsc.git at this
point yet. It only suports SCCPlite, which is not yet fully supported
by osmo-bsc.
Rather, we continue to package osmo-bsc_nat from openbsc.git like we did
so far.
Also, the osmo-bsc_nat binary really doesn't belong into the osmo-bsc
package at all.
Change-Id: Icf0bf80d61141ec060b6d2efcf3e65e2ef1ac2d6
This fixes the following dpkg-shlibdeps warning:
Change-Id: I31af5fb8b52ef1fd5effb139d9cdea1ebe9a41b4
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bsc/usr/bin/osmo-bsc_nat was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
We are using quite a number of symbols that are definitely *not*
yet present in the respective library versions that we stated as
dependency. Rather than figuring this out individually, simply
require the latest releases.
Change-Id: Iecda06d206c24390bb10f3a8f8a70ef3036381e2
Those dependencies were introduced at a different time, when GPRS
related code was still in this repository
Change-Id: I469909ad7c597cde3d7a7d2ec86101a9f41d3aa6
We output a hexdump for each sccp message we receive, but not when
sending.
Also log the hexdump of sccp messages when sending.
Change-Id: Ibfe52a0b7dbca4c569c603a008d73d0d99d1c345
We already log the message type of sccp messages we receive, but
for transmitting the log output is missing.
Also log the message type for tramsitted sccp messages.
Change-Id: I6736f15ddc03e5f70c3504abffbae6cbf766c9d7
A FSM doesn't need "FSM" in its name, as it is obvious that it is a
FSM. Also, having two that are called RESET is confusing, so let's
try to come up with better names.
Also, after Change-Id I9ef59432f43a3cdb94e4cbb0c44ac3f9b2aac0f2 in
libosmocore, we now enforce that no FSM identifiers contain spaces
or other illegal characters.
Change-Id: I1b44d26cebc4a47094d7b8b3983e5737b88bf003
The library code for rate counter initialization, which is called
from the descendants of bsc_network_alloc() might already want to
log something (particularly after Change-Id
Ifc6ac824f5dae9a848bb4a5d067c64a69eb40b56 in libosmocore), so the
logging framework must be initialized before.
Change-Id: I1e893c97e023e63489fe8c46539b5e507d3cec8f
The test clearly fails unless bts->network is set correctly. Not sure
why this hasn't shown up before?
Change-Id: I47786ed06ff610213d7a0b56d0ebf1c537cd7568
unsigned long can be 32 bits on some arch/OS, while "current" field is
always 64 bit because it's a uint64_t.
Change-Id: Ibad1e4f09cf912cb654dbe3687a3f2182e2060f5
Related: OW#3893
Program terminated with signal SIGSEGV, Segmentation fault.
0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342
(gdb) bt
0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342
1 0x0805ab80 in lchan_release (lchan=0x0, sacch_deact=sacch_deact@entry=0, mode=mode@entry=RSL_REL_LOCAL_END)
at chan_alloc.c:410
2 0x0805c1dd in handle_ass_fail (msg=0x94142b8, conn=0x9251048) at bsc_api.c:459
3 dispatch_dtap (msg=0x94142b8, link_id=0 '\000', conn=0x9251048) at bsc_api.c:598
4 gsm0408_rcvmsg (msg=msg@entry=0x94142b8, link_id=0 '\000') at bsc_api.c:658
5 0x08058ca2 in abis_rsl_rx_rll (msg=0x94142b8) at abis_rsl.c:1686
6 abis_rsl_rcvmsg (msg=0x94142b8) at abis_rsl.c:2097
7 0xb7e8cf9a in handle_ts1_read (bfd=0x94e8e08) at input/ipaccess.c:271
8 ipaccess_fd_cb (bfd=0x94e8e08, what=1) at input/ipaccess.c:386
9 0xb7ee8434 in osmo_select_main (polling=polling@entry=0) at select.c:158
10 0x0804bd7c in main (argc=6, argv=0xbfc27144) at osmo_bsc_main.c:272
(gdb) print lchan
$2 = (const struct gsm_lchan *) 0x0
Possible scenario in which this crash can appear:
1- gsm0808_assign_req() calls handle_new_assignment() which sends an CHAN
ACTIVATE msg and arms T10 timer.
2- ACTIVATE ACK is received (handle_chan_ack), which calls
gsm48_send_rr_ass_cmd() which sends an ASSIGNMENT CMD, and doesn't
disable/modify T10 timer.
3- T10 timeout is triggered (assignment_t10_timeout()), which sets
conn->secondary_lchan = NULL
4- Immediately after, the ASSIGNMENT FAILURE message (which might have been
already queued) is processed in handle_ass_fail, and then the crash occurs.
This race condition is not an issue for handle_ass_compl() path because there's
this check there which would trigger most probably if secondary_lchan is NULL:
"if (conn->secondary_lchan != msg->lchan)"
Change-Id: I3798b36c628f75d4e8bc7b0996c27d695d53fbb1
Previously if we ran out of space while adding EARFCN, we simply return
which might result in malformed SI2q. Fix it by proper rollback of
entire EARFCN. While at it, let's be paranoid and introduce extra checks
against integer overflow in budget calculations.
Change-Id: I4b2aa3825e9affb6dfeadecdf24dd1a43a92b7b7
Related: OS#2357
Expose OML link uptime available via vts's "sh bts 0" command with the
new "bts.0.oml-uptime" ctrl command. To avoid code duplication, move
uptime computation into separate function and use it for both.
Change-Id: Iec405aa949d6a38a9c8e64cd7ee4b49fd416835d
Related: OS#2486
It wasn't used anyway because OsmoBTS relied on OpenBSC only. As of
ec33b0397f5d71248c5834513d4be7b9b0e46366 in OsmoBTS it does not need any
shared includes anymore.
Change-Id: Ia689c7f2163dd23e429ee9d17177345b5c9470c7
* fix insert routine to keep the list sorted by UARFCN
* fix rest octets generator to properly account for offset
* adjust test results accordingly
Change-Id: I443c5c5f937b490578354f3c8a0c5b92629f2794
Related: OS#2357
OML link state is available via vty ("sh bts 0" command) and
ctrl ("oml-connection-state" RO variable).
When showing OML link state, take into consideration RSL link state as
well: if OML is up but RSL is missing show it as degraded.
That's implemented via BTS model-specific functions (currently Sysmo- and
Nano- BTS only)
Change-Id: I5952fc59e4d82e0aa627ad91d20f964d9559a4c4
Related: OS#2486
* expand comments, fix typos
* constify parameter
* move try-add-adjust routine into separate function to facilitate
further modifications
* remove excessive checks and unnecessary return values
* move (UARFCN, Scrambling Code) tuple uniqueness check into separate
function and use it early
Change-Id: Ia72f848dec40723510ca56868e08081804227d47
Related: OS#2357
Currently, OSMO_ASSERT() is defined such that it ends in a semicolon, hence an
added ';' is redundant. However, the usual way this kind of macro should be
defined is
#define OSMO_ASSERT(x) do { ... } while(0)
so that the compiler requires a trailing semicolon.
To prepare for such a change possibly coming up in libosmocore, add ';' to all
OSMO_ASSERT() users.
Change-Id: If6dce81faee9177737a6e1b572a871aaf7e37138
This is a BSC, it has norelation to RANAP or Iu(h). Let's remove
an references to it, and also the build dependency to libosmo-ranap-dev
Change-Id: I517b9f69309b2ed0540dd6c186b3d4a2a03aed44
* remove checks for non-existent tests
* always enable bsc and nat-trie tests because both are built
unconditionally
* enable gsm0408 test which was removed by mistake
* adjust gsm0408 test output to remove SMS-related results
Change-Id: I73ad079a6333ba56e73b7c4d1d0e9c8255c2a03b
Related: OS#2257
This adds a test case to explicitly verify the BA-IND is as expected
by the behaviour introduced in Change-Id I1cd0dc51026dcd0e508e63eea4e333e6b184787a
Related: OS#2525
Change-Id: I3e5b260af97ce96a221e4d51f6c1b41d58817a59
In masurement reports sent by the MS, this can then be used to correlate
if a given measurement report was in response to a BCCH/neighbor list
received on BCCH (SI2xxx) or on dowlink SACCH (SI5xxx).
Closes: OS#2525
Change-Id: I1cd0dc51026dcd0e508e63eea4e333e6b184787a
Save the time when OML link to BTS was established and show it in
vty. That's useful when troubleshooting issues like periodic/sporadic
BTS restart.
Related: SYS#3889
Change-Id: I9e4e8504afe8ca467b68d41826f61654e24d9600
Previously we've used function so debug print always pointed to the same
place which is not very useful. Wrap it with macro so proper
file:line is printed. Also, make sure that we always change state only
through this wrapper and log only when the state has changed.
Change-Id: I21789f8021290965b61a54a2b23177ccbbfe8321
Now osmo-bsc.cfg's SCCP addresses work by internal defaults, while
osmo-bsc_custom-sccp.cfg shows how to use custom STP IP address and SCCP point
codes.
Change-Id: Icb41d5adc24b2ee5613be691a201df8f3566e5dd
According to 3GPP TS 44.018 §1.8 the "network shall never enable PBCCH
and PCCCH".
Change-Id: I319e71a4b0c682361529e9c21377398a826b934b
Related: OS#2400
Fix three instances of VTY tests working because it used to include implicit
'exit' commands to the parent node.
Since libosmocore change-id Id73cba2dd34676bad8a130e9c45e67a272f19588 = commit
d64b6aed235f6e4d84a2cb8e84b32c3179260254, we no longer do this implicit-exit in
interactive VTY shells.
*) in testPingPongConfiguration, the intention is to enter the /msc 0 node.
Drop prior entry of the 'network' node, which looks like an oversight. So
far the 'msc 0' caused an implicit 'exit' and thus worked, now fails.
*) Two instances following comments "# Check searching for outer node's
commands", which look like they are intended to check for this implicit-exit
behavior. This is obsolete, drop those parts of the tests.
Change-Id: I77931d6a09c42c443c6936000592f22a7fd06cab
* log administrative state transitions
* log what's caused it
* while at it, mark boolean variable as such
Change-Id: I3e25a19fac4d0b4886d825c9876771b1f66efe58
Related: SYS#3864
After osmo-mgw change I8e0b2d2a399b77086a36606f5e427271c6242df1, there now is a
separated libosmo-mgcp-client, and osmo-bsc needs adjusting.
But besides having an unused struct in gsm_network, osmo-bsc does not yet use
its MGCP client; these are merely plans for the future. Until we do, let's just
drop the dependency entirely.
Change-Id: I6402c7cbe58dacae7630f7f03819f8102e54c699
These either remain from openbsc.git or slipped in while applying recent
patches from openbsc.git and do not belong in osmo-bsc.
Empty out contrib: remove things that are either obviously unrelated to
osmo-bsc, or seem old and/or esoteric.
osmoappdesc.py: drop nitb_e1_configs (and some ws)
Change-Id: Ib20064f35e623d99c7d59496a3156e84b8a0d07a
There is no Iu in a BSC, this was from old times with OsmoNITB. This
configure option now lives in osmo-msc.git
Change-Id: I9cf1c430855fe8a59fea1cf0abb3242c38d45cea
smpp_mirror is maintained in osmo-msc.git, so let's remove it
(and the associated libsmpp34 build requirement).
Change-Id: Ia7b242cc52cf261b1a5dd3c287da2868e1a2b9a8
This is the OsmoBSC project. Disabling the build of the BSC would be
somewhat odd, so let's remove the option.
Also, OsmoBSC depends on libosmo-sccp now, so we must unconditionally
depend on it. As a result, we can remove the --enable-nat option,
as this was only to avoid a mandatory libosmo-sccp requirement in
historical times.
Change-Id: Icfee8a904d33b7c13ab8d185d64fb5c2337d8640
Rewire build and includes to libosmo-legacy-mgcp.
Drop osmo-bsc_mgcp and related python tests, now found in osmo-mgw.git.
libosmo-legacy-mgcp is installed from osmo-mgw, hence add the dependency to
jenkins.sh (so far using the pre_release branch).
Change-Id: Ic99d681759edce11564da62500c2aac5cf5fffe2
Remove libiu here, use the functions from libosmo-ranap instead, by applying
the ranap_ / RANAP_ prefix.
Corresponding change-id in osmo-iuh.git is I6a3f7ad15be03fb94689b4af6ccfa828c25f45c0
To be able to run the msc_vlr tests for RAN_UTRAN_IU without Iu client headers
available, add iu_dummy.h, containing mere function signatures that match
iu_dummy.c and a mostly empty struct ranap_ue_conn_ctx.
Make sure we can build with and without --enable-iu: include osmo-iuh headers
only with --enable-iu.
Change-Id: Ib8c4fcdb4766c5e575618b95ce16dce51063206b
In SGSN, actually place the port in the SGSN config by default, so that the
gsup port may now be omitted in the VTY config (the IP address suffices).
Adjust the osmo-sgsn.cfg example.
Depends: I4222e21686c823985be8ff1f16b1182be8ad6175 (libosmocore)
Change-Id: I50f2040e2eb0baacb43849e93cfed10cbc2fc156
Currently the force_realloc feature is turnd on and of in a
hardcoded way. This patch makes the option available via VTY.
Change-Id: Ic8740512c5ea0766ff6ceb1c28b9c2b3fe46e75f
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.
Implement AoIP in osmo-msc and osmo-bsc.
Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.
From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN
jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new
M3UA SIGTRAN.
Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
When somebody kills the process, it's best to handle the signal
and to use the opportunity for some cleanup. We always did this
in the NITB on SIGINT, but never on SIGTERM. Let's change it.
Change-Id: Iea6804325a6575ceab5edfd28dd20249462f143b
This option was present in very early versions of the NITB, but
at least since 2011 it is no longer supported. It's still listed
in --help output, which is wrong.
Change-Id: I1d2cceb588ec5fb34ec5e2c05a7d8c93310bee88
Set the time on the status report to the time the message was delivered, as
this may not be the same as the time when we are delivering the report to the
originating MS.
Change-Id: I9056429d40bf02731f004b7833f1de45a0d1add8
libsmpp34 already converts received TLV integer values to native
endianess in libsmpp34_(un)pack.
Converting them again at receive time swaps the 2 bytes of
user_message_reference, then using a wrong value. As GSM03.40 spec
uses only 1 byte for the id, then only the high byte of the initial
value is used and eventually sent back to the ESME. Again, at that time,
htons() is not needed because libsmpp34 already handles that part.
See OS-#2429 for more details.
Change-Id: If748548a4a223e529a1110c89e483b599b406e8b
I already stumbled into 2 compilation environments which had Werror
enabled for -Wmaybe-uninitialized and the build failed, so let's
workaround this warning.
| smpp_openbsc.c: In function 'handle_smpp_submit':
| smpp_openbsc.c:216:9: error: 'sms_msg_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
| memcpy(sms->user_data, sms_msg, sms_msg_len);
| ^
| smpp_openbsc.c💯15: note: 'sms_msg_len' was declared here
| unsigned int sms_msg_len;
| ^
| cc1: some warnings being treated as errors
Change-Id: I0901ddadb5f72e1585cb1797ac22c8ab95e83146
Commit 058cd573d8 added 2 new pointer parameters to
gprs_subscr_request_auth_info, but forgot to update wraps of the
function in sgsn_test.
I catched this today because openbsc build test sgsn_test was failing.
Closed look up to the logs showed:
Assert failed (auts != NULL) == (auts_rand != NULL) openbsc/openbsc/src/gprs/gprs_subscriber.c:791
Change-Id: Ie9e4af6da0339536fb20ca0b7bbcf6f485bd522c
gsm_04_11.c sms_report_alloc()
Use the sms->text, not the sms->user_data to construct the report body.
This also prevents the potential output of non printable characters to
the log and or vty.
Change-Id: Id51bc9483ad6f52d6da74135605cfd12434c7c96
gsm_04_11.c: gsm340_gen_sms_status_report_tpdu()
When we construct the status report PDU, use sms->src
instead of sms->dst as the destination address
This way we tell the MS that the message was delivered
to the destination and not to itself.
This is relevant for phones that display a textual
representation of the delivery report.
Change-Id: I2d4f87ac777465de9bfb5a775a789a2691755ee9
Use new definitions in libsmpp34 to set the registered_delivery field
accordingly, as provided by I5b3afff1b3b77cccd949e0606914c7ac3ba6114c.
Moreover, do not set this header field to zero if status reports are
off, the deliver_t structure has been already zeroed so this not
required.
Change-Id: Ie78e17323796120f576b9c0e1bc5ccc32da8ee12
In 2015, Jacob moved/copied related functions to libosmocore, but
for some reason didn't remove the copies here. Let's follow-up on
that and remove duplicated code.
The libosmocore commit introducing osmo_apn_to_str() was
8114294bf29ac6e44822c0ae43d4b0819f11b022
Change-Id: I7315ffcbed8a54cca2056f313bb7783ad82d0ee9
We can only print libgtp pdp information if a library context is
attached to this pdp context. This is not always the case,
particuarly during some teardown scenarios.
Change-Id: Ia3184877f9709db65f5f93a98403f2ef5b04a8ca
When converting from GSM_PCHAN_PDCH, we should generate
a RSL channel number IE with the osmocom extension
RSL_CHAN_OSMO_PDCH rather than claiming it is a regular
TCH/F channel.
This is important as this function is used by
osmo-bts, too - and it decides which channel number IE is
put in the GSMTAP header for both GSMTAP tracing as well
as the GSMTAP based osmo-bts-virtual.
In order to avoid any unintended effect on libbsc,
we make sure to modify rsl_ipacc_pdch_activate() to
always use GSM_PCHAN_TCH_F in related RSL message.
Change-Id: Ie34219e64a6d89da4a79f2db8ec73d1909fb8280
In the PDP Context Create from SGSN to GGSN, we include information
about the RAN type (GERAN/UTRAN) and the Cell of the MS. This was
all hard-coded to GERAN, and wasn't updated when we added UTRAN
support to the SGSN.
Change-Id: I6c79e42c5e08b28fe8182555302a5505fbbaa313
Commit 5754206379 introduced
OSMUX_STATE_NEGOTIATING to fix a race condition present in osmo-bsc_nat.
However, after this change osmo-bsc_mgcp cannot switch to
OSMUX_STATE_ACTIVATING anymore, which means during osmux_send_dummy time
it won't call osmux_enable_endpoint(), which in turn won't set endp type
to MGCP_OSMUX_BSC.
If MGCP_OSMUX_BSC is not set, uplink streams are sent using regular RTP
instead of Osmux not matter it is enabled in config or not.
Change-Id: Ibcb59aa1ca25408f82cc88c2d5b81177b5f276dc
In case of successful completion of handover gsm_subscriber_connection could be moved from one bts to another,
so connection link to bts should be replaced by link to bts, which owns new_lchan.
This bug was detected, because conn->bts->nr is used in call control log messages
and wrong number of bts was observed in these messages after handover.
Change-Id: Idc7dd412b7580c451e716b73ef7549826c60b0d9
Fixes regression probably introduced in c696cc28.
For bts>0 logging doesn't show bts number correctly when printing lchan
identification string - it will always show it as "bts=0". The reason for
this is that the identification string is cached before bts->nr value is
set to a proper value.
This patch sets bts->nr as part of the first step of the bts structure
initialization, before caching happens thus making sure the cached
identification string is cached with the correct values.
Change-Id: I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
Replace magic numbers by esm_class definitions, which
have been added to latest libsmpp34 in Change-Id
I91afd8b462b8fd3b2c4c5b54f4eeb7ec5b730b65
Change-Id: I6c458690da60c8f3637680efbd718f6e8c6feb4c
submit_to_sms() now handles two TLVs, so find_tlv() is suboptiomal and
it can be removed, since it would result in two passes on the TLV list.
Use new smpp34_tlv_for_each() helper to iterate over the list of TLVs
that is available since I446929feed049d0411e1629ca263e2bc41f714cc.
Change-Id: I53a65164a6cc4abc6bf57d9a8dc275cf21c90222
The change-id I7276d356d805a83ebeec72b02c8563b7135ea0b6 added msg_ref to
the databse but forgot to remove the comment stating it's not being
stored.
Change-Id: I204f098c8f2a480405446113e2181b2c53700cf3
gsm340_gen_oa() returns a negative value if the output buffer that the
caller passes is too small, so we have to check the return value of this
function.
Fixes: CID 174178
Fixes: CID 174179
Change-Id: I47215d7d89771730a7f84efa8aeeb187a0911fdb
This patch adds gsm340_sms_send_status_report_tpdu() to build a
status-report. Moreover, set sms->report field if we see a SMPP
SUBMIT_SM with Delivery Acknowledgment esm_class, so this identifies
that this is a delivery report.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| | SUBMIT-SM |
| | esm_class = Delivery Ack |
| |<-------------------------------|
| | SUBMIT-SM-RESP |
| |------------------------------->|
| | |
| SMS-STATUS-REPORT | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | |
There is a FIXME message in this patch, that I just copied from
gsm340_gen_sms_deliver_tpdu() since TP-MMS is not supported by OpenBSC.
Change-Id: Ib70e534840308ed315f7add440351e649de3f907
Simple patch to test the new status-report support code, remove previous
code before Delivery Acknowledgement support was in place. Use
LOGL_DEBUG for logging messages here as suggested by Neels and Harald.
Change-Id: I877e228d8e174430f700631edbf9955972da7892
SMPP DELIVER_SM messages with esm_class = Delivery Receipt need to send
this message reference (that the mobile phone allocates) to the ESME.
Thus, the ESME propagates it via SUBMIT_SM with esm_class = Delivery
Acknoledgment so that the SMSC sends the GSM 03.40 status-report to the
origin including this. Given this field is useful for status-reports, we
need to store it in the HLR database.
Moreover, we need a new field that specifies if the entry represents a
SMS status-report, to do the right handling from the gsm411_send_sms() -
such new handling comes in a follow up patch entitled "libmsc: handle
delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report".
This patch includes the migration routines to the new database schema
revision 5, it's quite a bit of dbi boilerplate code - copied-pasted and
adapted.
Change-Id: I7276d356d805a83ebeec72b02c8563b7135ea0b6
If the mobile phone requests a status report via SMS, send a DELIVER_SM
with esm_class = Delivery Receipt to ESME to indicate that the SMS has
been already delivered to its destination.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| SMS-DELIVER | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | DELIVER-SM |
| | esm_class = Delivery Receipt |
| |------------------------------->|
| | DELIVER-SM-RESP |
| |<-------------------------------|
| | |
This patch implements "Appendix B. Delivery Receipt Format" as specified
in the SMPP 3.4 specs. This string is conveyed in the SMS message as
data, and it is only meaningful to the ESME, for logging purposes. The
"submit date" and "done date" are not yet set, and other fields are just
sent with dummy values, so they are left to be finished as future work.
The new SMPP TLV tag TLVID_user_message_reference is added to the SMPP
messages inconditionally now since this information is required by
delivery-reports to associate the status-report with the original SMS.
Change-Id: Ic1a9023074bfa938099377980b6aff9b262fab2a
Just munch and log SMPP delivery receipts by now, don't mirror this, it
is going to break things in openbsc.
Follow up patch removes this and mirrors this SMPP message as a
SUBMIT_SM with esm_class = Delivery Acknowledgement.
Change-Id: I78e93bc4034679e238c8642ccf6a0e844b1d6d8b
Propagate the status report request field to the SMPP message through
the registered_delivery field, so the ESME knows that the mobile phone
is asking for explicit delivery acknowledgment is required. See SMPP 3.4
specs section 5.2.17.
Change-Id: I59af60fa89cd10ae973c5e122789e3e03e3728ee
Rationale: allows seeing all timer defaults at once by doing
OsmoBSC(config-net)# timer ?
Before, defaults are visible only by doing on each timer:
OsmoBSC(config-net)# timer t1234 <tab>
Change-Id: I8259234e5c62e058dde56d531071440bbab11462
The VTY parsing already ensures the parameter range being 1..65535, no need to
check the range again.
Change-Id: I1cffa5b01cd5c589f1e42998e32135f1da8c960b
Move the sms message-type-identifier (mti) handling away from the
routing logic. This patch allows us to reuse the sms_route_mt_sms()
function in a follow up patch for sms reports send through SMPP
DELIVER_SM with esm_class = Delivery Receipt whose Change-Id is
Ic1a9023074bfa938099377980b6aff9b262fab2a.
Change-Id: I3f3d30e0762b91e2099243b0be1a4b67cbb5e9c0
No need to cache the sms object, just cache what we need into the
smpp_cmd structure. This simplifies what that I introduced in
93ffbd0029 ("libmsc: send RP-ACK to MS after ESME sends SMPP
DELIVER-SM-RESP").
Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
The following branch:
if (!rc && !gsms->receiver)
rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED;
at the end of sms_route_mt_sms() always evaluates false.
Just a bit before, in such function, we have this:
if (!gsms->receiver) {
...
#ifdef BUILD_SMPP
...
#else
...
#endif
return rc;
}
So, if there is no receiver, we just stop running code and return the RP
cause via the rc variable. Same applies to the smpp_first check under
the BUILD_SMPP ifdef (that I have removed in this snippet to keep this
commit message small).
Change-Id: Ic3502b5b169bc7a73a67fd6ff53d8b6c0dc045c8
libgtp is calling gtpie_tv2 which will convert this uint16_t from host
to network order. So far libosmogsm and the sgsn treated the charging
characteristics as opaque data. So when moving from byte array to the
uint16_t do the swapping.
Change-Id: I977aec2e2f8d57802e45f591754e5733562d5c2a
We no longer permit timers with a 0 value, so this case can never
happen. Also, if it should happen, I'd rather have a timter expiring
immediately (and breaking something) than not being started in the
first place.
Change-Id: Ibfcdd3ddc0155caee89c501498329bde247621a0
It typically doesn't make sense to configure any of the GSM RR timer
to 0 (Seconds). In fact, accidentially configuring any of the timers
to zero might have severe side effects, such as "stuck channels"
described in https://osmocom.org/issues/2380
Change-Id: I517828f2f0c80ec01cb63648db2626f17a67fe57
A number of the GSM timers (including T3109) had no reasonable
default values if not specified in the VTY / config file. Together
with unconditional writing to the config file, this created
config files with a persistent setting for important timers as '0'.
To make things worse, many of our example cofig files suffered from the
same problem.
Let's avoid this from happening by
* having reasonable defaults if nothing specified in the config file
* conditionally savingg timers only if they differ from default
* reject any timer values that state zero during start-up (see previous
commit)
Change-Id: Iaac0bfca423852b61d8b9eb1438157ef00d0d8c8
Closes: OS#2380
Using this new command (introduced in OsmoBSC + OsmoNITB), you can
simulate the generation of TRAP events for testin purposes.
start the control interface monitor as an example client program:
./openbsc/contrib/bsc_control.py -m -d localhost -p 4249
then start OsmoBSC or OsmoNITB, telnet to the VTY and enter 'enable'
mode and issue the following (example) command:
ctrl-interface generate-trap my.foo.var 2342
As a result, on the bsc_control.py you will see:
Got message: TRAP 0 my.foo.var 2342
Change-Id: Ib1d2ec38290dc94797c1b365d9b733e5215ab7d1
In case the counter group allocation fails, we must handle this
gracefully and fail the allocation of the parent object, too.
The recent change (Id I7dad4a4d52fe05f6b990359841b4408df5990e21) seems
to have missed one instance, so let's follow-up.
Change-Id: I1ee9e3d26dcc18e7f979fd9a786162cbcc50942c
Related: OS#2361
If we previously had a given SI present/active, we must send a
zero-length BCCH FILLING for that SI type to the BTS to stop it from
further transmitting this SI.
Change-Id: I33e356e2fa3a69efac9080813e3e9ef4e6438ed1
Closes: OS#2368
If we want to instruct the BTS to stop sending a given SI, we must be
able to send the respective BCCH INFO / SACCH FILLING with a header but
without any L3 data IE. This patch enables the related functions to do
this whenever their data argument points to NULL.
Change-Id: I88b85614951a108574f05db3b706884afe7e87a9
In commit 8b1a2f8cd7 we started to
initialize bts->si_valid to 0. This means we are skipping the manually
configured static system information.
Instead, we have to initialize bts->si_valid to bts->si_mode_static,
i.e. start with those that are static and not to be auto-generated.
Found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo
Change-Id: Iab9cc93cf6d54560a72cc393cc3721a8d10e04bf
Closes: #2367
In case the counter group allocation fails, we must handle this
gracefully and fail the allocation of the parent object, too.
RelateD: OS#2361
Change-Id: I7dad4a4d52fe05f6b990359841b4408df5990e21
This is useful if you are updating some configuration parameters which
affect the content of the SYSTEM INFORMATION messages. Currently, we
only send them at the time the RSL connection is established (i.e. when
the BTS is initialized), so if you change something, you need to bring
down and re-start the BTS.
Using the newly-introduced "bts <0-255> resend-system-information"
command, you can re-generate + re-send SYSTEM INFORMATION without
bringing the BTS down, i.e. without any radio carrier downtime.
Change-Id: I326df47de98f6d36c9a4d2d5475225d1e62bafb5
A valid subscriber is indespensible when allocating a new
transaction. Return NULL if no subscriber is supplied. This
will cause unidentified subscribers to be rejected.
Note: Under normal conditions, the problem does not occour,
but it is still possible that a misbehaving MS might trigger
the problem by sending a SETUP command before authenticating
the subscriber. (unencrypted networks)
Change-Id: Ia8739b6e329ab02c0064270d02ad1d6ee245520d
* fix BTS numbers: use 0 to indicate given BTS and 0xFF to indicate all
BTS' as it's explained in 3GPP TS 52.021 §9.3.
* only request attributes from supported (OsmoBTS) types
Change-Id: I8f43055c38000248033a8ff9ddaf0910d68d794b
Related: OS#2317
TS 04.14 (TS 44.014) specifies a series of commands specific to
conformance testing. Let's add some VTY commands to play (at least
initially) with closing and opening voice loops in the MS.
Change-Id: I38b1ee9dbf26f5689c38cb83b1b3c5e9eaad7678
For some GGSNs we need to insert the PDP Charging Characteristics
that were returned. We receive these values from GSUP and will
fill them into the tlv structure when finding the ggsn context.
Change-Id: I1725bfd2403d29ce3550bfcd6fcc1498426ef906
Necessary since libosmocore I513835be2d931d0a931cdfc996f361a451bc1a15
removes the script from libosmocore/contrib.
Change-Id: I02d7e1c0151c687fd9341d21a09ca15cbf5a1938
For the vty tests, add osmo-sgsn-accept-all.cfg (that does not need an HLR) and
use in vty_test_runner.py, otherwise the 'show sgsn' command will reply that it
could not connect to the HLR, failing the vty test which expects empty.
Change-Id: Ie3b2013198d3e2b780a4e31c36b89b58129dcacd
This helps in providing 3G software packages for the sysmoNITB hardware, which
uses 10.23.24.1 for SGSN and 10.23.24.2 for GGSN.
However, in order to not break the python tests, the osmo-sgsn.cfg example
still uses 127.0.0.1 as local address.
Change the GGSN address to 127.0.0.2, because SGSN and GGSN cannot co-exist on
the same address (the GTP port number is fixed by spec: no IE to communicate a
differing port, so it has to be the standard GTP port for both).
Change-Id: Ie3a25f6771ed6e620cb2b315638c622a9a24e530
On incoming 04.08 messages, we log only the protocol discriminator in
decimal. Enhance: log pdisc and message type in hex, and also log the
protocol and message type as human readable string.
Also adjust the msc_vlr tests' log statements for wrapped rx/tx functions
of dtap from/to the MS.
Adjust the expected output of msc_vlr_tests.
Change-Id: Ida205d217e304337d816b14fd15e2ee435e7397d
Depends: libosmocore change-id I0fca8e95ed5c2148b1a7440eff3fc9c7583898df
The ip.access nano3G needs the first RTP payload's first two bytes to read hex
'e400', or it will reject the RAB assignment. Add flag
patched_first_rtp_payload to mgcp_rtp_state to detect the first RTP payload on
a stream, and overwrite its first bytes with e400. This should probably be
configurable, but seems to not harm other femto cells (as long as we patch only
the first RTP payload in each stream). Only do this when sending to the BTS
side.
Related: OS#2459
Change-Id: I5eff04dcb0936e21690e427ae5e49228cd459bd4
libosmocore change-id I4efdb1eaae43aced33961b64d4f14b0040321c10 changes the
gsm340_gen_scts() from gmtime to localtime, meaning that by feeding a mere zero
as timestamp, we get different results depending on the local machine's
timezone setting. Instead of calling gsm340_gen_scts() with zero, simply write
a bunch of bytes as time so that the tests get identical SMS bytes every time.
Change-Id: I8a50e8963dce80609749571b61fc6ffe1c54660c
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw
Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.
Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
In an upcoming commit, sgsn_vty_init() will require access to the global sgsn
config struct to initialize a generic VTY command with the proper config
destination address, see Change-Id I5b5b6a9678b458affa86800afb1ec726e66eed88.
Change-Id: Ie6b6e5422987586531a898e0c5b867623dbecb0f
Disable large parts of the code that depend on BSC presence. The code sections
disabled by #if BEFORE_MSCSPLIT shall be modified or dropped in the course of
adding the A-interface.
Don't set msg->lchan nor msg->dst.
Don't use lchan in libmsc.
Decouple lac from bts.
Prepare entry/exit point for MSC -> BSC and MSC -> RNC communication:
Add msc_ifaces.[hc], a_iface.c, with a general msc_tx_dtap() to redirect to
different interfaces depending on the actual subscriber connection.
While iu_tx() is going to be functional fairly soon, the a_tx() is going to be
just a dummy for some time (see comment).
Add Iu specific fields in gsm_subscriber_connection: the UE connection pointer
and an indicator for the Integrity Protection status on Iu (to be fully
implemented in later commits).
Add lac member to gsm_subscriber_connection, to allow decoupling from
bts->location_area_code. The conn->lac will actually be set in iu.c in an
upcoming commit ("add iucs.[hc]").
move to libcommon-cs: gsm48_extract_mi(), gsm48_paging_extract_mi().
libmsc: duplicate gsm0808 / gsm48 functions (towards BSC).
In osmo-nitb, libmsc would directly call the functions on the BSC level, not
always via the bsc_api. When separating libmsc from libbsc, some functions are
missing from the linkage.
Hence duplicate these functions to libmsc, add an msc_ prefix for clarity, also
add a _tx to gsm0808_cipher_mode():
* add msc_gsm0808_tx_cipher_mode() (dummy/stub)
* add msc_gsm48_tx_mm_serv_ack()
* add msc_gsm48_tx_mm_serv_rej()
Call these from libmsc instead of
* gsm0808_cipher_mode()
* gsm48_tx_mm_serv_ack()
* gsm48_tx_mm_serv_rej()
Also add a comment related to msc_gsm0808_tx_cipher_mode() in two places.
Remove internal RTP streaming code; OsmoNITB supported that, but for OsmoMSC,
this will be done with an external MGCP gateway.
Remove LCHAN_MODIFY from internal MNCC state machine.
Temporarily disable all paging to be able to link libmsc without libbsc.
Skip the paging part of channel_test because the paging is now disabled.
Employ fake paging shims in order for msc_vlr_tests to still work.
msc_compl_l3(): publish in .h, tweak return value. Use new libmsc enum values
for return val, to avoid dependency on libbsc headers. Make callable from
other scopes: publish in osmo_msc.h and remove 'static' in osmo_msc.c
add gsm_encr to subscr_conn
move subscr_request to gsm_subscriber.h
subscr_request_channel() -> subscr_request_conn()
move to libmsc: osmo_stats_vty_add_cmds()
gsm_04_08: remove apply_codec_restrictions()
gsm0408_test: use NULL for root ctx
move to libbsc: gsm_bts_neighbor()
move to libbsc: lchan_next_meas_rep()
move vty config for t3212 to network level (periodic lu)
remove unneccessary linking from some tests
remove handle_abisip_signal()
abis_rsl.c: don't use libvlr from libbsc
gsm_subscriber_connection: put the LAC here, so that it is available without
accessing conn->bts. In bsc_api.c, place this lac in conn for the sake of
transition: Iu and A will use this new field to pass the LAC around, but in a
completely separate OsmoBSC this is not actually needed. It can be removed
again from osmo-bsc.git when the time has come.
Siemens MRPCI: completely drop sending the MRPCI messages for now, they shall
be added in osmo-bsc once the A-Interface code has settled. See OS#2389.
Related: OS#1845 OS#2257 OS#2389
Change-Id: Id3705236350d5f69e447046b0a764bbabc3d493c
libvlr now delegates subscriber management to osmo-hlr, so the database no
longer represents a HLR. It basically only stores SMS, so reflect that fact in
the default database name.
Change-Id: I3289d68d3eb63aff940b48a25b584d5e83cd0197
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
SMS:
The SQL based lookup of SMS for attached subscribers no longer works since the
SQL database no longer has the subscriber data. Replace with a round-robin on
the SMS recipient MSISDNs paired with a VLR subscriber RAM lookup whether the
subscriber is currently attached.
If there are many SMS for not-attached subscribers in the SMS database, this
will become inefficient: a DB hit returns a pending SMS, the RAM lookup will
reveal that the subscriber is not attached, after which the DB is hit for the
next SMS. It would become more efficient e.g. by having an MSISDN based hash
list for the VLR subscribers and by marking non-attached SMS recipients in the
SMS database so that they can be excluded with the SQL query already.
There is a sanity limit to do at most 100 db hits per attempt to find a pending
SMS. So if there are more than 100 stored SMS waiting for their recipients to
actually attach to the MSC, it may take more than one SMS queue trigger to
deliver SMS for subscribers that are actually attached.
This is not very beautiful, but is merely intended to carry us over to a time
when we have a proper separate SMSC entity.
Introduce gsm_subscriber_connection ref-counting in libmsc.
Remove/Disable VTY and CTRL commands to create subscribers, which is now a task
of the OsmoHLR. Adjust the python tests accordingly.
Remove VTY cmd subscriber-keep-in-ram.
Use OSMO_GSUP_PORT = 4222 instead of 2222. See
I4222e21686c823985be8ff1f16b1182be8ad6175.
So far use the LAC from conn->bts, will be replaced by conn->lac in
Id3705236350d5f69e447046b0a764bbabc3d493c.
Related: OS#1592 OS#1974
Change-Id: I639544a6cdda77a3aafc4e3446a55393f60e4050
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
Related: OS#1592
Change-Id: Ie303c98f8c18e40c87c1b68474b35de332033622
Enable various components according to the build matrix during make distcheck.
Add python tests, osmo-bsc, nat, ...
Change-Id: Ic724cf61d44409337414dc58c8795896b4b97a8a
- bscs.config needed by the vty tests was not picked up as a dist file, because
its suffix is not 'cfg'. Rename to *.cfg. Apply this rename in
vty_test_runner.py and osmo-bsc_nat.cfg.
- Remove restart counters after external tests, otherwise distcheck complains
about uncleaned files.
- Add contrib/ipa.py to EXTRA_DIST, hence add a Makefile.am to contrib/.
Otherwise the python tests cannot find that dependency.
Change-Id: I42b55cb1125099afc3a8e3f87c0e398426b2e2a9
Before, each GSUP client would contact the HLR with an identical unit id, i.e.
"SGSN-00-00-00-00-00-00", with the result that some messages were sucked off by
the wrong client.
Pass explicit unit name from each gsup client user, so that OsmoMSC is "MSC"
and OsmoSGSN is "SGSN". Hence the HLR can properly route the messages.
Todo: also set some values instead of the zeros.
Unrelated cosmetic change while editing the arguments: gsup_client_create()'s
definition's oap client config arg name mismatched the one used in the
declaration. Use oapc_config in both.
Change-Id: I0a60681ab4a4d73e26fe8f0637447db4b6fe6eb2
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7
We are building with libosmo-sccp tag 'old_sua' until the new sigtran has
been applied. Since osmo-iuh commit
0f88c110093935305143987638e46dc6db304a3e
"migrate osmo-hnbgw to libosmo-sigtran's SCCP/M3UA"
osmo-iuh requires libosmo-sccp master. A similar 'old_sua' tag is in place in
osmo-iuh.git, to match libosmo-sccp 'old_sua'. Do that to fix the jenkins
build of --enable-iu.
Change-Id: I70f731db0b74ed48ae6dd713ed4c3247222ef0de
* use LT_INIT instead of AC_PROG_RANLIB
* remove redundant libbsc entries
The default (for both manual and .deb builds) is to use shared build (as
before) - the static build is entirely optional.
Based on work by Sergey Kostanbaev <sergey.kostanbaev@gmail.com> and
Alexander Chemeris <Alexander.Chemeris@gmail.com>.
Change-Id: Ibcd1da98302413182c85e25c4cb7d69d9e38c35a
While fixing potentially incorrect memory access, the check for maximum
number of supported BTS features was incorrectly adjusted instead of
feature vectore length check next to it. Fix this by adjusting checks
properly and adding comments to avoid future confusion.
The error was introduced in a60bb3dd28.
Change-Id: I06d2498d730624d5da535f6add6fa98d004714ae
When we are performing Rx sensitivity testing on a BTS, we want to
deactivate the connection failure criterion / radio link timeout, i.e.
no matter how many SACCH frames in uplink are failed to decode, the BTS
should never close the channel.
OsmoBTS Change-Id I736f21f6528db5c16fa80cdb905af20673797be5 covers a way
how this behavior can be requested from the BTS via an OML attribute.
This patch adds support to the BSC to actually set that attribute.
Do not use this in production networks, as the BTS will keep open radio
channels indefinitely even if the phone is gone and no longer
transmitting anything. This is a pure testing feature.
Change-Id: I6cb94e0f024934f7baeeb728ca9ed3042fbf16d2
Previously the SI generation lead to setting the BCCH SIs for all TRX in
a multi-trx setup. This is because we create the SIs globally but
si_valid appears to be limited to the 'current' trx. Warn if we attempt
to set SIs for the BCCH on a trx that does not have a BCCH.
Change-Id: Ie0e288252a2e7709c4dae16b96a0b1512278847f
Tweaked-by: Max <msuraev@sysmocom.de>
To support segmented SI2quater as per 3GPP TS 44.018 we'll have to
support multiple SI messages (up to 16 for SI2q) for a given type in
contrast to existing 1:1 mapping:
* expand storage space to hold up to 16 SI messages (spec limit)
* add assertions for budget calculations
* generate multiple SI2q messages
* adjust SI2q-related tests
* use precise check for number of SIq messages instead of approximate
estimation
Change-Id: Ic516ec9f0b821557d9461ae9f1c0afdd786f3b05
Related: OS#1660
* move SI2quater related defines to shared header
* add define from OsmoBTS which checks for presence of a given SI
message in gsm_bts struct. Rename it to avoid conflicts with OsmoBTS
code and to match naming conventions of similar macros.
Change-Id: I11432c93c772d1ead6d45a7bb0f1d13d492c82f1
Related: OS#1660
Use sizeof target BTS feature storage to make sure we always fit into
pre-allocated memory. Also use it for log check.
Change-Id: Ib107daa6e8b9bc397a10756071849f8ff82455d5
Fixes: CID 170581
osmo_talloc_replace_string() was introducd into libosmocore in 2014, see
commit f3c7e85d05f7b2b7bf093162b776f71b2bc6420d
There's no reason for us to re-implement this as bsc_replace_string
here.
Change-Id: I6d2fcaabbc74730f6f491a2b2d5c784ccafc6602
In addition to compile-time defined BTS model features we also need
run-time BTS features reported by BTS via OML. This should be shared by
BSC and BTS. To accommodate for this, add following:
* features bitvec to gsm_bts struct
* features descriptions
* comments to avoid confusion between 2 feature sets
* helper functions to set/query particular feature
* upper boundary on number of supported features and assertion for it
Change-Id: I02bd317097ba66585c50ebd4e8fc348f6dc3dad9
Related: OS#1614
Rename gsm_bts_has_feature() -> gsm_btsmodel_has_feature() and adjust
type signature to match gsm_btsmodel_set_feature() function and avoid
confusion with upcoming functions to check/set BTS features reported
over OML.
Change-Id: I97abdedbef568e0c2fbd37c110f7d658cf20e100
Related: OS#1614
Since commit b4999b60d4 we created PCU
sockets at hard-coded paths in the filesystem by default for all BTSs.
This is inflexible and prevents the use of multiple BSC instances on a
single filesystem, or the placement of the sockets in a more secure
location than /tmp.
The new approach with this patch is that
* no PCU sockets are created by default
* only for those BTSs where a 'pcu-socket' is configured via VTY,
the socket will actually be created
Change-Id: Ie9079470584777dcc31f85f9bf0808f479156ccb
Closes: OS#2293
Using this command, one can modify the RTP stream associated with a
given logical channel and (re)direct it to a specified IP:Port.
Change-Id: I63e03b932038a4e2f6d51c5541b52e4a42df27bf
Sometimes it is useful to manually activate (or decativate) a given
logical channel from the VTY. Doing this on the BSC (rather than the
BTS) ensures that the BSC knows that this timeslot / channel is
allocated and there is no risk to have clashes between the BSC "owning"
the resources and the BTS allocating some by itself.
Change-Id: I44fc3904678eb48bd3ab1a3da8c0c265fa082e0d
We can also move the string-to-numeric conversion inside vty_get_ts() to
reduce the amount of work required in the caller.
Change-Id: I2a74ed06e90e39d39f53fff39bb96df172728c0e
Resolving a timeslot based on its numeric identities is a generally
useful function, so lets' factor that out.
Change-Id: Id2570232f82542487a1133be7efb1dc1eb3029a8
We generally use const pointers for input arguments. Also, document
input/output arguments of function and add spec reference.
Change-Id: I2532cde69a18e3b021f7371e68f67a28a43d8b5f
The pcu sends us an already made up MAC-Block that contains the
paging request. pcu_sock.c is parsing this paging request
wrongly and fails silently, which results into a dropping of the
request.
This commit fixes the parsing problems.
Change-Id: Iefef08123bdc351afd8287d3f27ebf0ae58a6e7d
The PCU sends imm.ass messages in response to a rach request. Those
messages need to be forwarded to RSL in order to get them send. This
commit introduces the required functionality for that
Change-Id: Ice099c4ed7008200ed179e581aba1899c6c29455
Ericsson allows to attach a reference to immediate assignments. A
confirmation of the transmission is then sent back, but only containing
the reference, not the whole RLC packet.
Change-Id: I945f49e62e2a74a7906e2d49940927773edd04a9
The BSC-located PCU case looks to the PCU like a BTS-located PCU with
"direct PHY" access, i.e. the data related primitives are communicated
from the PCU directly towards the TRAU Frames or whatever transport
method is used between CCU and PCU.
In order to make the PCU believe that, we need to pass in a 'layer 1
handle'. As we don't use it, we can just pass any non-zero value and be
happy.
Change-Id: I8170bd4134904702b6b272e496100361ba473cbc
Instead of 20, use the actual buffer sizes of struct sw_load, which are 255.
Previous code would truncate a longer string at 20 without(!) NUL termination.
In the _len members, store the actual length copied. In previous code, if the
source string were longer than 20, we would store only 20 (without NUL term)
but still reflect the longer length of the source string.
Fix both of these issues for sw_load.file_id / file_id_len and
sw_load.file_version / file_version_len.
Change-Id: I2e34a1348a290d3f58dd830d08da65b94b3270db
Send SMS RP ERROR with a failure cause that relates to
the status returned by the ESME in the deliver_sm_resp.
Actual mapping array is limited as most phones I tested
don't seem to care about the failure cause anyway,
although some will display a different notification for
GSM411_RP_CAUSE_MO_NUM_UNASSIGNED
Change-Id: I61fb2d9ef4f2d2eabdc49b53d9966ad328d15e51
The newline and $NULL manage to append a trailing space to the 'openbsc' dir.
This was broken in commit 7b6673fa06
"Consistenly format variables in */Makefile.am files"
by Change-Id Ifa21513c007072314097b7bec188579972dc1694
Add a comment to prevent this in the future.
Reported-by: Andreas Mueller <andreas.mueller@criticallabs.org>
Change-Id: I218027459e3b2aaa817d91eb3f69d9c0b10dcd4e
The gsm_data_shared.h header is installable and used by OsmoBTS so it
should not include any private (non-installable headers) to avoid
OsmoBTS' build failures.
Change-Id: Ic25031101fc01bd732fe691132c081ad05fa6a4b
Request BTS attributes via OML on connection and parse the response:
request/parse incoming response as sw-config.
Note: only basic BTS-wide KV attributes wrapped in sw-config are
supported for now.
Change-Id: I589be51daca0cb9e1f3473b93e910e46b06e23ae
Related: OS#1614
Previously only the existance of bts->si_common.si2quater_neigh_list was
checked but not the actual number of EARFCNs in it. Fix it by using
si2q_earfcn_count() and adjust tests accordingly. While at it - reformat
tests to include extra information.
The correctness was checked manually by inspecting GSMTAP output.
Change-Id: Ic4fb2a9e870db66cac58b1e8d113587b30d64ce2
Related: RT#8792
In preparation for extended SI2q messages:
* add SI2q-specific accessor macro
* add *_offset variables to gsm_bts struct
* internalize memory check while generating rest octets - introduce
budget concept (number of bits available in a given message)
* internalize *arfcn_size() functions as they are not needed outside of
si2q_num() anymore
* change rest octets generation to work with gsm_bts struct directly
* do not generate rest octets if no SI2q is necessary
* adjust unit tests accordingly (cosmetic changes only to avoid
regressions)
Requires: I92e12e91605bdab9916a3f665705287572434f74 in libosmocore
Change-Id: Ib554cf7ffc949a321571e1ae2ada1160e1b35fa6
Related: RT#8792
* use define for number of attributes instead of magic number
* add sub_model to gsm_bts struct
* expand number of BTS features
* mark attributes parameter to abis_nm_get_attr() as const
Change-Id: I7ecb0c4339530d3a8354a2f94b34063dda87e030
Related: OS#1614
The VTY config allows above 32bit range extensions, but
db_subscriber_alloc_exten() was unable to generate extensions outside of 32bit.
Add VTY regression test and fix the problem by using proper 64bit types.
Related: OS#2253
Change-Id: I9afe6a8833004ecd2f3f936b2d5aa4de8e7dbcb0
Fix parsing of the 'subscriber-create-on-demand random' VTY: atoi() is not
enough to include the specified range of 1-9999999999.
Use atoll() instead to ensure a large enough number space also on 32bit
systems.
(Note: for me, atoll() truncates at 32 bit when <stdlib.h> is not included.)
Add a VTY regression test for this.
Related: OS#2253
Change-Id: I353e04481ec567adca383d6b51ba8fb865eed73e
* move value_string definition and corresponding functions for BTS type
to shared header to make it re-usable by OsmoBTS
* use consistent function naming
* add similar functions for BTS variant
* add enum to be used by OML Attribute Reporting to distinguish between
type, variant and other info
Change-Id: Ida94725a6fce968443541e3526f48f13758031fd
Related: OS#1614
Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until
we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we
can route this sms somewhere we can reach indeed.
After this change, the conversation looks like this:
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| SMS-SUBMIT | |
|------------------->| |
| | DELIVER-SM |
| |---------------->|
| | |
| | DELIVER-SM-RESP |
| |<----------------|
| GSM 04.11 RP-ACK | |
|<-------------------| |
| | |
Before this patch, the RP-ACK was sent back straight forward to the MS,
no matter if the sms can be route by the ESME or not. Thus, the user
ends up getting a misleading "message delivered" in their phone screen,
when the message may just be unroutable by the ESME hence silently
dropped.
If we get no reply from the ESME, there is a hardcoded timer that will
expire to send back an RP-ERROR to the MS indicating that network is
out-of-order. Currently this timer is arbitrarily set to 5 seconds. I
found no specific good default value on the SMPP 3.4 specs, section 7.2,
where the response_timer is described. There must be a place that
describes a better default value for this. We could also expose this
timer through VTY for configurability reasons, to be done later.
Given all this needs to happen asyncronously, ie. block the SMSC, this
patch extends the gsm_sms structure with two new fields to annotate
useful information to send the RP-ACK/RP-ERROR back to the MS of origin.
These new fields are:
* the GSM 04.07 transaction id, to look up for the gsm_trans object.
* the GSM 04.11 message reference so the MS of origin can correlate this
response to its original request.
Tested here using python-libsmpp script that replies with
DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see
here on my motorola C155 that message cannot be delivered. I have tested
with the success status code in the SMPP DELIVER_SM_RESP too.
Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
Use textual representation for message type and protocol descriminator
in case of Gb parsing errors.
Change-Id: Ida925258be119619d8705361730c554a130b75bc
Related: SYS#3610
Previously vty always used additional checks even for GEA0 (no
encryption) which resulted in misleading warnings. Fix this by
adding explicit check for GEA0.
Related: SYS#3610
Change-Id: I1ee468ab3298076d4cb5c7b1f6293c07e272417b
Previously we required pcap.h unconditionally which causes embedded
build failure because it's not included in current version of out poky
toolchain. We can add it to toolchain but it's only necessary for
utils/osmo-meas-pcap2db which is not built for sysmobts anyway so it's
easier to just make this dependency optional and build osmo-meas-pcap2db
only if it's available - similar to the way we build osmo-meas-udp2db.
Related: SYS#3610
Change-Id: I77a5f7eafe0282abedacffad6a9bcb0a8f2b5caa
Previously it was only in gsm_bts_model which is not initialized on BTS
side. It's more convenient to have it in the struct which is available
to BTS as well.
Change-Id: I54fde8c4ccd5d994af08074f5864446e79a93a25
Related: OS#1614
Supporting SI2quater as per 3GPP TS 44.018 will require chnages to the
way System Information is stored because it uses 1:n instead of 1:1
mapping between SI type and generated SI content. This should not affect
other SI types though. To facilitate this transition:
* convert the code to always use GSM_BTS_SI helper instead of accessing
buffer directly
* make helper more robust by adding extra parenthesis
* add similar helper for gsm_lchan
* add function estimating number of SI2quater message to hold configured
number of (U|E)ARFCNs
* add SI2q index/count fields and pass them to rest_octets generator
explicitly
* internalize buffer access in generate_si* functions
Change-Id: I74e4e3cb86364cec869a1472a41b4a95af0d50dd
Related: RT#8792
OpenBSC does not produce any installable libraries, only header files so
this section is unnecessary.
Change-Id: I4c563d775a84f41f82404e0eaba1a25fdbaac1a5
* set proper flag when saving MS Timing Offset
* use gsm_subscriber's IMSI or lchan's name if bsc_subscriber is unknown
* add comments with spec reference
* store/display MS Timing Offset instead of raw Timing Offset field from
RSL
* Compute MS Timing Offset [-63; 192] from Timing Offset field [0; 255],
adjust structure gsm_meas_rep with proper type to store it
Change-Id: I7e003d23a6edb714c5f17688fd6a8edac131161d
Related: OS#1574
It is defined in the file and used twice in there, so let's use it for
all of them which makes code smaller and more clear.
Change-Id: I9fac7cabedff74f8f6293ad8b54420229b80aa71
* add version string to gsm_bts
* add PCU version string to gsm_bts
* rename GSM_BTS_TYPE_OSMO_SYSMO -> GSM_BTS_OSMOBTS to avoid confusion
between BTS model and variant
* add variant enum to gsm_bts_model using enum with variants for each
hw vendor of OsmoBTS
* show connected PCU version (if available) in vty via 'show bts'
This will come in handy when logging details regarding particular BTS
reported via OML, see:
Related: OS#1614
Change-Id: I6710d53115f34634a7b70969cc05fd5c72ff8ab2
This option allows to enable or disable TCH/F allocation on the
TCH/F_TCH/H_PDCH timeslots. Until now, source code modification
was required to enable this feature.
Related: OS#1778
Change-Id: Id18cab25844dc854a66b4e2713e90c3f43afa712
From a human admin viewpoint it doesn't make sense to count the messages sent:
When we use TMSIs, we first send a LU Accept with a new TMSI, and then expect
the MS to respond with a TMSI Realloc Complete message. When that fails to come
through, the LU actually ends in failure, even though a LU Accept was sent.
If a conn breaks/vanishes during LU, we cancel the LU without sending any reply
at all, so the failed LU would not be counted.
Instead, count Location Updating results, i.e. completion and failures.
(With the new VLR developments, LU counters need to be triggered in completely
different places, and this patch prepares for that by providing sensible
counters.)
Change-Id: I03f14c6a2f7ec5e1d3ba401e32082476fc7b0cc6
Explicitly check for and log PCU version received from BTS via OML alert
message.
Change-Id: I3c88663d4e2887a4038b4c3f1387128295b8934e
Related: OS#1614
Add python client which converts TRAP messages into SOAP requests and
perform corresponding actions.
It can be used as follows
./soap.py -d -w http://example.com/soapservice/htdocs/wsdl/test.wsdl
See ./soap.py -h for additional options.
Change-Id: I82844ec7a302bac30d6daee9ebca2188fd48ca46
Related: SYS#3028
ericsson can handle a reference at the end of a imm assign command which is used in
the confirm response. The confirm response is only sent if the trailer is present.
Change-Id: I88560291b5a3a3d7a0bac4d3c089b45f1f6b297f
When the BTS is configured to use a SuperChannel and it is using a
unix domain socket based transport towards the L2TP daemon, then
we must instruct the L2TP daemon to instruct the SIU to change the Abis
Lower Transport Mode using the ALTCRQ / ALTCRP L2TP signalling.
Change-Id: I672bfaa09c42fbeb0c8459f24b2222b952de954b
Do not print anything to stdout directly - use proper logger object
instead: either the one supplied by IPAFactory user or default to NO-OP
NullHandler logger.
Change-Id: Ic3417095a6e8848f0acabb46a9e64c0197b736e2
Related: SYS#3028
The VTY tests assume that $top_builddir == $top_srcdir. Use the script's
location from sys.path[0] to find the correct locations of example configs even
when building in another directory.
Change-Id: I2731f361e3b72d0980968e6cf83594ea450db7c2
Previously any OML NACK message will result in BSC dropping OML link to
BTS which makes it impossible to use optional OML messages which might
be unsupported by BTS. Fix this for 3GPP TS 52.021 §8.11.1 Get
Attributes message. Also, log human-readable NACK name to see what
exactly causing OML link drop.
Change-Id: Ib8af2872c27abb793172ec59bdc145b8d54f83da
Related: OS#1614
In change-id Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3, libosmocore changes
from incrementing SQN after tuple generation to incrementing SQN before tuple
generation. Thus we now need to pass desired_sqn - 1 to get the same tuples.
Change-Id: Ifeda71e713bb60dcd31ac651f461b714cfa39b5c
Related: OS#1968 OS#1969
The timer T3186, which is described in 3GPP TS 44.060, is using 3
bits of the si13 mac block. This requires special encoding. In the
case of T3186, the value is encoded by the formula: bits = t/500-1.
Our implementation uses the formula bits=t/500, which is incorrect.
Change-Id: Ifd340c536cff2d1c4b1b3677a358ea95438801eb
Option "logging level ... everything" is broken for quite some time and
might be deprecated in future. Replace it with "logging level ... debug"
in config examples.
Change-Id: I828ef7671b4fb38717526a18ff8e9a5428cd511e
Related: OS#71
bsc_control.py lacks a copyright header. This commit adds the
copyright header from ipa.py to bsc_control.py.
Change-Id: Ie70bf686ee9bb157198e02bf8d946abf56adc82a
Fix uninitialized memory access warning.
"Conditional jump or move depends on uninitialised value"
Found by valgrind.
Change-Id: Ibc2d585c5db899e6af20104211e32faf3822633a
osmo-python-tests now includes code that retries connecting the VTY socket and
needs no external sleep()ing. This flies through most tests without any sleep()
at all.
See osmo-python-tests.git change-id Icc337f52a93d5fe31fc4ff235ccaf4e0fe75fa39
Change-Id: I42161d9716fe5bb0ef1c56e4bfb770bb99bbca7a
In a future commit, gsm_subscriber will be replaced by vlr_subscr, and it will
not make sense to use vlr_subscr in libbsc. Thus we need a dedicated BSC
subscriber: struct bsc_subscr.
Add rf_policy arg to bsc_grace_paging_request() because the bsc_subscr will no
longer have a backpointer to gsm_network (used to be via subscr->group).
Create a separate logging filter for the new BSC subscriber. The implementation
of adjusting the filter context is added in libbsc to not introduce
bsc_subscr_get/_put() dependencies to libcommon.
During Paging Response, fetch a bsc_subscr from the mobile identity, like we do
for the gsm_subscriber. It looks like a duplication now, but will make sense
for the VLR as well as for future MSC split patches.
Naming: it was requested to not name the new struct bsc_sub, because 'sub' is
too ambiguous. At the same time it would be fine to have 'bsc_sub_' as function
prefix. Instead of struct bsc_subscriber and bsc_sub_ prefix, I decided to
match both up as struct bsc_subscr and bsc_subscr_ function prefix. It's fast
to type, relatively short, unambiguous, and the naming is consistent.
Add bsc_subscr unit test.
Related: OS#1592, OS#1594
Change-Id: Ia61cc00e8bb186b976939a4fc8f7cf9ce6aa3d8e
Add MS TIMING OFFSET (3GPP TS 48.058 § 8.4.8) and P offset (3GPP TS
45.010 § 1.2) which can be used to compute MS TO from known TA.
This will be used by osmo-bts (see
I4dfe5c48834a083e757d5de3236a02e15a238b28) to provide MS TO as part of
RSL MEASUREMENT RESULT.
Change-Id: I8bda57c8d6c15bbb803eca708931556dae118a00
Related: OS#1574
When the IMSI ACL is maintained via the VTY, users may enter IMSIs
without leading zeros. Especially in test environments, where
MCC=001 and MNC=01 is common, it is likely that someone enters the
corresponding IMSI (001010000000001) without the two zeros at the
beginning.
This patch fixes the problem by sanitizing the IMSI, eventually
missing zeros in the beginning will be automatically added.
Change-Id: I56ba0da61978bbdce71d0e320166c52b20b42517
* print pdp->address instead of mm->imsi if mm is NULL
* print mm->imsi in debug log (move it below NULL check)
Change-Id: I4fbf5a54019a46612fbc528d61120182738f9205
Add via_ran to gsm_subscriber_connection to indicate whether a conn is coming
in via 2G/GERAN/A-Interface or 3G/UTRAN/Iu-Interface. Prepares for Iu, but
also for libvlr to decide between GSM or UMTS Auth.
Until actual Iu support is merged to master, this indicator will aid VLR unit
testing.
At some point we may also add RAN_GERAN_IU; it's not on the agenda yet, but to
clearly distinguish the names if we want to add it, explicitly name the ones we
have RAN_GERAN_A and RAN_UTRAN_IU.
Change-Id: I93b870522f725170e4265a5543f6b680383d7465
Make NEIGH an array of Javascript objects, otherwise the JSON is not parseable
when neighbours exist
Change-Id: I42029f40bf357adbb2f3c71cdcbafbc21090e348
Remove the fuzzer interface that was partially implemented in
gsm_04_08.c and silent_call.c is causing problems when an
SMS is sent during an active silent call. The reason for this
is that gsm0408_dispatch() in gsm_04_08.c would decide to
rout all uplink traffic to silent_call_rx() in silent_call.c.
silent_call_rx() is a stub function that discards the data.
This patch removes the fuzzer interface code by placing ifdefs
around it, so that it can be re-activated by experimentators.
Change-Id: Id500197d58663b3f4b1756136343670388b0a4bc
Similar to a recent patch in osmo-python-tests for VTY based tests, but this is
for the Ctrl tests.
The TestCtrlBase tests gave a constant sleep(2) grace period for the process to
startup. This causes tests to take minutes for no reason at all.
Add code to TestCtrlBase to try and connect right away, retrying up to three
seconds in .1 second intervals. This flies through most tests without any
sleep() at all.
Change-Id: I06569767153838bd9cd3edac001df5f6c567874c
When running the testBSCreload test in close succession, I get a "Connection
refused" error because the socket is still in TIME_WAIT state. Passing the
SO_REUSEADDR flag allows reusing the addr despite a TIME_WAIT socket.
Change-Id: I941851b062999ab4b962430f7b27c19935993e0a
If a pdp context is created a xid request is sent right after
the pdp-context-ack message. The sending of the pdp-context-ack
and the xid message is triggered from the GGSN via the GTP
interface.
When the pdp-context-ack message is not received by the MS, it will
send the pdp-context-request again. A lost pdp-context-ack is resent
by the SGSN directly so that the mechanism described above does
not work for pdp-context-ack resents.
This commit adds code to trigger the sending of xid messages also
for resent pdp-context-ack messages.
Change-Id: Ice66790803154310a61a70a54be76cec539c97a7
On 'auth-policy remote', the SGSN requires GSUP server address and port. If it
was missing, the SGSN would print a VTY warning and run anyway. Make this error
more fatal: print an error (flattened a bit) to stderr and abort the program.
Move validation of the GSUP server data presence out of the VTY command itself
and into the config reading function. This way the GSUP server config can be
given anywhere, including below the auth-policy config (was required above).
Don't care about setting the auth-policy to remote with a telnet VTY, because
in that case the GSUP client won't be started anyway.
Change-Id: I4d8db910c32abd8579d3c9b9f0b2cb3a9a6dfe4c
The general infrastructure for UMTS AKA is already in place:
* GSUP with capability to send us auth_vectors that contain
either triplets or quintuples
* mm_context that holds such auth_vectors
Add:
* capability to send UMTS AUTN in GMM AUTH REQ
* parse extended UMTS RES
* on auth response, validate expected AKA with vector and received res/sres
* add Auth Failure message to receive resync AUTS token and
* send to HLR
* clear out-of-sync auth tuple
* enter new state for when we're waiting for HLR to resync and send new
tuples so that the next Auth Request will be handled
Original first half of this patch by: Harald Welte <laforge@gnumonks.org>
Full UMTS AKA procedure including AUTS resync tested to work against OsmoHLR
with R99 USIM and Milenage algorithm.
The sgsn_test.c needs adjustment because we're checking the vector's auth_types
now.
Depends: libosmocore change-ids
I277fb3d407396dffa5c07a9c5454d87a415d393f
If943731a78089f0aac3d55245de80596d01314a4
Related: OS#1956
Change-Id: Ie6a0cefba5e4e7f02cc2eaf6ec006ac07d5c1816
Each running test would open up another socket without ever closing unused
ones. Close the sockets after each test is done.
Change-Id: I0a42caab3bb8c9c9d04b033e4de9efe0ca8fd2af
Prepare for replacing gsm_subscriber with vlr_subscriber. vlr_subscriber will
not make sense to be used in gprs, so have a dedicated GPRS subscriber struct.
(Could change if the gprs code were to use libvlr; is currently independent).
Related: OS#1592
Change-Id: Ia8b391ee009c8545763cba04505be3947835120e
With the OsmoMSC program coming up, the name osmo_msc_data becomes even
more confusing than it already is. Clearly indicate it as libbsc's data of
a remote MSC by prefixing with bsc_.
Also, the Osmocom community has in the meantime agreed to have the osmo_
prefix only in libosmocore, to avoid naming conflicts in case things are
moved there. So while renaming anyway, also drop the osmo_ prefix.
Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
With the OsmoMSC program coming up, the name osmo_msc_data becomes even
more confusing than it already is. Clearly indicate it as libbsc's data of
a remote MSC by prefixing with bsc_.
Also, the Osmocom community has in the meantime agreed to have the osmo_
prefix only in libosmocore, to avoid naming conflicts in case things are
moved there. So while renaming anyway, also drop the osmo_ prefix.
Change-Id: I13554563ce9289de126ba0d4cf329bafcda35607
We're discarding the name OsmoCSCN for the benefit of OsmoMSC. But "CSCN" has
already crept into the master branch in two places; apply the rename.
See OS#1958
Change-Id: Ib4274eb3c172ada1fe7f05746740b456370bc93d
Each running test would open up another socket without ever closing unused
ones. Close the sockets after each test is done.
Change-Id: Ie433c8560de54f9a9d05fa07c44bae3126d19b30
Doesn't make sense to switch this to struct vlr_subscr when it isn't used at
all. So let's remove it.
Change-Id: Ifa5901f8bf1aed3981841d24d4ec8d659f3de7a9
In libosmocore, my patch was merged to master a bit too soon. To accomodate the
request for naming that matches the general "LOG" prefix instead of "LOGGING",
a fixup was committed to libosmocore. Adjust for that.
Original patch: change-id I5c343630020f4b108099696fd96c2111614c8067
The fixup: change-id I424fe3f12ea620338902b2bb8230544bde3f1a93
Change-Id: Ib2ec5e4884aa90f48051ee2f832af557aa525991
The LCHAN and BTS filter contexts are actually never used, so drop them until
someone adds them properly.
For now use only LOGGING_{FILTER,CTX}_VLR_SUBSCR. Some of these will change to
_BSC_SUBSCR once struct bsc_subscriber is introduced, and later on, struct
gsm_subscriber will be replaced by vlr_subscriber so that the names will match.
Depends: libosmocore change-id I5c343630020f4b108099696fd96c2111614c8067
Change-Id: Ifa82f6a461ad4c0eeddb8a38fb3833460432d16b
Handle Delete Subscriber Data GSUP message from HLR to disable Packet
Services for a given IMSI.
Change-Id: I6b9b494fa58bcb95bd550c49f8204f00f8fdf628
Related: OS#1645
To be paranoid, catch a NULL subscriber and/or bts in
subscr_update_expire_lu(): print an error log and avoid segfault.
(I'm not sure this would really happen in a normal situation.)
During aggressive testing of Paging timeout, I came across this segfault in
msc_release_connection() when conn->expire_timer_stopped is set but
conn->subscr is NULL, at the subscr dereference after:
if (conn->expire_timer_stopped)
subscr_update_expire_lu(conn->subscr, conn->bts);
I brought this situation about by a fabricated Paging fault, i.e. in
gsm48_rx_rr_pag_resp() return 0 and don't call gsm48_handle_paging_resp() at
all. Thus conn->subscr is still NULL when expire_timer_stopped is 1.
When looking at CM Service Request handling, the conn->subscr is set before
setting expire_timer_stopped = 1, which is a saner thing to do. But without my
mad 'return 0', there is in fact no way to have a NULL subscriber there.
It looks like all other code paths already do the same, but it's not that
obvious (e.g. _gsm48_rx_mm_serv_req_sec_cb()). So rather catch this case of
NULL conn->subscr, and while at it catch NULL bts as well.
Change-Id: I430dd952b2b928bea7f8360f1e01bb3cccb0a395
* add vty command to set E-UTRAN_PRIORITY, THRESH_E-UTRAN_low and
E-UTRAN_QRXLEVMIN according to 3GPP TS 44.018 Table 10.5.2.33b.1
* remove old command which does not support those parameters
Change-Id: I36dcc79f7b7a02036e74720923d0df1a2a2db504
Fixes: RT#8792
Log more data related to channel allocation:
- channel type
- number of paging attempts
- timers fired
Change-Id: Ib417a9c942c17b902dd80ff555cd9da5f91bff48
Since ce9fec3e896571835ac5bfd2980d6836f2b29f0d libosmocore ignores
parameters to log_vty_command_* functions. Hence parameter of
logging_vty_add_cmds() is ignored too. As we depend on much later
libosmocore version anyway, we can simplify code somewhat by removing
parameters which will be ignored anyway.
Change-Id: I62f752fd88f1d8fefa563648f9864c7c31f87991
Postfix the ran type to clarify the purpose.
Because of the new support of the Iu ran type, there are 2 functions to allocate a mm ctx.
For Iu it's sgsn_mm_ctx_alloc_iu(). For gb it should be named in the same way.
Change-Id: Ic49009e8c20c12308855e1409c09004698c79b95
The fix introduced in dac5867af5 did not
work because autotools in our OE are too old. Use alternative way to
include custom m4 macros to fix it.
Change-Id: I5fe6d1180c2624cfe1d3673314f6846527a43464
Parse the longer UMTS res from the extended Auth Response Parameter IE.
Parse the R99 Authentication Failure and AUTS in case of cause
GSM_REJECT_SYNCH_FAILURE which indicates a SQN re-sync request.
Both still end in 'not implemented' error logs, which are the places where the
upcoming VLR that supports UMTS AKA will integrate.
Depends on recently added constants in libosmocore in
commit 55a43b801385e07a484217925ecf2379b9f54fcf
aka change-id I745061ce8eb88aa23080dadcdbfe2d703c362a30
Change-Id: I4868bbeedc32fa7b8d03b9e3c66db618543d38ec
The currently unused function abis_om2000_vty.c:con_group_del()
allows deleting OM 2000 connection groups. This commit adds a
matching VTY command to make use of it.
Change-Id: I39a90b06e19356c536cacd1c923e195dd305ab80
'self' will not be accessible in that context, so this patch isn't
useful.
This reverts commit b39053ad6d.
Change-Id: Ic1a9ba5fdfd7bdc6c5cf0974e8c637ae23b81ece
To be able to do R99 UMTS authentication, we need to send along AUTN bytes in
the Authentication Request. Add autn parameter to gsm48_tx_mm_auth_req() and
conditionally append the R99 AUTN TLV to the Authentication Request message.
Change-Id: I0d644559088706aa06b42b9bfe1f8c21ca6fa4da
Add verbose logging as well as three retries around the place that often
fails on our build server with a 'Broken Pipe' error.
Change-Id: I8851b76b2d7b87dd500ae40f47e6bea716ef3fc4
Check conn->subscr against NULL.
gsm0408_rcv_cc() dereferences many conn members without checking presence: the
bts and lchan members may be expected to be NULL in the ongoing MSC split and
3G developments.
But the conn->subscr is initially NULL, so an MS sending a CC message before
something like a LU or CM Service Request will result in a segfault. Prevent
that.
Note: the upcoming VLR will be more restrictive on what messages are processed,
this is a "backport" to the situation on current master.
Change-Id: If067db7cc0dd3210d9eb1da15be6b637795a3ecf
Added in recent commit 42def7205b
"Implement VTY configuration to control Early Classmark Sending"
Change-Id: Iaf640fa6e1f234f594fb8dc06f716d3d3e95eb2a
all other objects always use the MO instance. The existing code
likely is due to copy+paste mistakes.
Change-Id: Ie0a31cd93993da10f31eecf530a5a05773c11eb1
It is one of these changes that should have never worked but did
for a long time. Only recently a corrupted GTP message was seen.
The code in ccd2312d10 tried to
solve the right problem but was deeply flawed.
* Make the code operate on the copied message and not the original
one that is deleted by the underlaying layers on return
* Add an out variable to determine if the msgb should be deleted
and assume that by default it will be deleted.
Change-Id: I564526e7cde2b8a2f0ce900492cd38fc23c176a7
It is generally not a good idea to add more and more external
dependencies unless absolutely needed. autoconf-archive is a good
example of that, as we need to update all build machines, and older
OpenEmbedded versions do not appear to have (the right?)
autoconf-archive recipe. Provide local copy of necessary m4 files to fix
the build there.
The dependency to autoconf-archive was introduced in Change-Id
Ied9c950dafa65f324cf31298b13b590f56139700
Change-Id: Iacc1958b471ec3fc65307259039e1d496845f528
The ABI of libgtp changed and we require a new library now. Drop
the SO_VERSION from the library name and just depend on libgtp-dev.
Change-Id: Ib301b27e2c08fda827b55820389247e27e5e8fc7
in gprs_gmm.c:gsm48_rx_gmm_ra_upd_req the variable reject_cause
is not initalized, which is ok, since it gets initalized before
the jump into the "rejected" path. However, the compiler still
throws a warning. This commit fixes the problem by preinitalizing
the reject_cause to GMM_CAUSE_PROTO_ERR_UNSPEC
Change-Id: I84cffb631e4cad3d4748512b47e3876208f53727
In some cases, when successive mobile originated calls are made, the LAPDm UA
message gets lost because the channel is relased to early. Too overcome the
problem we do not send release indications immediately. Instead a flag will be
set and the message stored and sent on the next TCH-RTS-IND.
This commit adds the required flag and the msg-buffer to struct gsm_lchan.
See also coresponding change in osmo-bts.git:
Change-Id Ie4f70c75f0137b4bd72d579b3a32575bac2fca38
This patch is is a slightly improved/reformatted version of:
95d1f15ad1
Change-Id: I15fc1ef8e9e83f009bde96de9a8e95702cffbce6
The SI3 rest octests contain a flag that indicates if early classmark
sending is allowed in this cell or not. So far we always set this to
one, now it is configurable using the 'early-classmark-sending' command
at the VTY node.
Change-Id: Ia0b1cc5ab45673f3da70c59ae8917eba343f9862
There were some members that we neither set nor read, so let's
shrink the struct size and remove those unused members.
Change-Id: I02136e3aa91e58b2afc923c09c8693095497fdd7
When displaying the PDP context, it is quite useful to also show IP
address and TEI information about the GTP side of that PDP context.
Change-Id: I56ea530240c15b26729e7a42e539020cb1e233e5
cosmetic ws in common_cs_vty.c, osmo_msc.c
comment: tiny typo fix in gsm_04_08.c
In comments, drop some unbalanced braces, because simplistic C file harvesters
will break at a single opening brace even if it is in a comment. This is aimed
at the fsm-to-dot.py script in libosmocore/contrib.
Change-Id: I3c1fa53195a1e57d6fe0a6791c346d30ceff1251
When the creation of a new compression entity fails, an error
message is created, this error message contains printf with
a dereferentiation of the compression entity, that is clearly
NULL at that point. This commit corrects that.
Change-Id: I87371ade0ccd6a93b446f2013c1747f486739518
Use CTRL_CMD_DEFINE_RO(), CTRL_CMD_DEFINE_WO() and
CTRL_CMD_DEFINE_WO_NOVRF() where appropriate to get rid of boilerplate
code.
Change-Id: I5bcea0b4f4b8f535bef2b423f2013b8b4a218b5b
osmo-bts consumes the gsm_data_shared.{h,c} files and assumes the
OpenBSC directory layout. Install the files into the specific
sub-directories to make the --with-openbsc=dir option work.
Change-Id: I3da21402dee3d6f1d812b232b0a3f13b8a462d5b
* Explicitly check when ARFCN array split is impossible and return
gracefully instead of using negative index.
* Separate range encoding into generic function and use it for all
SI-related things.
* Propagate the error into that function and to its callers.
* Add separate test-case for the segfault previously triggered by this bug.
Change-Id: I3e049ab2d7c1c4d6c791b148f37e10636a8e43e0
Related: RT#7379
Previously reading from socket would block if no data were sent by
the server. Use non-blocking read for set and get operations.
Change-Id: I706d54a4a7ceef62683bf9a2fe63fc9ab331c24e
* clearly separate report parts
* use textual representation for failure cause if possible
Change-Id: I7a98a77011463021d0edd6ecfab1680e211f7e16
Related: OS#1615
Use osmo_strlcpy() to fix unsafe invocation of strncpy(), which potentially
left the result unterminated.
Change-Id: I1a119b1760a3e3262538b4b012d476fdce505482
Re-apply the reverted commit 98bc7fa50d, this
time with a clear error message in case autoconf-archive is not installed.
Change-Id: I631bde22e79ec0318eb9c8114db5861a1d635816
Tweaked-by: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Add openbsc-dev with source and header files necessary for osmo-bts builds.
Max's note: extracted from Debian packaging work into separate commit.
Change-Id: I25f8c639d2dc525ca280a7cd09de3ca6358d2568
The code checked 'if (strcpy(..) != 0)' which is always true and thus always
copied twice -- luckily we want to copy anyway and so this is not an actual
functional failure.
We could correct to strcmp, but instead of iterating to compare, we might as
well copy right away.
Change-Id: I0ea035bd478f7022ed65e9e84d8aaf5e423309b7
This introduces a failure with ./configure on my machine:
../configure: line 6612: syntax error near unexpected token `-Werror=implicit,'
../configure: line 6612: `AX_CHECK_COMPILE_FLAG(-Werror=implicit, CFLAGS="$CFLAGS -Werror=implicit")'
Makefile:420: recipe for target 'config.status' failed
make[1]: *** [config.status] Error 2
Installing autoconf-archive did not fix the error.
So even though jenkins seems to accept this, I cannot build with this patch.
Let's find out how to do this in a way that all systems can still build
and then re-apply this patch.
This reverts commit fd161ccce8.
Change-Id: I2b368500b07f233882ef854eca1fa21f6df39e29
Make warnings (when available) related to common memory-related issues
into errors to harden the source and decrease chance of errors.
Change-Id: Ied9c950dafa65f324cf31298b13b590f56139700
* add missing spaces after comma and minus
* prevent useless recursion calls
* mark static functions as such
* name and explicitly use enum for ARFCN range
Change-Id: If5b717445c8b24668bad0e78fd5bb51f66c4d18e
Call vty_init() before handle_options() to make sure the host.app_info is
populated before --version potentially tries to print it.
The segfault was introduced by 2c05f75bbf in a
recent MSC-split merge.
Change-Id: Ice91256d72b9eabd52709352ba6cc6a42af2921b
The term "phone" is incorrect. Rename phone to "MS" (mobile station)
in the comments and log output of gprs_llc.c
Change-Id: I322d3d99452502da7555cc2af6bc8a192ca3c9c5
In some rare cases the modem might send a xid indication that does
not contain anything except the version number field. The sgsn
ignors such SNDCP-XID indications by stripping the entire field
from the response. We found a modem in the wild that started to
act problematic when the empty SNDCP-XID was missing in the
response. This patch changes the XID negotiation behaviour in
a way that if a modem should send empty SNDCP-XID indications,
the reply will also contain an empty SNDCP-XID indication. Apart
from that the SNDCP-XID version number is now parsed and echoed
in the response. This ensures that we always reply with the version
number that the modem expects. (The version was 0 in all cases we
observed so far)
Change-Id: I097a770cb4907418f53e620a051ebb8cd110c5f2
Related: OS#1794
libosmocore change-id I857af45ae602bb9a647ba26cf8b0d1b23403b54c adds
OSMO_VALUE_STRING to compose value_string arrays with the exact enum names as
entries. Use instead of identical local macros in two places.
Change-Id: I1b44d2a3f293785a01d6a587c78f9e0cbeec70c3
gsup_test_client was added in 4f8e34b226 and
moved to libcommon in 2c1f8c8ceb, both of
which forgot to adjust the .gitignore.
Change-Id: Idd0d29a2f5c5b9b038103c955e0027d9ee9fee73
debian/control:
* restructure to make it easier to incorporate further changes
* update package descriptions
* update project URL
debian/rules:
* use proper hardening syntax
* restructure to make it easier to incorporate further changes
* remove useless comment
debian/compat: update compatibility version
debian/coryright: update to match Debian format
Change-Id: I49cc9239b15dc77d782914ca2547e601d049acdc
Related: OS#1694
* log xid type as string instead of int
* log packet encryption status, algorithm and IOV-UI in debug mode
* print encryption parameters when dumping llme via vty
* log key propagation from MM to LLC
Related: OS#1794
Change-Id: I30c38fdeb0b88bb39bdb9928851300bc79e6aec6
This option only served to demonstrate possibility of manually selecting
<id> field in CTRL protocol. Since the transition to generic ipa module
this is no longer exposed so the option became a no-op. Correspondingly
there's no need to explicitly initialize the RNG - the Ctrl class
handles random <id> generation internally.
Change-Id: I10cc7c069354cced2bba84fe67c69c28b8596ded
When passing a NULL config to osmo_oap_client_init(), set OAP to disabled
state. Along with the previous fix that ensures message rejection in the
disabled state, this makes use of OAP in the GSUP client optional.
oap_client_test: expect null config to set state to disabled.
Related: OS#1592
Change-Id: Ie4d622fcfd24cb7d89d19f93e4b2571d8fadd1a3
Fixes the bug indicated in oap_client_test.c: adjust to actually expect the
proper behavior.
Also adjust for modified return value for message rejection. Instead of -1,
just expect < 0.
Adjust experr for new error messages.
Related: OS#1592
Change-Id: I16165d228653e8a2689f9df94b77b470c06480c6
There is a hole in OAP where a disabled OAP still accepts at least a
Registration Reject message, after which it will do things it shouldn't. Show
this by expecting the bugs, to be adjusted with the upcoming fix.
Related: OS#1592
Change-Id: I4a5fde308b876946fea2571ea1a550f0cc7ee136
Use libosmocore's DLOAP logging category for OAP.
oap_client_test.c: make sure DLOAP is in DEBUG level to not lose any logging
messages from experr.
Todo: we're using a "Library" logging category, which is not really what the
library category was intended for. Instead, the OAP client should probably be
given a logging category like DVLR or DGPRS in its initialization API.
Related: OS#1592
Change-Id: Ic765c19381b0d983da90a5d8aee9cd17e31cf34a
Mainly to differentiate the OAP messaging API (osmo_oap_ in libosmocore) from
the OAP client.
This is in preparation for moving the oap client to libcommon, which is in turn
preparation for libvlr. Add the osmo_ prefix, as all public Osmocom API should
have. We also have OAP messages code in libosmocore, so clarify by naming this
osmo_oap_client, and by also renaming the oap_test to oap_client_test. This
reshuffling will allow an easy move of OAP to libosmocore if we should want to
do that. A number of patches will follow up on this.
Related: OS#1592
Change-Id: Id447d2bebc026a375567654adafa5f82439ea7e1
This corresponds to change-id If5099e60681a215e798b6675f21813f26769c253 in
libosmocore, which is now required to build openbsc.
Related: OS#1592
Change-Id: I2f06aaa6eb54eafa860cfed8e72e41d82ff1c4cf
Use the DLGSUP logging category for GSUP.
Bump the required version of libosmocore to 0.9.5 to benefit from the DLGSUP
logging category fix in core/logging.[hc].
(Id974c7be158e4d60421a98110f5c807aefd31119)
Todo: we're using a "Library" logging category, which is not really what the
library category was intended for. Instead, the GSUP client should probably be
given a logging category like DVLR or DGPRS in its initialization API.
Related: OS#1592
Change-Id: Id3938267fa062e1a997d3704cd678874306f86ee
This is in preparation for moving gsup to libcommon, which is in turn
preparation for libvlr.
Related: OS#1592
Change-Id: I9c95d00f1a9420887a44c938b1d0ee3e20586f4c
Make sure everything is named gsup_client_ / GSUP_CLIENT_.
Rename static gsup_client_send() to client_send() to avoid clash with public
gprs_gsup_client_send() being renamed to gsup_client_send().
This is in preparation for moving gsup to libcommon, which is in turn
preparation for libvlr. libvlr and osmo-sgsn will use the same GSUP client
code. A number of patches will follow up on this, also for the the OAP client.
Related: OS#1592
Change-Id: I57433973b1c4f6cc1e12e7b1c96b5f719f418b51
GSUP was added to libosmocore in 0.9.4. We're using it here, so make up for a
previously missing bump.
(BTW: I'm pretty sure that other dependencies are also in dire need of a bump,
but leaving that for another patch)
Change-Id: I4f245a7d78d0889b37084c52478372bddb8289d6
* replace some tabs indent with spaces
* add comment to make sure no new tabs are used for indentation by emacs
* remove unnecessary parenthesis
Change-Id: Ib79fd4317d40ee4fd87b090b9faf8ebaf4bfca64
Replace hackish ipa_send_* routines with proper implementation from IPA
module thus making it part of extended tests.
Change-Id: If13ed7fd243ce3aeef505d2e8468e221aa62f79e
This reverts commit 1611df5226.
This is due to a segfault introduced to the asan build only. See:
http://lists.osmocom.org/pipermail/openbsc/2016-December/009966.html
Subject: new sanitizer breakage: SIGSEGV in sgsn_create_pdp_ctx()
Date: Tue Dec 13 12:08:32 UTC 2016
Change-Id: Ic926c0e6778947b516994822e3a21d4fde25bb02
Enable Deactivate PDP context based on the IMSI of the subscriber.
When there are PDP contexts present for a MM context,
PDP context will be deactivated along with GMM Detach(MM context deletion).
If there are no PDP present, MM context will be deleted to avoid
further PDP context request from the MS.
Test cases is added to check this functionality.
Change-Id: Ia0a41aa2218ec2fda4ea17a37c8cc55cba63dd13
GSM48_CMODE_DATA_6k0 was not properly terminated and thus resulted in a
bug.
Change-Id: I4000f06d0b49c4afb0446beddd150521c4ba3cf0
Fixes: Coverity CID 148207
For TCH/F_PDCH in PDCH mode, directly return the lchan to use, in order to
switch it to TCH/F. To check the pchan type in chan_alloc.c, make ts_pchan()
public in gsm_data_shared.h.
Commit c3f72f63af broke TCH/F_PDCH, as a fallout
of setting the GSM_PCHAN_PDCH subslots number to 0. This is sane and correct,
but the chan_alloc code failed to see a ts as available if it has no subslots.
Explanation:
_lc_find_trx() checks each timeslot. For normal, static TCH timeslots we
determine the number of logical subslots contained and check whether one of
them is free. For dynamic TS, we can do the same when in TCH mode, but when in
PDCH mode, we already know that it is available for immediate switchover for
voice and hence can return it right away. TCH/F_TCH/H_PDCH already has a
special check for that. TCH/F_PDCH doesn't, but this worked for TCH/F_PDCH as
long as ts_subslots() returned 1 for PDCH: the for-loop at the bottom of
_lc_find_trx() checked one subslot, which succeeded on an lchan in PDCH mode,
since PDCH lchans are always marked type == NONE and state == NONE. Now we more
accurately acknowledge that a PDCH timeslot has zero subslots and that a
dynamic timeslot in PDCH mode can always be switched to voice immediately,
without checking lchan type or state.
So, above mentioned commit set PDCH to zero subslots, and the for-loop to check
the (zero) subslots never ran and hence never returned the lchan. This fix adds
a special condition for TCH/F_PDCH in PDCH mode, same as TCH/F_TCH/H_PDCH.
(Todo: ts_pchan() can probably be used in other places as well to remove some
code dup. Leaving that for another patch.)
Fixes: OS#1868
Change-Id: I5d555d018a5bcb8d948e54059d32ec4c9b3070d0
Preparing cosmetically for a subsequent commit which will add another pchan
kind to be checked, rather use a "switch (pchan) {}". Also reverse one if()
branch to "early-exit" style.
Change-Id: Ie5eb0fa859c4f225616095dc56d52ce0f2dc8bdc
This is useful particularly in case where we deactivate PDCHs
which don't have a SACCH associated. The existin code would
always attempt to deactivate a SACCH even in those cases, leading
to the BTS responsding with related error messages.
Change-Id: Iaf46782329b38ba8f3d438e6c75c2d467b852734
When the LLC-XID request is constructed the order of the elements
in the TLV structure is reversed. This is in theory not a problem,
but differs from what we know from our practical experience. This
commit fixes the problem.
Change-Id: I1d71c947350d3c5a85ff36b71c1b8f036071d162
This is intended to prepare for splitting gsm_subscriber_connection into BSC
and MSC specific structs, to make the splitting patch more readable.
Change-Id: Ib9666225fb9bfec2cf1e364343560571869fe6a7
Rename current subscr_con_allocate() and subscr_con_free to bsc_*,
and add two separate msc_subscr_con_allocate() and _free().
The msc_subscr_con_free() ignores all lchan members.
In libbsc use bsc_*, in libmsc use msc_*.
Change-Id: I3cf7c7cafdf4672ec7b26058bba8a77159855257
Future: there will be distinct subscr conns for libbsc and libmsc.
Leave the timezone VTY output in libbsc's config_write_net(), until the BSC/MSC
separation of struct gsm_network is completed.
Change-Id: I9712b2e07b4f1ab8d2e4ad40a8d771e98ed25b20
Time zone used to be configurable per-BTS. In the upcoming MSC-split, no BTS
structures will be available on the MSC level. To simplify, drop the ability to
manage several time zones in a core network and place the time zone config on
the network VTY level, i.e. in gsm_network. If we are going to re-add fine
grained time zone settings, it should probably be tied to the LAC.
Adjust time zone VTY config code (to be moved to libcommon-cs in subsequent commit).
Adjust time zone Ctrl Interface code.
Change-Id: I69848887d92990f3d6f969be80f6ef91f6bdbbe8
Implement connection_for_subscr() from a completely different angle: instead of
looking up lchans in bts structs, look up the subscriber in the global list of
gsm_subscriber_connection. static lchan_find() is thus obsoleted.
All callers of connection_for_subscr() live in libmsc, so move to libmsc.
The move and edit are done in a single commit since the old and new
implementation have nothing in common.
Future: osmo-cscn will use this, without bts being present.
Remove implementation of connection_for_subscr() from channel_test.c -- it is
possible that the abort() in there was intended for a regression test, but
actually it seems the implementation was merely added for linking reasons, and
the abort() added to guard against the NULL return value: no comment nor the
commit log indicate that the abort() is test critical; the addition was the
only change in channel_test.c for that commit; at the same time a
connection_for_subscr() call was added in libmsc.
Change-Id: I5e0ba0ecf1726ebd540800f4e98fdfc937c904ff
Keep only BSC specific bits of the 'network' VTY node in bsc_vty.c, move more
general VTY commands to common_cs_vty.c.
Add arg to common_cs_vty_init() to pass a config_write_net() function. Pass a libbsc
specific config_write_net() function.
Future: upcoming omso-cscn will re-use the VTY bits moved to libcommon-cs and pass a
different config_write_net() function.
Change-Id: I871b7b32a0c56fdce983e409cf244ec487d24e71
Move gsmnet_from_vty() and the bsc_gsmnet global to common_cs_vty.c.
Rename bsc_gsmnet to vty_global_gsm_network and make it static to common_cs_vty.c, to
clearly mark the global variable for VTY use only.
Introduce common_cs_vty_init() to set vty_global_gsm_network.
Change-Id: I26c5c47de08f899b896813d09612d5cb2f8e42d6
Now that bsc_network_alloc() is separate, move it to before the VTY init (a
subsequent patch will pass the gsm_network instance as a parameter to
vty_init()).
bsc_hack.c: drop the comment that says about the VTY init: "This needs to
precede handle_options()" -- it is not accurate. Actually move the
handle_options() above both vty_init() and the bsc_network_alloc() calls, to be
able to decide which mncc callback to pass to bsc_network_alloc. It would make
sense to set this later on, but that would require further refactoring of the
bsc_network_init() and gsm_network_init() signatures, so not in this patch.
Change-Id: Ie6a7037e703b5a2d08ceeb20d35f197aaddc9d1b
For patch clarity, keep some code dup to be removed in a subsequent patch. In
the same sense don't change the fact that mncc_sock_init()'s return value is
ignored.
The global gsm_network instance 'bsc_gsmnet' is basically only used by the VTY,
and a future patch will "hide" that global in a vty .c file. In a nutshell, I
want to
- first allocate a gsm_network,
- then initialize the VTY passing the gsm_network pointer,
- and then read the config file using the initialized VTY.
So far, bsc_bootstrap_network() allocates the gsm_network and reads the config
file right away, which only works by sharing the extern bsc_gsmnet pointer,
which I would like to uncouple.
Change-Id: I480a09a31a79766ad07b627dd5238b7e37f3be7a
libbsc and libmsc will have separate subscriber connection structs. Hence don't
rely on gsm_subscriber_connection, but work on a direct pointer to the counter
for the next RP reference.
The only very thin function in gsm_04_11_helper.c thus becomes obsolete: drop
the entire file.
Change-Id: I2a2e9ba6a981a385d1f8f07acbe03536ffed0072
Factor out encryption info from struct gsm_lchan as struct gsm_encr, placed in
common_cs.h.
Change-Id: I94015fb9dd511c37c1e3058a0963c780b3f700ac
Future: this will be used by libmsc's subscriber connection, for osmo-cscn.
Both libmsc and libbsc will need distinct gsm0480_send_ussdNotify() and
gsm0480_send_releaseComplete() functions, since there will be distinct
subscriber connection structs.
Rename to msc_send_ussd_notify() and msc_send_ussd_release_complete(), and add
the same in libbsc with bsc_ prefix in new file gsm_04_80_utils.c.
In preparation of this patch, the message generation part of these functions
has been added to libosmocore as gsm0480_create_ussd_notify() and
gsm0480_create_ussd_release_complete(). Use these.
Adjust all libmsc and libbsc callers according to use the msc_* or bsc_*
implementation, respectively.
Change-Id: I33a84e3c28576ced91d2ea24103123431f551173
For new MM contexts, the ra_id was correctly obtained from the ue_ctx, but in
case an MM ctx is re-used and the ra_id changed, the new ra_id was not copied
to the MM context; instead, the ra_id was overwritten with uninitialized data.
Always initialize the local ra_id variable from the ue_ctx->ra_id for Iu
connections; it is used further below to update the ctx->ra_id.
For the case of a brand new Iu MM ctx, the ctx->ra_id then gets initialized a
second time. We could technically drop the init in sgsn_mm_ctx_alloc_iu(), but
it doesn't hurt either way.
Fixes: CID#57936
Change-Id: Ia06458758362e76925690b1757d8ced95e9609e4
Coverity scan detects a Null pointer deref (FORWARD_NULL) in
gprs_sndcp_comp.c: 67 in gprs_sndcp_comp_create().
The reason for this is that gprs_sndcp_dcomp_init() and also
gprs_sndcp_pcomp_init() rely on the comp_entity->algo algo
flag. If the program logic is correct a null pointer deref
should never occur.
This commit adds OSMO_ASSERT() statements to ensure a null
pointer deref is catched if if the ...comp_init() functions
are used with incorrect parameters.
Change-Id: I7748f06d1739a697edad5100a031e5aa1ef11ed1
Used by libbsc, libmsc as well as osmo-bsc and osmo-bsc_nat.
Moving gsm48_create* to libcommon-cs affects linking of osmo-bsc_nat, resulting in
undefined references to gsm48_extract_mi() and gsm48_paging_extract_mi(); fix
that by placing libfilter.a left of libbsc.a upon linker invocation.
Change-Id: I212c2567b56191022b683674c1c4daf842839946
Reincarnate gsm_network_init() as the parts not specific to libbsc.
Move from bsc_network_init() those bits that are not BSC specific (and useful
for upcoming osmo-cscn).
Add libcommon-cs to all linkages that use gsm_network_init().
Note: the only requirement to allow linking gsm_network_init() without libbsc
is to keep the call to gsm_net_update_ctype() out of libcommon-cs. The other items
are kept out of libcommon-cs because it makes sense semantically. But the separation
is not strong in that the BSC specific data members are of course still
omnipresent in struct gsm_network. If bsc_network_init() is not called, these
are not initialized properly -- for now no users of uninitialized members
exist.
So this is just a first step towards a sensible split of the BSC and MSC
gsm_network structs. The long term aim should be to have entirely separate
structs with some common general items.
Change-Id: If06316b97002390dc9a434686750cb96193ea63b
bsc_network_init() is more fit to live in a BSC specific header, move it to new
common_bsc.h. It will probably also absorb the BSC-specific part of gsm_network
in the future.
Adjust header includes across the board. Particularly, fix abis_nm.h by
explicitly including gsm_data.h: it so far relied on other headers to do that,
which now is no longer always given.
Change-Id: I9edfb1e748bb1cb484fadd48b0406f5b3098e89b
The gsm_network_init() function initializes a whole lot of BSC specific stuff.
Aiming to move some of it to libcommon-cs, first rename it to bsc_network_init().
This will retain the BSC specific stuff when the move is done.
Adjust all callers.
Future: osmo-cscn will call the more generic part and not the BSC specific
part.
Change-Id: I4816ae19374390fc5c64972f7cad2e9ec3d8bcc3
Put mncc_recv_cb_t in common_cs.h to avoid header include complications: if placing
right above struct gsm_network, one must include gsm_data.h to use
mncc_recv_cb_t as function parameter in a header, which will include
gsm_data_shared.h, which will include common_cs.h (future knowledge). Since I will
need to use mncc_recv_cb_t in common_cs.h, including gsm_data.h from there would
introduce an #include loop. Avoid that and define mncc_recv_cb_t in common_cs.h to
begin with.
Change-Id: I2e64cffa563750ce9f3172ffba6f9cf5b9280e9c
Timer T3395 starts at the transmission of Deactivate PDP request using
pdpctx_timer_start but there was no corresponding stop function.
The timer is stopped when Deactivate PDP Context Accept is received.
This according to 3gpp spec reference 24.008 section 6.1.3.4.2.
Change-Id: I825c0a47d39e784dd1b8251f564609262530a5c6
This is a speculative change for interrogateSS and by not answering
the request the radio connection would remain open long.
The SS/USSD code is from a time where none of knew much about GSM. We
do not support SS but should reject it. We have checked for an empty
string in the text field to guess if it is a result/release to not send
more information. The right way forward is to decode the ASN1 into the
fields REQUEST/RESULT(last).
Fix an issue and make the code worse. Assume ss_code > 0 to see if this
is a interrogate invoke. The issue is that code 0 is a well defined
value but unlikely to be used.
MAP ASN1 definition:
SS-Code ::= OCTET STRING (SIZE (1))
-- This type is used to represent the code identifying a single
-- supplementary service, a group of supplementary services, or
-- all supplementary services. The services and abbreviations
-- used are defined in TS 3GPP TS 22.004 [5]. The internal structure is
-- defined as follows:
--
-- bits 87654321: group (bits 8765), and specific service
-- (bits 4321)
allSS SS-Code ::= '00000000'B
Change-Id: Ib0dc4485388f030eb172fe21f5327b7ab94751f5
When OM2000 has confirmed that a TS is started, call dyn_ts_init()
on the timeslot to start the processing for fully dynamic (osmocom
style) TCH/F_TCH/H_PDCH. This should in turn trigger the activation of
idle timeslots as PDCH until we want to allocate any of them for TCH/F
or TCH/H.
Change-Id: I1a1fd61d6afd85449cacad4bacfb830252dab6b1
Ericsson has introduced a propritary format to issue the S13 BCCH
information. Normally the system info type field for SI13 would
be encoded as 0x28. Ericsson encodes that field as 0x02 and ads
a bcch mapping parameter, (IEI=F2) This patch sets the BCCH mapping
to 0x00 (=BCCH Normal) statically (0xF200)
The new constands are added to libosmocore, see commit:
f0f9c8c29daaefbf9cff19177ade4a13ffb2e36c
Change-Id: Ie0900f9b810744172b3090ce1b0ef7b7a1132946
function bts_model_rbs2k_start() in bts_ericsson_rbs2000.c lacks
the feature definition for GPRS and EGPRS.
Change-Id: I777a67862084aa6cca39cfc43f5708e47608b0e6
This test is to trigger the use-after free issue in commit bff7b0d80972. If
compiled with address-sanitizer the test will abort without the fix.
Change-Id: I5e8c6626ba43342740f08d699383bdded739079f
Ticket: OW#3049
Sponsored-by: On-Waves ehf
In case the link_info is deleted we have to stop handling the stored messages
inside link_info. Not doing so can lead to invalid memory being accessed.
Change-Id: Ieb8503e9e94e7a5ac450ad8aa1713ec4f21cdea5
Ticket: OW#3049
Sponsored-by: On-Waves ehf
it seesm more recent RBS2000 models have much larger CCP and CI value ranges
than those of older models.
Change-Id: Ib116c1fac901b293929fce34223d1fd0af15d2bc
The code for supporting the configuration of the OM2000 CON (LAPD
Concentrator) MO was so far incomplete and not used from the OM2000 FSM
initialization. This patch adds
* VTY commands for configuration of CON Groups and Paths
* The FSM integration to actually configure the CON MO
Change-Id: I56dc1b5e35adef3a2078bcf9536537eb0f454192
This happens e.g. with DAHDI driver, when the DAHDI device cannot be
opened. Let's not prematurely seg-fault early in the RBS2000 signal
handler, but take the proper error handlign for this.
Change-Id: I9223fb1568d3db7e278f07240c4be334c6602a13
talloc_ctx.c: In function ‘talloc_ctx_init’:
talloc_ctx.c:40:2: warning: implicit declaration of function ‘msgb_talloc_ctx_init’ [-Wimplicit-function-declaration]
msgb_talloc_ctx_init(ctx_root, 0);
^~~~~~~~~~~~~~~~~~~~
Change-Id: Ib8ebc02d5cf0d2b4019473d3750ae7c6f8a32896
For TCH/F_PDCH, return an invalid chan comb (0) and print an error message
that hints at the proper pchan type to use instead: TCH/F_TCH/H_PDCH
Change-Id: Ibe0f944573f0a6d1be4bf7cf4986c4b2b3bd6d0d
When OM2K sets up the timeslots with the BTS, the dynamic channel state
is not yet resolved to any particular pchan type. Instead of using the
dyn state, always advertise dynamic timeslots as pchan2comb(TCH/F).
In the past, the Ericsson dynamic timeslots were handled as pchan type
TCH/F_PDCH. This is a mistake, as this pchan type is intended for
the ip.access dynamic PDCH way of dynamic channels. In any case, in the
initial state of this pchan type, the timeslot was initialized as
pchan2comb(TCH/F) because the ts->flags do not reflect an active PDCH
yet. In short, this patch does not change the behavior of TCH/F_PDCH
timeslots, only clarifies it.
It would in fact make sense to disallow use of TCH/F_PDCH for OM2K,
but that should probably be a separate patch.
The proper pchan to use for Ericsson dynamic timeslots is
TCH/F_TCH/H_PDCH. These do not use ts->flags, but ts->dyn.* as state,
which first reflects pchan_want == pchan_is == GSM_PCHAN_NONE. Hence
the timeslot was initialized by OM2K as pchan type zero, which is
unknown / invalid. So, instead of using pchan_is, which is not yet
reflecting anything meaningful, always initialize as TCH/F chan comb,
as Ericsson hardware apparently expects it.
Change-Id: If0693f7c5c85977b0e4acbc701ee5d635434d0d1
talloc_free the cfg only after asserting num_bsc count sanity.
This caused a failure in the 'bsc-nat' test with -fsanitize build.
Should fix the Osmocom_Sanitizer build on jenkins.osmocom.org
https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/
Change-Id: Ic20aacaccffcaa58ccec6d24c884727dc1bc50e6
Throw warning message in case the MO state does not change
to enabled after sendeing an Enable-Request message.
Change-Id: Idfde8d6f71526e8acfea51835732515a4bee858e
This patch adds support for ericssons sambm negotiation.
This patch depends on libosmo-abis commit:
2788c7eacab91cd39d68e316fc8ee87763bbfeb4
Change-Id: I56b1c1cef07a61143fc0e8058480805cddfeff96
This patch adds parsing for OM2000 MO fault report map parsing,
the bits in the fault maps are counted out and displayed.
Change-Id: I6e2928f39b09bc08e9ab78bc10bc81e07f7eb55d
Contrary to standard A-bis, in the RBS2000 case the BSC connects
the signalling data links (LAPD) to the BTS. In case one of them
drop, we need to attempt to re-establish them.
This requires libosmo-abis with Change-Id I07f0f79e0cda09766f357032ffb4e7ad643d448a
Change-Id: I710b5af5d0acbdd3febd314849340f2adb7abd80
In case of the sysmoBTS and receiving a channel activation ack on a channel
that was marked as broken, release it again.
Use a normal release without SACCH deactivation and release the rqd_ta data.
Also add a local variable 'ts' to shorten some lines.
The typical situation where this would occur is with high latency between BTS
and BSC (or NITB). If a channel activation ack does not arrive in time, a
channel is marked broken, and never recovers after that. This patch will
release the channel again, which will remove the BROKEN_UNUSABLE state and
makes lchan available again. Reported by Rhizomatica.
However, in case of packet loss, i.e. when the channel activation ack never
arrives at the BSC, this patch does not provide a resolution of the
BROKEN_UNUSABLE state.
On dynamic timeslots: clearing the dyn ts state could possibly happen in
lchan_free() instead of in rsl_rx_chan_act_ack(). That's to be done in a
separate patch, if at all.
Tweaked-By: nhofmeyr
Change-Id: I63dc0deaf15ba7c21e20b1e0c7b85f0437e183ed
The GTP protocol specification requires us to include the MSISDN IE in
all non-secondary PDP context activations. However, when no real HLR is
used (e.g. via GSUP), we do not have the MSISDN information available
and so far simply sent a zero-length MSISDN IE in GTP. The latter is a
violation of the spec.
So to resolve this, we now send a 15-digit all-zero dummy MSISDN IE, as
described in TS 23.003.
Change-Id: I8d0a5d52d6cd2a00b5dda060bd41d45056dfa84d
When receiving the 'Start Result' message, for CF and TRXC MO
we directly transition to performing the Operational Info. In that
case, we need to return after sending the Operational Info and skip
the usual processing for the default case below.
Change-Id: I99860d198b337ffe461b240bda20dc10e1b5b2cb
Our existing OM2000 code for initializing all Managed Objects of a BTS
at startup was never complete. Rather than trying to fix the old-style
code, introudce a hierarchy of osmo_fsm's reflecting the full protocol
hand-shake and sequence of bringing up the individual MO's.
If this works out well, it mihgt make sense to convert the TS 12.21 OML
code for other BTS models, too.
Change-Id: I3e11b28ba22b8c227e0401e6207fdda5381dda8c
Extend both 'show lchan <bts> <trx> <lchan>' and 'show lchan summary' to
include information on dynamic timeslots.
Have one common function that prints " as foo" or " switching foo -> bar" to
the vty, use it in lchan_dump_full_vty() and lchan_dump_short_vty().
In lchan_dump_short_vty(), split the vty_out call in two in order to interleave
the dyn ts info right after the pchan.
The summary hence looks e.g. like this for osmocom style dyn ts:
BTS 0, TRX 0, Timeslot 5 TCH/F_TCH/H_PDCH as PDCH, Lchan 0, Type NONE, State ACTIVE - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
or
BTS 0, TRX 0, Timeslot 4 TCH/F_TCH/H_PDCH switching NONE -> PDCH, Lchan 0, Type NONE, State BROKEN UNUSABLE - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
Change-Id: I3eb72ac7f0a520a8eefe171b9fb357f149aa3fda
count_codecs() is called on every chan act ack, also for channels other than
TCH/F and TCH/H. So this logging happens a lot during normal operation but adds
no real information.
Also, RSL would be the wrong logging category for this -- RSL is about the RSL
communications, not whether our internal code tries to count lchan codecs for
the wrong channel types.
Change-Id: Ibdac3bbe48745fe6a1c31d6f87369c9066c0374a
As per TS 23.014, a GSM MSC must implement mobile-originated DTMF
generation. We gate the DTMF signalling messages to MNCC, and expect
the external MNCC handler to deal with it. However, the internal MNCC
handler simply ignored such singalling messages, rather than rejecting
DTMF altogether.
It turns out failure to respond to START DTMF will cause some phones to
behave in interesting ways, particularly with modem
firmware v6.01.00, see https://osmocom.org/issues/1817). In this case
the phone is not able to release the call as the pending response to the
START DTMF is probably keping a reference or lock of some sort.
Change-Id: I336f0cd0a6396b522d228479a417fd4d606157ac
GSM 04.18, which is the successor of GSM 04.08, describes
additional RR 3g specific message types. This commit adds
log output for those messages. The behaviour is not changed
all affected message types are still forwared to the MSC
as they were before.
See also 3GPP TS 04.18, section 10.4, table 10.4.1
The change requires to update libosmocore as well, see
also commit f48fdb3a108da0dc23d7af4ac021e98e11f07152 in
libosmocore.git for details.
Change-Id: I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa
the OML attribute tables are hardcoded. To set variable parameters,
the hardcoded data structure (tlv) is patched on byte level during
runtime. This patch replaces this mechanism.
- Replace hardcoded OML attribute tables with dynamically
generated TLV structures.
- Add unit tests to check if the OML attribute tables are
generated correctly
- Put OML attribute table generator code in a separate file:
bts_ipaccess_nanobts_omlattr.c
Change-Id: Ibeb34a84912d6cf695f553a34c69320fca7d08fa
Use channel type name instead of number and log it with DEBUG facility
otherwise it produces lots of irrelevant messages for SDCCH*
Change-Id: I11b04e0cb02bf6ed01f6076cb31a56d8921d735e
- missing break in gprs_sndcp_pcomp.c, line 143
- string overflow in slhc_test.c, line 211
- sizeof mismatch in gprs_sndcp_xid.c, line 1369 and 1378
- mismatching signedness in gprs_sndcp_xid.c, line 1377
- needless < 0 comparison in gprs_sndcp_xid.c, line 477
- needless < 0 comparison in gprs_sndcp_xid.c, line 209
- missing returncode check in v42bis_test.c, line 320
- wrong pointer dereferentialization in gprs_sndcp_comp.c, line 73
Change-Id: I4f9adf251f5119e67ffe76baad6f1f996ac8dbad
When DL DTX is active and silent period is in progress dtx.cache is
populated by SID UPDATE message which about to be scheduled next. If at
that moment FACCH message arrives (which have higher priority) we have
to send ONSET message to L1 but we can't invalidate cache with SID
UPDATE as it will be used for SID FIRST message to resume silent period
after FACCH transmission is over (provided there were no incoming voice
in between). Hence the necessity for separate buffer to store content of
FACCH message while we're sending ONSET to L1 while keeping SID UPDATE
cached.
Change-Id: I316e81af893b24766bf259baaed7a0be75a11694
Related: OS#1801
We count the codec when the channel was successful setted up
Using sign_link->trx->bts instead of msg->trx to get the bts.
Add OSMO_ASSERT for bts within count_codecs()
Change-Id: Ib49c7c337980a7d6f189d7a0551ca2e4c3822f45
Value 4 used as magic number by both OpenBSC and OsmoBTS so it make
sense to add it to shared header. See
ebb483b69a5319e522ba5f713e9cb6f68a814a6a in osmo-bts for details.
Change-Id: I9c6ad68f4c6aa72d39ec7e5a6968b36ec20e79f4
Drop extern definitions of talloc_msgb_ctx and use msgb_talloc_ctx_init()
instead.
In sgsn_test.c, use a local variable msgb_ctx to do the talloc report
from the return value of msgb_talloc_ctx_init().
Change-Id: I2f9ace855f0ecbdc9adf5d75bcb1a3d666570de4
There's "channel-descrption bs-ag-blks-res" vty command which sets
BS-AG-BLKS-RES which might be too high if CCCH is combined with
SDCCHs. Previously proper value was silently enforced. Log this
situation explicitly and add spec reference to the comment.
Change-Id: I53e2b881fc28472d6709f063fb265a4e6a0fffcd
- consolidate all DTX-specific things in a separate struct
- rename struct fields to better reflect meaning
- add pointer to DL FSM for AMR
- remove unused flag
- expand buffer to hold cached payload alongside with CMR/CMI
Change-Id: Idac8609faf9b5ced818fde899ccfc6ed0c42e8fd
Just as a general precaution deemed to fit such a convenience function that
lives in libcommon, no actual failure observed.
Change-Id: I8e77fe1abc402469fd037e2fde2f46e2c8114f59
Found this by coincidence, no actual failure case was observed.
lchan_lookup() does have a return NULL code path, so we should not blindly use
its returned pointer.
Change-Id: I34ce126d36420b8194c88c0faa865294334a6658
This reverts commit 38e9ea3f7f.
Introduced a reproducable segfault, because msg->trx is not actually set/used
in the openbsc code paths.
Program received signal SIGSEGV, Segmentation fault.
count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
104 rate_ctr_inc(&bts->network->bsc_ctrs->ctr[BSC_CTR_CODEC_V1_FR]);
(gdb) bt
#0 count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
#1 0x0000000000425661 in abis_rsl_rx_dchan (msg=<optimized out>) at ../../../src/libbsc/abis_rsl.c:1516
#2 abis_rsl_rcvmsg (msg=0x8143f0) at ../../../src/libbsc/abis_rsl.c:2611
#3 0x00007ffff71420d0 in handle_ts1_read (bfd=<optimized out>) at ../../src/input/ipaccess.c:271
#4 ipaccess_fd_cb (bfd=0x815af8, what=1) at ../../src/input/ipaccess.c:386
#5 0x00007ffff7779b62 in osmo_fd_disp_fds (_eset=0x7fffffffe590, _wset=0x7fffffffe510, _rset=0x7fffffffe490) at ../../src/select.c:149
#6 osmo_select_main (polling=polling@entry=0) at ../../src/select.c:189
#7 0x0000000000406fac in main (argc=<optimized out>, argv=0x7fffffffe738) at ../../../src/osmo-nitb/bsc_hack.c:385
Add flag to explicitly track the state of DTX DL for AMR HR whe
SID_FIRST_P1 has been sent to L1 already but no next frame available
yet: this can be followed by SID_FIRST_P2 or SID_FIRST_INH depending on
arrival of voice frame within next 60 ms.
Change-Id: Id28b07b8e83cfe5e84de48a2f124084036580cd4
In addition to RTP payload SID cache got to store CMR/CMI prefix. Extend
the buffer so it can fit in.
Change-Id: Ibd4a63604a82cad3ce65f0752bffefa4b083e1b3
Fixes: Coverity CID#149508
active_calls describe all calls in active state.
call.complete Call got terminated by disconnect requested either by MS or MSC.
call.incomplete Call got terminated by any other reason.
call.active Calls reached active state.
Change-Id: I49b93af2e6a0ba16c2fb00b7b83974e8a6a16df3
Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I3b6d9ad4e5af44c2bdf3844c7bf8e8517bd61d8e
Tests for V.42bis, slhc, llc-xid and sndcp-xid are built and
executed on all build configurations, but are only needed when
the sgsn (gprs) is built. This patch adds conditions check
if the tests mentioned abvove are needed or not.
Change-Id: I6921e6198ea7f99fe5276f91cbc522091853bc4e
Most of this file uses four spaces of indenting. Replace all tabs with spaces.
Remove the erratic 'set' from the recently added vim comment at the bottom.
Change-Id: I4273b3314defb1e5b31b509c2ac7d7c6cd6834cf
Add option to TextTestRunner that shows print output on stdout.
It's better to see everything in our jenkins runs and not hide test output.
Change-Id: If4be1ad1c81c9ed4ab9b208b4c6d1e4b2cc8fdd5
After libosmocore 38d232ee5d2ceb045d9ad6d3a23afcb4972523f7 which outputs
'CTRL at <ip> <port>' from ctrl_interface_setup_dynip(), there's no need to log
the CTRL bind here anymore.
Change-Id: I1a874efe365a1ecf8ec37b058215b95b9a635ec2
Add a condition for GERAN Gb.
SNDCP and IuPS were developed on separate branches, and the merge results in
code trying to use an llme on a UTRAN Iu context where the llme is NULL,
leading to stack corruption upon PDP ctx act.
Change-Id: Ibb20d738c1b64d36630ce8eceb54c33ba4f1b003
In nat_msc_test(), upon socket timeout, retry up to six times. Reduce the
timeout between retries. This should get rid of sporadic test failures that
we've been seeing a lot on jenkins lately.
Raise an exception upon unexpected vty response.
Print more detail to stdout. Since we would actually want as much output as we
can get in a test suite, remove the 'if (verbose)' and just always print the
connection source. unittest is keeping all stdout silent by default anyway.
Change-Id: I2f83eef55592778e54164a90e1eabeb80fb918da
Use the recently added ts_is_tch() function instead of an explicit switch to
determine TCH pchan types. This is a cosmetic change since the bs11 does not
support dynamic channels (which was the main motivator behind ts_is_tch()).
Change-Id: Idf8ce51c76a83210fe3d70e18c51bbaffebb8ad5
Add ts_is_tch() in gsm_data_shared.h/.c and use it to replace a switch on the
pchan in e1_config.c.
This patch is not due to an actual observed failure. A general grep for switch
on pchan turned up this instance that doesn't handle dyn TS properly. Hence
this patch is not actually tested with real equipment.
Change-Id: Ide4f156034bab77140d2d9a8c462d68ae6f0d6a6
Add ts2comb() to switch on dyn TS so that dyn TS in TCH mode are also treated
like normal TCH/H or TCH/F pchans. Use ts2comb() instead of pchan2comb().
Change-Id: Iddc51a4409488d91db59228ca66aaab73ce3f1df
In gsm_data_shared.c, add ts_pchan() to determine actual pchan type for dynamic
and non-dynamic TS.
Use in ts_subslots() to fix the value returned for TCH/F_PDCH in PDCH mode.
Adjust the assertion in channel_test.c accordingly.
Drop GSM_PCHAN_TCH_F_PDCH, which is now handled in ts_pchan().
Explicitly add GSM_PCHAN_PDCH as zero in subslots_per_pchan[] (cosmetic).
Adjust the comment in subslots_per_pchan[].
The fix for the number of subslots affects only one caller: bts_chan_load() in
chan_alloc.c. Before this, it would always include a TCH/F_PDCH in the
load_counter->total, now it is skipped when in PDCH mode. Whether this is the
way bts_chan_load() should handle dynamic TS is a separate discussion, so far
I'm only making sure that the two dyn TS kinds act in the same way:
TCH/F_TCH/H_PDCH is only counted when in TCH mode, and TCH/F_PDCH should match.
Change-Id: Icd6668667ad2be7ad20866ffd185bf3b8711ccd6
This reverts commit 308cb0719d.
Problems in this commit:
openbsc/src/libbsc/chan_alloc.c:523: case GSM_PCHAN_TCH_F_PDCH:
This is actually wrong, GSM_PCHAN_TCH_F_PDCH use ts->flags, not ts->dyn below
(due to historical reasons and could be unified).
560: if (only_count_tch && !chan_is_tch(ts))
This has exactly one effect: it excludes GSM_PCHAN_TCH_F_PDCH when in PDCH
mode, because for all other PDCH (plain PDCH and TCH/F_TCH/H_PDCH in PDCH mode)
below ts_subslots() returns 0 and skips the for() loop. I consider this a bug
in TCH/F_PDCH, to be fixed in an upcoming commit.
I don't see why we need the only_count_tch argument, because this should
normally only count TCH, weren't it for the TCH/F_PDCH bug.
If dyn TS should be counted differently, we should do this in a different way.
Change-Id: I34dbbaf53a800115e3d03bd44028cad675f3b525
Add test_dyn_ts_subslots() and call from main(). Update channel_test.ok.
This includes erratic assert to show a bug for TCH/F_PDCH in PDCH mode: the nr
of subslots should be the same as for a normal PDCH, i.e. zero. This will be
adjusted along with the fix in an upcoming commit.
Change-Id: I09685be3fb3ed1ead4577b772a9fbc31967980d1
Move the main() guts to test_request_chan(), so that I can add another test in
an upcoming commit.
Change-Id: I1349d0f416806416080d4667ad697f7db1ea252d
After libosmocore 55dc2edc89c1a85187ef8aafc09f7d922383231f which outputs
'telnet at <ip> <port>' from telnet_init_dynif(), there's no need to log the
telnet VTY bind here anymore.
Change-Id: I97a730b28759df1d549a5049f47a3da1c16a3447
Instead of below error, raise an exception to describe what's happening.
Seen in a jenkins run on https://gerrit.osmocom.org/#/c/945/2:
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 787, in testBSCreload
msc = nat_msc_test(self, ip, port)
File "./vty_test_runner.py", line 1251, in nat_msc_test
return conn
UnboundLocalError: local variable 'conn' referenced before assignment
Change-Id: Iae26e7345267a21aed0b108b089453832889c9fa
The previous commit added a network backpointer to gsm_subscriber_connection.
Use it wherever it makes sense, to skip the step through the bts structure.
In some places, remove local variables that become unused.
Change-Id: I34537025986713291e14c8212a81539b497befd4
We want to be able to use a network backpointer without having to go through a
gsm_bts struct.
This commit adds the network pointer, the subsequent commit applies direct
access to the network structure from gsm_subscriber_connection.
Change-Id: If8870972f1b3e333c2a4cce97cdc95bdee0382a1
Add an explicit gsm_network pointer instead of using the bsc_gsmnet global.
This allows passing a gsm_network struct from the main() scope, which helps to
decouple libmsc from libbsc.
Change-Id: I9e2c0d9c18d4cebb5efb71565ad84df2bc2e0251
Decouple the talloc context allocations from global tall_bsc_ctx pointer.
It appears that talloc_ctx_init() was intended for general use, since it is
located in libcommon. It is currently used only by osmo-nitb; but the upcoming
osmo-cscn will use it as well.
Instead of defining in osmo-nitb main file, add definition in gsm_data.h.
Change-Id: I168106599b788f586be0ff0af4699b9746c1b103
Decouple the root talloc context from libbsc's global talloc_bsc_ctx.
This allows to define the root talloc ctx from a main() scope, which in turn
helps decouple libmsc from libbsc.
Change-Id: I92f6b47b1eeea2e8f3fba66f25d7e708e5659f8a
Replace the global sub_connections llist with gsm_network.subscr_conns.
Initialize and apply where applicable.
Remove bsc_api_sub_connections(), callers now access gsm_network->subscr_conns
directly.
This allows using the subscr_conns from libmsc without having to link libbsc.
Change-Id: Ice2a7ca04910bcfaaff22539abe68a6349e8631c
We want to create the telnet for VTY only after reading the config file, and
the dummy_conn was a workaround to be able to do so, but is not needed:
gsmnet_from_vty() used to expect vty->priv to point to a gsm_network struct,
but that is not actually the case anymore. It is using a static pointer to
store the gsm_network struct instead.
Change-Id: I51e7224c5a4cd5baf564bee871cf2fa6e885cda7
- Edit previously committed V.42bis implementation to function
outside IAXmodem.
- Add unit test to verify the correct function of V.42bis
Change-Id: I689413f2541b6def0625ce6bd96f1f488f05f99d
V.42bis is a data compression method found in modems. It has also
been specified for GPRS as data compression algorithm.
The implementation has been taken from IAXmodem:
https://sourceforge.net/p/iaxmodem/code/HEAD/tree/
svn checkout svn://svn.code.sf.net/p/iaxmodem/code/ iaxmodem-code
Revision: r36
Change-Id: Iabedece9f97ca944a1e3f747bb073e532c4e9dca
- Add module to handle compression entities
- Add module to control header compression
- Introduce VTY commands for heade compression configuration
- Add changes in sndcp and llc to integrate header compression
Change-Id: Ia00260dc09978844c2865957b4d43000b78b5e43
The previously pushed slhc implementation has been modified to compile
and function outside of the kernel. Also debug log messages were added
and datatypes ware matched. The implementation is now ready to be used
Change-Id: I7a638e88a43b3eb9d006751a03ef2570e36613f0
SLHC is an Implementation of RFC1144 TCP/IP header compression. We will need
RFC1144 compression to compress GPRS TCP/IP traffic. The implementation pushed
with this commit was taken from:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
commit 29b4817d4018df78086157ea3a55c1d9424a7cfc
Change-Id: Ied69c143678dc4a64cecc671f5c4dfebe19d8519
The SNDCP-XID (or layer-3 xid) is used to exchange layer-3 parameters
such as compression. The encoder encodes a bytestream that is then
sent as regular XID field from LLC.
We will need the SNDCP-XID to negotiate the parameters for our
upcomming GPRS data and header compression features
Change-Id: If2d63fe2550864cafef3156b1dc0629037c49c1e
gsm0408_dispatch() is the main entry point for receiving data from the BSC/RNC
level, so make sure callers pass valid pointers before using them all the way
down the code path (related to CID#93769, a fix before this was refactored).
For unknown/unimplemented packet discriminators, make sure to return error
codes.
Change-Id: Ieec39c74a53ef4dfa971dd935c8c9aa60fef58c1
Don't use quoted, local include, use <> style include.
Cosmetic: also move stdbool.h include to the top to keep osmocom and openbsc
includes grouped.
Change-Id: Iaa3dc36768f96f6b8c91010a2ba389fdc37f1503
Add vty function to explicitly set use of 4xRACH type of ack message for
PACKET CONTROL ACKNOWLEDGMENT. Previous hardcoded value (use RLC/MAC
control block) is used as a default.
This is handy for debugging issues related to Timing Advance in context
of GPRS.
Change-Id: Ie869ac0a82055110f1e3b875e246750c4e113336
Related: OS#1526
Add log_name to lchan_lookup() and pass such from the various RSL rx events
that call it to validate the RSL chan_nr.
Change-Id: Id81e7b8b9c27831923f050a78dfc7d650e687033
The message 'RF Channel Release due error 0' keeps catching my eye because
it says 'error' even though the error code is zero, i.e. no error.
This shall end now.
Change-Id: Ie0b9d62e8ce85a096c963931e0ae5527b8dc490a
smpp_try_deliver could fail with rc < 0. In such cases don't send the MS the rp
error sms rejected (cause 21). A rejected message should not be sent again. The
spec 04 11 recommends sending cause 41 Temporary failure in unknown cases.
Add also a log message and rate counter for such cases.
Tweaked-By: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Change-Id: Ia03e50ce2bd9a7d1054cc5a6000fd73bd3497c03
This is where IuPS will redirect GTP-U endpoints in a subsequent commit.
Also add comprehensive logging of pmm_state transitions.
Change-Id: I7c2cd1abc1805659b01dffffff31c49fe5161086
DEVELOPMENT HACK: Our current HLR does not support 3G authentication tokens. A
new HLR/VLR implementation is being developed. Until it is ready and actual
milenage authentication is properly supported, we are hardcoding a fixed Ki and
use 2G auth.
Change-Id: Ieca45960fa941a3a706c6e479b04b9f2ef89d860
In gsm48_gmm_sendmsg(), redirect to iu_tx() for both cases of MM context
present or not.
In gsm48_rx_gmm_att_req(), compose an MM context marked as Iu for messages
coming in from a ue_conn_ctx (passed in msg->dst). Also make sure cid is
initialized to avoid introducing a compiler warning.
In gsm48_rx_gmm_ra_upd_req(), look up an Iu MM context based on the presence of
the ue_conn_ctx in msg->dst.
In sgsn-test, add libiu and libasn1c, libosmo-sigtran, libosmo-ranap, which are
now needed for an --enable-iu build.
Change-Id: Ia47ffbfa6fa0f5a0cd76a379c57ef42faa0d80e3
Add file iu_vty.c in libiu, and iu_vty_init() to initialize the new VTY
command:
log
logging asn1-debug (1|0)
Change-Id: If4e7d0ab3fc2ed0cdf4fb0a3fa077a9e34890918
As the NITB has an internal SIGABRT handler that prints a talloc report,
let's also print a stack backtrace at the same point.
Change-Id: Ia63aa5c39b26e27c3ee220d755c17d2c1ef636c5
For Iu connections, msg->dst will point to the ue_conn_ctx, and we need to make
sure to keep msg->dst intact when copying from/to msgb and from/to MM context.
Change-Id: I90c7ca6c3655d447aaca958e0086ae6ce6f6045a
Bit 4 is reserved in 3GPP TS 04.08 so exclude it from the type.
In 3GPP TS 24.008 it indicates if a follow-on request is pending by the
MS, but only in Iu mode. According to the spec it is not required to
react to that request with a follow-on proceed so this field can be
ignored for now.
See 3GPP TS 24.008 Ch. 4.4:
"Unless it has specific permission from the network (follow-on proceed)
the mobile station side should await the release of the RR connection
used for a MM specific procedure before a new MM specific procedure or
MM connection establishment is started."
as well as Ch. 4.4.4.6:
"If the network wishes to prolong the RR connection to allow the mobile
station to initiate MM connection establishment (for example if the
mobile station has indicated in the LOCATION UPDATING REQUEST that it
has a follow-on request pending) the network shall send "follow on
proceed" in the LOCATION UPDATING ACCEPT and start timer T3255."
Change-Id: If1dff960c406060e257dafc54132687ffc42ad8f
With this commit the already existing XID mechanism has been
modified to suit the needs for the upcomming SNDCP-XID patches.
This commit should not break anything since it does not alter
the current behaviour (incoming XID is still just echoed, on
GMM-Reset a basic XID message is still echoed)
Change-Id: I65b9d625e72d3d61c99abdc7041773701d694d52
For some reason gprs_sndcp.h is located in src/gprs. This commit moves
gprs_sndcp.h to include/openbsc and fixes the include path in
gprs_sndcp.c and gprs_sndcp_vty.c
Change-Id: If4e4f1252c81d7907c1b4d738c982bb172b128c9
The lle-xid encoder/decoder is needed to encode and decode llc
xid parameter messages. We need this to exchange sndcp-parameters
(SNDCP-XID) and also simple parameters such as encryption IOVs
Change-Id: Ia06e4cb08bf9b48c2a4682606d1b1a91d19a9d37
In rsl_lchan_mark_broken(), call rsl_lchan_set_state() so the state transition
gets logged in the debug log.
Remove logging for the broken channel at the callers, instead log the error
actually in rsl_lchan_mark_broken() itself, with the reason message passed by
the caller anyway. (Removes code dup and ensures it's always logged.)
Change-Id: I54ae9bbd3f193bae7b1bda1fef3e33e62b353bf5
Actually schedule an activation timer for the activation part of a dyn TS
switchover. It needs to be restarted because the channel release procedure in
the first part of a switchover actually removes the activation timer.
Change-Id: Ibf50d13ba10298464a8b07e34716763161438990
The dyn_ts_switchover_*() functions made the impression that they act on a
specific lchan of a timeslot. The assumption that we would remember to use e.g.
lchan[1] across a PDCH deactivation is brain damaged to begin with; and
factually we always use lchan[0] anyway (the only case for using lchan[1] would
be when switching to TCH/H, but the channel allocator will always return
lchan[0] for that).
Instead of the brain damaged lchan args, use a ts arg across all
dyn_ts_switchover_*() functions, with one exception: The
dyn_ts_switchover_complete() actually receives an RSL activation ack message on
a specific lchan and needs to evaluate its lchan type. This will always be
lchan[0] as it is now, but we should stick with the lchan the message was sent
for.
For PDCH, a check to use lchan[0] already existed, when composing the ACT
message in rsl_chan_activate_lchan_as_pdch(). Replace with an assertion.
Adjust all callers to pass ts instead of lchan.
In dyn_ts_switchover_start(), there was a dead code check that jumps to
switchover_complete() in case the pchan already matches. This never hits,
because we only call dyn_ts_switchover_start() when pchans mismatch. So avoid
guessing at passing lchan[0] to dyn_ts_switchover_complete() by not calling it
at all but logging an error instead.
In rsl_chan_activate_lchan(), we remember some values before going into
switchover from PDCH. Explicitly store them in lchan[0], because after a PDCH
release we have always and will activate no other than lchan[0].
In dyn_ts_switchover_continue(), move the check for any existing lchan->rqd_ref
further above, and more correctly check all lchans that were so far valid on
the TS, instead of just one.
This partly prepares for a subsequent commit to fix the act_timer use for dyn
TS: with the old lchan arg, we might schedule an activation timer on lchan[1]
but receive an ack on lchan[0] (for PDCH), leading to an act_timer expiry.
Change-Id: I3f5d48a9bdaa49a42a1908d4a03744638c59796a
new counters are:
llc.dl_bytes
llc.ul_bytes
llc.dl_packets
llc.ul_packets
The ip payload bytes are waiting for payload compression
because those data are known then.
Change-Id: I068376d35e84283cb98523cd3097a12c55cdb709
For TCH/F_TCH/H_PDCH dynamic timeslots, the ts->pchan does not lead to a
meaningful value from the subslots_per_pchan[] array. Use the ts_subslots()
function instead, which checks for dyn pchan.
Change-Id: I659acebca82dfb3e305433471be64e9d27439af8
Add web application exposing Control Interface over web. All of SET, GET
and TRAP are fully supported.
Notice: TRAP is converted into 'Server-sent events' according to RFC
6202, see also https://www.w3.org/TR/eventsource/ - this requires
corresponding client.
Due to use of special prefix modified version of python
eventsource-client is necessary ATM.
Change-Id: I87d40c80061f8b3d02d656ab8cadabbfb871b461
Related: OS#1646
Add get_var and set_var functions which handle requested variable while
checking for proper response and id. Split header handling into separate
function.
Change-Id: I08705963c277bd93a011193dd7451a626d606c21
Related: OS#1646
According to documentation for Control Interface Protocol <id> is "A
numeric identifier, uniquely identifying this particular operation",
hence it's best to be illustrated with random integer - use it as
default.
Fix override of id with previously used python-specific objects' id.
Change-Id: I32236c067360526f4e7ee4bbdba64c5137de696d
Related: OS#1646
Commit ec1b5a0e9e introduced an unset cbits
value for the 'special hack for BCCH', where I break out of the switch
without setting cbits. Fix that.
Also remove the comment part that says 'return 0', because I don't return 0.
Change-Id: I54129d921807971eeafc23f80c57666c67b71377
In https://gerrit.osmocom.org/589 , msuraev reports an assertion on octphy.
So disable this recently added assertion until we clarify the invocation in
question.
Change-Id: Ia0f7ae5b114e179ab56b98adbae9810e81b4b88f
Many years ago, there was no difference between the libbsc support for
nanobts and sysmobts. However, this is not the case for a long time
anymore, and there are some specifics in OsmoNITB when it comes to
sysmobts. Let's have an example config file
Change-Id: I94ae57c9a3cb497ca39d56270fa15ed65d7f147e
Introduce explicit __main__ function to facilitate re-use of defined
python functions for ctrl interface.
Change-Id: I9bad8f0dd1d69bd28816bf047d85840e3411bb9c
Related: OS#1646
To avoid two phones picking mismatching TCH pchans, never pick TCH/F on dynamic
TS in osmo-nitb.
Add gsm_network flag dyn_ts_allow_tch_f, set to true by default in
gsm_network_init().
Set this flag to false in osmo-nitb's main().
See http://osmocom.org/issues/1778
Reasoning about ways to solve this:
* a compile time switch doesn't work because libbsc is first compiled and then
linked to both osmo-nitb and osmo-bsc.
* we could test net->bsc_api == msc_bsc_api(), but I have the so-called MSC
split waiting on branch sysmocom/cscn, which will result in msc_bsc_api() not
being linked in the osmo-bsc binary.
* have a function am_i_nitb() with different implementations in osmo-nitb and
osmo-bsc, but then we'd need to add implementations to all tests and other
binaries linking lchan_alloc().
* have a flag in struct bsc_api, but so far there are only function pointers
there.
Having a "global" flag in gsm_network allows to add a VTY command in case we
decide to keep this feature (#1781), has no linking implications and is nicely
explicit.
Tested that osmo-bsc still picks TCH/F on dyn TS indirectly, since I have no
standalone MSC available: when compiling osmo-nitb with the line that sets
dyn_ts_allow_tch_f = false commented out, TCH/F is picked as described in
OS#1778; and by printf-verifying that dyn_ts_allow_tch_f == true in osmo-bsc
main(), only osmo-nitb should have TCH/F disabled.
Related: OS#1778, OS#1781
Change-Id: If7e4797a72815fc6e2bbef27756ea5df69f4bde7
It's no longer just for IPAC style TCH/F_PDCH, but also contains code for
TCH/F_TCH/H_PDCH, so pick a more general name.
Change-Id: Ic19db81eca03fd72738839ee3686b6b4c8b6b437
Init both TCH/F_PDCH and TCH/F_TCH/H_PDCH via dyn_ts_init(), which
refactors dyn_pdch_init().
Make dyn_ts_switchover_start from abis_rsl.c public in abis_rsl.h, so we can
start the initial switchover to PDCH from dyn_ts_init(); in abis_rsl.h include
gsm_utils.h for enum gsm_phys_chan_config.
Change-Id: I5c0b257ba8ff0e9c9a2268681a84b0681a778368
In struct gsm_lchan, add dyn.rqd_ref and dyn.rqd_ta. These save the Channel
Requested details across the PDCH deactivation dance.
abis_rsl.c: add static functions:
* dyn_ts_switchover*() for the various stages of switchover between pchans.
* pchan_for_lchant() to derive the desired pchan from the lchan type that was
set during lchan_alloc().
* rsl_chan_activate_lchan_as_pdch() to compose the simpler RSL CHAN ACT message
without introducing numerous special cases to the normal RSL CHAN ACT code.
In rsl_chan_activate_lchan(), detect and initiate required pchan switchovers if
requested pchan on a dyn TS differs.
In rsl_rx_rf_chan_rel_ack(), initiate or continue pchan switchovers after a
channel was released.
In rsl_rx_chan_act_ack(), notice that a switchover is complete.
In chan_alloc.c, add ts_subslots(): abis_rsl.c will need to know the number of
subslots per pchan, to verify that all lchans are free before dyn TS
switchover. The subslots_per_pchan[] array is static to lchan_alloc.c, and
since we need a non-trivial check for dyn TS anyway, add public ts_subslots()
to lchan_alloc.c, which also checks the current dyn pchan type.
Change-Id: I5c6bce13092a10204113d84678c587c65e35e4fd
Change _lc_find_bts() to _lc_dyn_find_bts() with added dyn_as_pchan arg to
pass exactly as which pchan we'd like to allocate on a dynamic TS. Add
_lc_find_bts() as wrapper so non-dynamic-TS callers remain unchanged.
Also add dyn_as_pchan arg to _lc_find_trx() (not renaming to dyn and wrapping
because there is only one caller).
Implement dynamic allocator logic in _lc_find_trx() and lchan_alloc().
A returned dynamic channel still needs to be switched to the proper mode, which
will follow in another commit.
Replace a fixme comment with a normal comment in subslots_per_pchan[], because
handling of dynamic TS is now defined.
Change-Id: I18da7679300c43220d9baa6a304e8df74d366249
Accept GSM_PCHAN_TCH_F_TCH_H_PDCH for TCH/F and TCH/H if in matching pchan mode
or switching to matching pchan.
Accept RSL_CHAN_OSMO_PDCH chan_nr cbits for GSM_PCHAN_TCH_F_TCH_H_PDCH pchan.
Change-Id: If8f7c118f69e5a9f370bfe25f82f3d5a8de75b51
In gsm_lchan2chan_nr() use the current pchan type.
In gsm_lchan_as_pchan2chan_nr(), add the special case of non-standard cbits for
activating PDCH on a TCH/F_TCH/H_PDCH dyn TS. This way, gsm_pchan2chan_nr()
conforms to the standard and does not need access to a ts struct.
Change-Id: If248b9073b9f397110a2003d8e1a04afdc1c0e20
For upcoming dynamic TS, the pchan choice for RSL De-/Activation is not
trivial. So in order to pass the desired pchan to generate the RSL chan_nr,
introduce gsm_lchan_as_pchan2chan_nr().
To avoid code dup, this requires decoupling the gsm_ts2chan_nr() pchan from the
actual ts struct, so refactor gsm_ts2chan_nr() to gsm_pchan2chan_nr() with
explicit pchan, ts_nr and lchan_nr arguments.
Change-Id: I1a40e8452fe8120d350a27973e56be0b8c8c517f
Dyn TS will add a new type of chan activation, which does not need a Channel
Mode IE. Incidentally, the dyn PDCH also doesn't need this IE if it opts for
sending a PDCH ACT instead. So it makes sense to compose the Channel Mode IE
only after the dynamic decisions are done.
Change-Id: I66d88ad6a4ae7bee1e552960fd4e92aff953125c
System Information 13 field EGPRS PACKET CHANNEL REQUEST is
modified to support 11 bit RACH. Further VTY configuration is added
to enable/disable 11 bit RACH support in EGPRS. By default 11 bit
RACH support is disabled.
Change-Id: I51357bec936c28a26ab9ff5d59e0e30ca3363297
This function outputs a debug log without line ending, which should be
completed by a subsequent DEBUGPC(), so complete the started log line where
missing in three of the switch cases.
The three cases do print another log message, but since these don't start on a
new line when RLL is in debug level, the log output for these is hard(er) to
read without this patch.
Change-Id: I355647e77e1b2d8e75ae1a167fe87a507a38d82d
Incorrect regular expression used by default to authorize all
subscribers to implement authorization policy 'accept-all' prevented MS
from camping on the open network.
Change-Id: I20284b3d40ecf4ca1e67d8cd25afb8d5e4ae3025
It is particularly interesting to see whether a given lchan type is allocated
on a dynamic timeslot.
Change-Id: I8a0bca6d9cd583a0988e5ee8f4e6f74f218f4185
lchan_lookup in abis_rsl.c and rsl_lchan_lookup() from osmo-bts rsl.c are the
same code, except for the log context, which is only set in abis_rsl.c.
Factor out the common code to rsl_lchan_lookup() in gsm_data_shared.c.
Openbsc and osmo-bts each define their own DRSL log constant, so add an int *rc
return code argument and keep the logging part in abis_rsl.c's thin lchan_lookup()
wrapper. Incidentally, this also removes code dup for logging.
To avoid duplicate symbols, the rsl_lchan_lookup() implementation needs to be
removed from osmo-bts, so older osmo-bts git revisions will not build with
this.
Change-Id: Ie89bc5bb9110a0e539d37991dedac6f913211b48
Add state fields osmo_bts_trx_ts->dyn.* to record dynamic timeslot state.
Initialize in gsm_bts_trx_alloc().
Change-Id: I0a4049df8500b4f7c864f1355c4e9238932d1b8f
A new type of dynamic channel will be introduced soon, so prepare some comments
to name the dynamic TS kind more specifically.
Change-Id: I51fa8c2ebba507299e55a5cb7e67e48a6c8471f7
f9f4387686 introduced a check for ran_type,
which potentially leaves reject_cause unset. Fix that.
Change-Id: I0220841ff796f949d00a1415d46b54a3eacc9493
We keep some random snippets of documentation here, but manuals are now
generally kept in osmo-gsm-manuals.git. Particularly the GSUP, OAP and
control interface are documented more extensively there.
To avoid having two sets of (diverging) documentation, let's remove it
from the openbsc.git repository.
Change-Id: I4a4c918587e236a7aa00cf2bb6aa05b090f7229b
Add GSM_PCHAN_TCH_F_TCH_H_PDCH in gsm_pchant_names and gsm_pchant_descs: the
VTY and CTRL can now handle the new pchan type.
Adjust the CTRL iface test to expect the new PCHAN type in the output.
Fixes make check with --enable-external-tests after libosmocore commit
fd80f5a04239c2ab7b561401476dd89f2861748b that adds GSM_PCHAN_TCH_F_TCH_H_PDCH.
Change-Id: I4ad9c972d7f76f7e20cf74d6fc3d1928b644a4f8
Since the osmo_unixsock_listen() was moved to libosmocore
it would be better to use the library's implementation
instead of reinventing the wheel again.
Change-Id: Iacfc39b6214c24084438f8fe04d03952cdc9ebc2
Skip PDCH activation if the GPRS mode is 'none' at:
* TCH/F_PDCH init after OML Enable (dyn_pdch_init())
* after TCH/F_PDCH is released, in TCH/F mode
* in the T3111 error timer callback after a TCH/F_PDCH was released in error
state
Assert the GPRS mode in rsl_ipacc_pdch_activate() to make sure all callers
check the GPRS mode.
Closes: OS#1765
Change-Id: I970e5f9dbcb1c625209e914a4c7696294ed34e62
Split out generation and application of GEA gamma into separate function
which can be used for both encryption and decryption.
Change-Id: I442f2ead57e40d9bcd24e7f1b261041371595360
Related: OS#1582
According to 3GPP TS 24.008 § 4.7.1.2 some GMM frames are not supposed
to be ciphered. Propagate information about the necessity for
encryption between MM <-> LLC to ensure only proper frames are
encrypted/decrypted/dropped.
Change-Id: I0358905e60d1b182f75caec81bfcc72bbbbb2aa1
Related: OS#1582
It is already functional enough to allow testing with real
phones. However, note - there are several limitations in the current
implementation:
* only default value for IOV-UI is supported at the moment
* AUTN-based key material is not supported
Related: OS#1582
Change-Id: I8900b906693496e4e6b35be5a86937c58039ed9e
The A&C reference number specified in 3GPP TS 24.008 § 10.5.5.19
identifies particular request sent by network with the related response
sent by MS. The value transparently copied from request to response by
MS: the spec do not specify what exactly should be in there so we use
rand() to decrease chance for collisions.
Note: variable named 'rand' clashes with standard function rand() so it
was renamed.
Change-Id: I3638821a9b4a0532b28dbbb50faa30c4082579f6
Related: OS#1582
Have a bash function to build each dependency with the same commands. There is
a tradeoff: having each dependency build with the same function means you can't
easily tweak one of the dependencies. OTOH having a unified function means a)
more readable script, b) that we're sure not to forget some steps and c) no
need to do the same edit n times.
Set the PKG_CONFIG_PATH globally. Also a tradeoff: if a future addition
wouldn't need the same PKG_CONFIG_PATH, this would make things ugly. But that
is actually quite unlikely, and the readability improvement is substantial.
Use env variables to remember local paths. That means we always are sure to cd
to the same absolute base path, which a 'cd ..' can't guarantee; also, we avoid
possible typos for e.g. "$deps/install".
Change-Id: Ib23f86c6cc1441d882de59bcdde5de87fa4e9fdf
Without this commit it is possible that osmux is disabled again on links with
high jitter. This happens when an MGCP response without X-Osmux header is
received before the NAT receives an Osmux dummy frame from the other side.
Ticket: SYS#2628, SYS#2627
Sponsored-by: On-Waves ehf
Change-Id: Id624b0279aee5e2412059a10296ce7896e2d4628
Previously it was possible to start osmo-sgsn with "auth-policy remote"
but without "gsup remote-*" which resulted in broken setup: no MS could
perform GPRS ATTACH. Add consistency check to vty code to fix this.
Related: OS#1582
Change-Id: Ie4296e7d99d7833f7d828b0196435ea81097cf6e
Previously if subscriber was automatically created it got assigned
random MSISDN number. Make it optional (defaulting to previous behavior)
by adding following:
* new optional no-extension argument for subscriber-create-on-demand vty
command
* db unit tests
* vty test
Note: using the db made with new code might result in subscribers with
empty extension. Such subscribers cannot be deleted using old
code. Make sure not to mix db versions or manually fix it by editing
sqlite with external program.
Fixes: OS#1658
Change-Id: Ibbc2e88e4722b08854ebc631485f19ed56443cbb
The state is directly overwritten by the next function. Because
there isn't any state transition, remove this state.
Change-Id: I7f287692dbd559268fb5e61d81ac19e5dd4827eb
Always set CN domain in outgoing GSUP packets to PS to make it
compatible with osmo-auc.
Change-Id: Ia6ee2e55a41a8ea9e465d7df1b2b3559b553fca8
Related: OS#1582
Use correct vty command for subscriber deletion, adjust assertions
accordingly. The error was cause by inconsistent syntax of vty commands
for subscriber creation and deletion.
Change-Id: I9b9376b4ac0ec066000545167de312ca4460493b
In rsl_rx_rf_chan_rel_ack(), only activate PDCH when in NONE state.
For the case of REL_ERR state, do the PDCH activation in the error timeout
callback after T3111 is done.
Change-Id: I4c55479b252a12039bb3d8c30a9cbf0199ca410e
In gsm_lchant_name(enum gsm_chan_t), use the gsm_chan_t_names value strings
from libosmocore instead of redefining the same strings. The list from
libosmocore is also more complete, including CCCH and PDTCH.
Add a todo comment to move to libosmocore.
In consequence, libosmogsm linkage needs to be added to osmo-bsc_mgcp,
mgcp_test, mgcp_transcoding_test and smpp_mirror, smpp_test.
Change-Id: If65ee7c0619cbc0acb0a15045bd5a969442c93cc
Fail in configure if libgsm is not found.
Before this, the --enable-mgcp-transcoding would gladly accept that libgsm is
missing and the build would fail later because of missing linking and undefined
references.
Change-Id: Ic23157cc5b75694f400a176c31f97d71e861ea02
Do the PDCH DE/ACT before we set the lchan->state to De-/Activation Requested.
It makes more sense semantically to change PDCH mode while the lchan is still
in NONE status. Thus slightly move some invocations:
PDCH ACT: Free the lchan before PDCH activation. Hence remove the lchan_free()
call from the rsl_rx_pdch_act_ack() code path; it used to do the PDCH
activation first and call lchan_free() in the callback.
PDCH DEACT: Set the (TCH) Activation Requested state only within
rsl_chan_activate_lchan(), after the PDCH deact is complete.
Channel allocator: don't pick channels that have a PDCH PENDING flag set, to
avoid using channels that are still in PDCH switchover (despite their state
being NONE).
The lchan_may_change_pdch() sanity checks are becoming a lot simpler.
Change-Id: I4206dd4808e21c3e59393ea7f5ab4f438afff066
Set and clear pending flags on the TS according to PDCH de-/activation.
This will allow changing the time we set the channel state to after PDCH
DEACT and before PDCH ACT, in a subsequent commit.
Also add a sanity check on whether we're sending conflicting or superfluous
PDCH de-/activations on the same TS.
Change-Id: Ieae73271df749ded3d90585116aae01f3ad4ee74
Rename TS_F_PDCH_MODE to TS_F_PDCH_ACTIVE, to more accurately reflect the truth
value's meaning.
Add TS_F_PDCH_ACT_PENDING and TS_F_PDCH_DEACT_PENDING for sysmoBTS (and
possibly other BTS implementations) to remember what to do when the PCU replies
with a channel de/activation. Also add TS_F_PDCH_PENDING_MASK to test for both.
Change from #define to an enum.
Note: These flags are also used in the upcoming osmo-bts-sysmo dyn PDCH
commits, so osmo-bts submission depends on this commit.
Change-Id: I391a103ab599648b0c5d4f3ad613a6d7c48834b3
Previously if subscriber was automatically created it got assigned
random MSISDN number between 20000 and 49999. Make it configurable with
new vty command "subscriber-create-on-demand random" and expand vty
tests to check it.
Change-Id: I040a1d227b0c7a1601dc7c33eccb0007941408a6
Related: OS#1658
Previously length check have not considered AMR format which requires
extra byte for in-band length leading to SIGABRT on incorrect payload
from BTS.
Change-Id: I800f756fc803accace8c7e0b4a42b3744fe78bb6
Fixes: OS#1731
Add dyn_pdch_init() in new file bsc_dyn_pdch.c (new file to avoid linking
issues; bsc_init.c would create undefined references, and putting in a new file
is the easiest solution).
Call dyn_pdch_init() from nm_statechg_event() whenever a TS is enabled.
Revert the |= TS_F_PDCH_MODE chunk from previous commit, since this flag will
now be set after dyn_pdch_init() sent out the PDCH ACT and when subsequently
the PDCH ACT ACK messages are received in rsl_rx_pdch_act_ack().
Change-Id: I0cad93dec59d546b3f3b19e332e0833496031575
Remove check for dyn PDCH in _lc_find_trx(), instead call _lc_find_trx() via
_lc_find_bts() several times, so that pure TCH/F is preferred to TCH/F_PDCH.
Add this logic next to the other channel match decisions in chan_alloc().
BTW, the removed check in _lc_find_trx() whether PDCH is active is not
necessary, as described in the added comment for lchan_alloc().
Original patch idea by jolly, but split in two and implemented differently by
nhofmeyr.
Change-Id: I0c728b922656be03588b775638b610a93f8187d5
For chan_alloc_reverse, _lc_find_trx() should return the last free slot instead
of the first.
Original patch by jolly, but split in two by nhofmeyr.
Change-Id: Iff980242b9b5cb39345aaad0350ee368537677cd
Add bit which can be set on BTS side to indicate that next RTP frame
should be marked as a beginning of speech.
Change-Id: I355a5ae275a2743b29071924c916c4f68c3b3e80
Related: OS#1562
DTXd: to schedule SID repetition we have to know when previous SID was
sent (fn) and if it was UPDATE or FIRST SID (is_update).
DTXu: to properly set Marker bit in outgoing RTP we have to know the
beginning of talkspurt. For codecs without explicit ONSET event we can
do it by setting the flag (ul_sid) upon receiving SID and unsetting it
on speech frames.
Change-Id: I79cbec3b6c6fed5de385f8e202ceaf0b13234778
Related: OS#22, OS#1701
It is necessary for proper reporting of DTXd status during the
measurement period.
Change-Id: I4a033b03fcd0deb4db7a38273b5407511dbf1d6c
Related: OS#1701
In lchan_alloc(), there are several decisions to fall back to another type of
channel, followed by setting the channel type to the fall back type. So far,
this was set regardless of allocation success or failure.
If such fall back type is not available, do not modify the local type variable
and thus report an S_CHALLOC_ALLOC_FAIL on the type originally requested
(report is at the end of lchan_alloc()).
Change-Id: Ie3d4cb74f91db0b8c4f5e595a963099de339ad1a
libosmo-abis do not consider DTX bits while processing TRAU frames. As I
do not have equipment to test it, I'm not sure if/how non-IP BTS will
work in case of DTX - warn users about it.
Change-Id: I94ee69cd309fc343a428ddc66942cd57f2a34c05
Related: OS#22
Add missing mmctx NULL check in gsm0408_rcv_gmm(). gsm48_tx_gmm_status() would
dereference mmctx without checking, so we can't call it if mmctx == NULL.
Follows up on recent e98ba82d2b07c835:
"gprs_gmm.c: Don't try to de-reference NULL mmctx".
Change-Id: If59efbde86c76ffe91a0b33be87273783a2a4a02
Drop erroneous C from a DEBUGPC, should be on a new line.
Drop underscores from IPAC_PDCH_[DE]ACT: all other log messages for IPAC PDCH
are without underscores -- git grep "P(.*IPAC.PDCH.*ACT"
Change-Id: I8fb7a1c1beabb1f4388517383fd0bdc082d557ca
* extend "auth policy" vty command with new option "regexp"
* add vty command "authorized-regexp" for setting arbitrary POSIX
regular expression
* add basic vty test
* add optional "regexp" argument to subscriber-create-on-demand vty
command
With those in place we can now set the regexp against which MS's IMSI
will be matched.
If IMSI match the regexp than MS is allowed to access the network. If
subscriber is already marked as authorized in HLR than it'll be allowed
regardless of IMSI matching.
The same way we can decide whether to create subscribers on-demand
basesd on IMSI regexp match. Similar to authorization this restriction
can be overridden by manually creating subscriber via vty, ctrl
interface or directly in HLR.
Change-Id: I525f4b80676de47d1d422686da2ca012301b0129
Fixes: OS#1647
It's necessary to properly compute timestamp compensation for RTP
packets in case of DTX (or heavy packet loss).
Related: OS#22
Change-Id: Ib42c6a8614a4b73333a83181488dd4069cac14d7
Assert that llme is unused for non-Gb (Iu) connections, and clean up otherwise.
Make sure the cleanup is left below the sgsn_mm_ctx_free() call, as the comment
states.
Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f
In case the GMM message did not arrive over a Gb interface, there is no
LLME (and thus the associated pointer is NULL). Don't try to perform
operations on a NULL LLME.
Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e
Soem of the operations we perform in the GMM layer are specific to the
GPRS/EDGE radio access network and its Gb interface. Let's make them
conditional to that in preparation of supporting an Iu interface.
Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c
There was a comment in the code that certain GMM messages require a
valid mmctx pointer. However, nothing actually checked if that pointer
was in fact non-NULL. We plainly crashed if a MS would send us the
wrong message in the wrong state.
Original patch by Harald Welte, but it broke message validity checking,
resulting in sgsn_test failure. This re-implements the NULL check in a
different way, as explained by in-code comment.
Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8
This is the entry point for GMM from Gb. We will create a new one
for Iu, so let's be explicit rather than implicit.
Change-Id: I93c074bf99db041117c0dc03dc8255879845a875
Explicitly mark those sgsn_mm_ctx members that apply for Gb mode and (upcoming)
Iu mode, respectively.
Add some comments in sgsn_mm_ctx.
Change-Id: Ife9b02549f284e2547f16117cf43d7a36948fc4b
Tweaked-By: Neels Hofmeyr <nhofmeyr@sysmocom.de>
libosmocore changed in bf990bb8 Update internal GPRS cipher API
from uint_64 to uint8_t*.
Fix a warning.
Change-Id: Ib5bfe1fb05c693347b11ff4faadd3fc2205ebd76
Previously si2quater SI messages were always scheduled. Check for
neighbor configuration and only schedule si2q when necessary. Add
corresponding unit test.
Change-Id: Ibe997803ffb894133fd4d838410fe735791d414f
Fixes: OS#1727
Reviewed-on: https://gerrit.osmocom.org/81
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In GSM R99 SI6 has mandatory SI6 rest octets and so far we did
not include them. Add minimal support to generate the right band
indicator.
Target a slightly older version of the SI6 rest octets as we neither
support MBMS nor Random bit stream but should include the band
indicator.
Change-Id: I417a40eb91f42a3416b4e07bb9fb4d7a01aaa36b
Fixes: OS#1698
Related: OS#1725
Reviewed-on: https://gerrit.osmocom.org/71
Tested-by: Jenkins Builder
Reviewed-by: Max <msuraev@sysmocom.de>
Reviewed-by: Holger Freyther <holger@freyther.de>
In c09f8a3b7f as part of a cleanup
I accidently changed the talloc context from "con" to "bsc". The
issue occurred at an earlier commit when assigning req.ctx to the
"wrong" context. The allocation needs to be scoped by the struct
nat_sccp_connection and not the connection from BSC to NAT.
Before we have a nat_sccp_connection we scope the copied imsi to
the bsc_connection and then steal it, but for the identity resp
we will always have a nat_sccp_connection and can already use the
right context.
Change-Id: I53789aad2809e19338ad3b2deb72c4757e7bd524
Related: OS#1733
Reviewed-on: https://gerrit.osmocom.org/102
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Reviewed-by: daniel <dwillmann@sysmocom.de>
Reviewed-by: Holger Freyther <holger@freyther.de>
Make sure the version number of this sourcepackage is higher than
the one found in Debian SID.
Change-Id: I838632e9e90378a03235c2aebd5bc9ed06627ec8
Reviewed-on: https://gerrit.osmocom.org/113
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In AMR 12.2 (mode 7), the actual RTP payload is 33 bytes. Howeerver,
as we store the length of the (dynamically-sized) AMR payload in the
first byte, our buffer needs at least 33+1 byte in size.
Change-Id: If1ad5d2d68c85733306c75ea62f67fe8fbc143b3
Reviewed-on: https://gerrit.osmocom.org/91
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
In gsm04_08_clear_request(), in_release == 1 anyway and
msc_release_connection() would exit immediately without any effect. Don't
confuse the reader by passing release=1 arg.
Change-Id: I5bf9eb4889d32ad5e42ac7d096bf62fa3a493e20
Reviewed-on: https://gerrit.osmocom.org/93
Reviewed-by: Holger Freyther <holger@freyther.de>
Tested-by: Jenkins Builder
subscr_name() was called from several places:
* either without a check for subscr being NULL, which for example
was causing a segfault if we hand-over a channel before identifying the
subscriber
* or with an explicit NULL check and the ternary operator (?).
We now simplify the code by checking for the NULL Subscriber in subscr_name()
itself.
Change-Id: Ide09f4a515222eb2ec6c25e7a6a8c5f6cc2ffd4b
Reviewed-on: https://gerrit.osmocom.org/92
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Drop unused linking of libmsc, and drop duplicate linking of libbsc.
Change-Id: If2d63adb832c72ff1a22c25a78e06b0c244628d2
Reviewed-on: https://gerrit.osmocom.org/88
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Previously *FULL measurements were always used for handover
decisions. Those are incorrect in case of DTX - check if it was enabled
and use *SUB instead.
Note: *SUB values have higher variance so there might be more "bad"
values compared to *FULL although real quality remains the same.
Change-Id: I95e8e544047a83a256e057a47458678f40a19a15
Related: OS#1701
Reviewed-on: https://gerrit.osmocom.org/66
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
* Add per-BTS DTX settings
* Configure Uplink and Downlink DTX separately
* Deprecate global DTX option (it was never tested/used anyway)
* Use libosmocore function for DTX indicator in System
Information (previously it was incorrectly assigned for half-rate
channels)
Related: OS#22
Change-Id: I3d55168475ad47044b6238b55846ea22bdd518a4
Reviewed-on: https://gerrit.osmocom.org/40
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Move copy-pasted code into separate function to make writing more tests
easier.
Related: OS#1658
Change-Id: I9e39af85718514dd0f081d41c234c9dda77c4b27
Reviewed-on: https://gerrit.osmocom.org/43
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In the past, normal migration was possible only if the actual
schema version differed from the version used in DB by 1. For
example, if DB uses an old version 3 and you need to use it
with the code written for version 5, the check_db_revision()
will convert it to 4 and DB will still use incompatible schema
version during Osmo-NITB running time. After next run it will
be converted to version 5.
This patch replaces a set of 'else-if' checks by a 'switch'
without 'break' statements between 'case' labels (waterfall).
It makes you able to migrate from current version to the
latest despite any difference between them.
Change-Id: Ia9c2aa86f96b88ad8a710d0a23879ce219bc82dc
Reviewed-on: https://gerrit.osmocom.org/62
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In commit 4adb136da6 we introduced
a new authentication state SGSN_AUTH_AUTHENTICATE, but we didn't
add that to auth_state_names[] resulting in log messages printing
it abut 'unknown 0x1' rather than something more useful.
The existing GSUP code expected the subscriber data to be piggy-backed
onto the location update response, rather than a separate (and nested)
insert subscriber data request/response phase.
With this patch we should now support both the nested as well as the
piggy-backed version.
In general, if a function generates output data like a msgb (or in this
case filling an osmo_oap_message structure), the output argument
precedes the source. This is what we use all over libosmo*, and it is
modelled after memcpy(), where dst is the first argument, before src.
Let's align osmo_oap_decode(). Intestingly, osmo_oap_encode was already
correct, so the encode/decode functions used different conventions
before.
This rename is the first step of moving the associated functions into
libosmocore.
Also, rename gprs_match_* to osmo_match_shift_* to indicate that it is
not just matching the TLV, but also shifting the data portion.
This is a preparation to move the related code to libosmocore, whilst
at the same time generalizing it from GPRS Subscriber Update Protocol
to the Osmocom Generic Subscriber Update Protoco.
Rather than having a 'private' structure for kc, sres and rand, we
now finally (with 4 years delay) use osmo_auth_vector from libosmogsm,
which encapsulates authentication vectors that can be either GSM
triplets or UMTS quintuples or a combination of both.
gsm_auth_tuple becomes a wrapper around osmo_auth_vector, adding
use_count and key_seq to it.
key_seq is no longer initialized inside gprs_gsup_messages.c, as there
is no CKSN / key_seq inside the message anyway. If a usre of the code
needs key_seq, they need to manage it themselves.
In case both TCH/H and TCH/F or different codecs are configured and
internal MNCC handler is used we might end up in a situation where call
legs with incompatible channel types or codecs would be connected
resulting in a broken audio. Disconnect such calls with appropriate
error message.
Fixes: OS#1663
This adds a very basic, use once example in python on how to connect
and deal with the app specific payload and messages. The code is not
complete as the invokeId should be patched according to the initial
invoke. This excercise is left to future readers of that code.
* support for sending arbitrary static SI2quater.
* vty interface for neightbor EARFCNs specific to SI2quater.
* dynamic generation of SI2quater messages.
* unit test for SI2quater messages.
Fixes: OS#1630
Move define to header file.
Use inline functions where appropriate.
Change int variables which are used as boolean into actual bool to make
code easier to follow.
Use the simpler approach and just call encode('hex') on the str and
then convert it to lower case to keep the tests working.
reproduce:
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d = '\0\0'
>>> d
'\x00\x00'
>>> "".join("{:02x}".format(ord(c)) for c in d)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <genexpr>
ValueError: zero length field name in format
fixes:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 658, in testBSCreload
b0 = nat_bsc_sock_test(0, "lol")
File "./vty_test_runner.py", line 1150, in nat_bsc_sock_test
ipa_handle_small(bsc, verbose)
File "./vty_test_runner.py", line 1116, in ipa_handle_small
s = data2str(x.recv(4))
File "./vty_test_runner.py", line 1100, in data2str
return "".join("{:02x}".format(ord(c)) for c in d)
File "./vty_test_runner.py", line 1100, in <genexpr>
return "".join("{:02x}".format(ord(c)) for c in d)
ValueError: zero length field name in format
----------------------------------------------------------------------
If we want to separate the BSCs we should separate based on
the source port and not the source ip (at least in the current
test setup).
Fixes:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 658, in testBSCreload
b0 = nat_bsc_sock_test(0, "lol")
File "./vty_test_runner.py", line 1145, in nat_bsc_sock_test
bsc.bind(('127.0.0.1' + str(nr), 0))
File "<string>", line 1, in bind
error: [Errno 99] Cannot assign requested address
----------------------------------------------------------------------
Update the comment to reflect that the NAT itself will bind to port
5000 and then the mock MSC will fail to bind to it. Try to move the
mock MSC to another port.
Could fix:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 654, in testBSCreload
msc = nat_msc_test(self, ip)
File "./vty_test_runner.py", line 1101, in nat_msc_test
msc.bind((ip, 5000))
File "<string>", line 1, in bind
error: [Errno 98] Address already in use
----------------------------------------------------------------------
Don't assume that one can just bind to a local address that has
not been configured. Remove the unspecific comment as I don't know
to which other tests it is referred to.
This should fix:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 655, in testBSCreload
msc = nat_msc_test(self, ip)
File "./vty_test_runner.py", line 1102, in nat_msc_test
msc.bind((ip, 5000))
File "<string>", line 1, in bind
error: [Errno 99] Cannot assign requested address
----------------------------------------------------------------------
Add vty tests for BSC configuration reloading.
Load BSCs configuration on bscs-config-file command:
* remove all runtime configured BSC not in the config file
* close connections to all BSC with updated token value
Fixes: OS#1670
Sponsored-by: On-Waves ehf
Introduce new configuration option bscs-config-file which includes BSC
configuration from the given file. Both absolute and relative (to the
main config file) paths are supported.
Add 'show bscs-config' command to display current BSC configuration.
Note: it is still possible to have BSC configuration in the main
file (provided proper index number is used) and in runtime but BSC
configuration is no longer saved automatically. The management of
included configuration file is left to external tools.
Update configuration examples.
Fixes: OS#1669
Sponsored-by: On-Waves ehf
Factor out 2, add 3 functions. Those functions are simple wrappers
around hex strings specific to IPA protocol. Not all of them are
utilized at the moment but they were checked with wireshark while
working on the tests. It might come in handy if we'd like to further
expand related test harness in future. The same goes for optional
verbosity argument which is not used right now but will be handy for
future debugging.
Extend the existing ctrl command to be able to specify the
algorithm and Ki. In contrast to the VTY no size check is
done. Together with the VTY this code only supports a small
part of what is supported by libosmocore.
The algorithm and ki are considered optional but if a valid
algorithm other than "none" is passed, a KI must be passed as
well.
Extend the test coverage by passing the potential values. It
is not verified that the KI/algorithm is stored.
We should not return a subscriber in case it was not written to
the database. Instead free the memory allocated and return NULL.
Callers in gsm_04_08.c are prepared to have the creation fail.
Related: OS Issue #1657
The issue of db_create_subscriber updating an already existing subscr
is that the same subscriber will then have two entries in the active
subscribers list. In general this will break assumptions that a subscr
can be compared by comparing the pointer.
In the case of the VTY this was not an issue as the created subscr
was immediately destroyed again but it is better to avoid this problem.
Change the VTY command to find the subscriber and then call sync to
have the updated time set. The side-effect is we will now have two
queries for the subscriber. Once through subscr_get_by_imsi and once
through db_create_subscriber.
Change the db_create_subscriber to fail if a subscriber already exists,
and add a testcase for this behavior and do not updated the 'updated'
timestamp of an already existing subscriber.
Add a testcase for this behavior.
Related: OS Issue #1657
Add testcase to issue the subscriber create twice. db_create_subscriber
in db.c will first try to find the subscriber and if it exists, it will
update the "updated" column in the database.
Related: OS Issue #1657
The ip.access nanoBTS seems to have severe issues with BSSGP when
changing the country code and/or network code. It is unlikely that
the proprietary code is getting fixed so we extend the parameter
for the apply-configuration command to carry the 'restart' param.
The nanoBTS continues to be buggy and seems to have broken BSSGP
when changing SIs across new OML connections. Add an easy command
to force the reboot of the system through OML.
Make sure a new auth tuple is initialized after
db_get_lastauthtuple_for_subscr() returns an error, i.e. if no tuple is present
for the subscriber yet.
Before this patch, the first key_seq depended on the typically uninitialized
value that was present in auth tuple's key_seq upon calling
auth_get_tuple_for_subscr().
The very first key_seq used for a new subscriber will now always be 0. Before,
it used to be mostly 1 ("(0 + 1) % 7"), but depended on whether the key_seq was
indeed initialized with 0, actually by random.
In auth_get_tuple_for_subscr(), add missing condition to match incoming
key_seq with stored key_seq, so that re-authentication is requested for
mismatching key_seqs.
Add test for this issue.
Instead of using hardcoded -1 for errors, include -1 in the enum auth_action
type; apply its use.
In the mm_auth test, the string output changes from '(internal error)' to
'AUTH_ERROR', since now the proper enum value is used in auth_action_names[].
Test two situations for AUTH_DO_AUTH_THEN_CIPH:
- when no auth tuple is available
- when the key sequence from LU is marked invalid
Add convenience auth tuple comparison function using stringification.
Add basic MM Authentication test setup, with fake DB access and RAND_bytes().
So far implement simple tests for IO error during DB access and missing auth
entry.
To print the auth action during tests, add struct auth_action_names and
auth_action_str() inline function in auth.[hc].
Don't store an MSC index number in the vty->index void* value. Instead,
store the osmo_msc_data struct directly. Thus avoid warnings about
differences in int vs void* sizes, and save some index lookups.
In OpenBSC, we traditionally displayed a TMSI in its integer
representation, which is quite unusual in the telecom world. A TMSI is
normally printed as a series of 8 hex digits.
This patch aligns OpenBSC with the telecom industry standard.
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
mgcp_transcode.c: In function 'decode_audio':
mgcp_transcode.c:332:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_ERROR,
^
mgcp_transcode.c:332:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'long unsigned int' [-Wformat=]
mgcp_transcode.c: In function 'encode_audio':
mgcp_transcode.c:390:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_INFO,
^
mgcp_transcode.c:390:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'size_t' [-Wformat=]
mgcp_transcode.c: In function 'mgcp_transcoding_process_rtp':
mgcp_transcode.c:542:5: warning: format '%d' expects argument of type 'int', but argument 9 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_NOTICE,
^
mgcp_transcode.c:571:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_NOTICE,
^
There is no concurrency involved and if it failed the first time,
it will fail the second, third, ... time as well. Simply print that
we will leak the database instance.
libosmocore recently added inline functions to relieve callers from applying
bitmasks and bit shifts to access the transaction id of a GSM 04.08 header.
Apply these functions.
Replace hardcoded protocol discriminator and message type bitmasks with
function calls recently introduced in libosmocore.
Note that the release 98 bitmasks slightly differ from the release 99 bitmasks.
This patch uses the "default" gsm48_hdr_msg_type invocation, thus it depends on
libosmocore whether 98 or 99 bitmasks are used.
In some places, use of the bitmask was erratic. Fix these implicitly by
employing the bitmask functions:
* silent_call.c: silent_call_reroute(): add missing bitmask for MM.
* bsc_msg_filter.c: bsc_msg_filter_initial(): RR vs. MM messages.
* osmo_bsc_filter.c: bsc_find_msc() and bsc_scan_bts_msg(): RR vs. MM
messages.
* bsc_nat_rewrite.c: bsc_nat_rewrite_msg(): SMS vs. CC messages.
* bsc_ussd.c: no bitmask is applicable for the message types used here.
* gb_proxy.c: gbproxy_imsi_acquisition(): missing bit mask for pdisc.
In gprs_gb_parse.c: gprs_gb_parse_dtap(), add a log notice for unexpected
message types.
Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0").
Add VTY command
smpp
local-tcp A.B.C.D <1-65535>
while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the
new command immediately change the SMPP listening address and port.
Add a LOGL_NOTICE log when the SMPP listening address and/or port change.
However, to be useful, this patch has to go somewhat further: refactor the
initialization procedure, because it was impossible to run the VTY commands
without an already established connection.
The SMPP initialization procedure was weird. It would first open a connection
on the default port, and a subsequent VTY port reconfiguration while reading
the config file would try to re-establish a connection on a different port. If
that failed, smpp would switch back to the default port instead of failing the
program launch as the user would expect. If anything else ran on port 2775,
SMPP would thus refuse to launch despite the config file having a different
port: the first bind would always happen on 0.0.0.0:2775. Change that.
In the VTY commands, merely store address and port if no fd is established yet.
Introduce several SMPP initialization stages:
* allocate struct and initialize pointers,
* then read config file without immediately starting to listen,
* and once the main program is ready, start listening.
After that, the VTY command behaves as before: try to re-establish the old
connection if the newly supplied address and port don't work out. I'm not
actually sure why this switch-back behavior is needed, but fair enough.
In detail, replace the function
smpp_smsc_init()
with the various steps
smpp_smsc_alloc_init() -- prepare struct for VTY commands
smpp_smsc_conf() -- set addr an port only, for reading the config file
smpp_smsc_start() -- establish a first connection, for main()
smpp_smsc_restart() -- switch running connection, for telnet VTY
smpp_smsc_stop() -- tear down connection, used by _start() twice
And replace
smpp_openbsc_init()
smpp_openbsc_set_net()
with
smpp_openbsc_alloc_init()
smpp_openbsc_start()
I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol
there is also a bind/unbind process, so instead I chose the names "_start",
"_restart" and "_stop".
The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc
code internally uses talloc anyway and employs the smsc struct as talloc
context, I decided to enforce talloc allocation within smpp_smsc_alloc_init().
Be stricter about osmo_signal_register_handler() return codes.
Add ctrl_vty_init() calls and feed the ctrl_vty_get_bind_addr() return value to
ctrl_interface_setup() in the following programs:
osmo-bsc
osmo-bsc_nat
osmo-nitb
osmo-sgsn
For osmo-sgsn, move the control interface setup invocation below the config
parsing, so that the ctrl_vty_get_bind_addr() can return the configured
address.
Abort upon unknown options and missing option arguments. This came to my
attention while rewiring the -m and -M options: passing -M without argument
would launch nitb with wrong configuration. So, rather exit immediately.
If there are legacy options that should be ignored, they deserve an own 'case:'
in the option switch. There are none that I'm aware of though.
Strictly speaking, the unix domain socket location is not a name but a path.
The MNCC socket is called path, so it is confusing to call the ctrl socket
a 'name'.
Following the 'line vty'/'bind A.B.C.D' command added in libosmocore, use the
configured address to set the telnet bind for the VTY line. It is now possible
to publish the VTY on a specific local interface (including 0.0.0.0 aka "any").
Implement in all of:
osmo-gbproxy
osmo-gtphub
osmo-sgsn
osmo-bsc
osmo-bsc_nat
osmo-bsc_mgcp
osmo-nitb
In some of these main programs, move the telnet initialization below the
configuration parsing.
Historically, this was not a good idea for programs using bsc_init.c (aka
bsc_bootstrap_network()), since they expected a gsm_network struct pointer in
((struct telnet_connection*)vty->priv)->priv, so that telnet had to be either
initialized or replaced by a dummy struct. In the meantime, the gsm_network
struct is not actually looked up in a priv pointer but in the static bsc_vty.c
scope (bsc_gsmnet), so this limitation is mere legacy (even though said legacy
is still there in an "#if 0" chunk).
In the other binaries I have briefly looked at the init sequence dependencies
and found no reason to initialize telnet above the config file parsing. In any
case, I have tested every single one of abovementioned binaries to verify that
they still parse the example config successfully and launch, allowing VTY
connections on the configured address(es). I hope this suffices.
In all of the above, log VTY address and port. LOGL_INFO is disabled by default
in some of the logging scopes, and since it is a single log message right at
program launch, I decided for the slightly more aggressive LOGL_NOTICE.
Remove unused talloc.h from bsc_vty.c.
In bsc_nat.c, use OSMO_CTRL_PORT_BSC_NAT instead of hardcoding port number, and
include ctrl/ports.h for that.
Fix comment typo "COMAMND"
Remove the assert in the llme by avoiding the usage of foreign to local
mappings of TLLIs. The asserts had been hit at 32C3 and the fixes were
created by Jacob and had been tested at the convention.
If an MM context cannot be found based on BBSGP info and a RA UPDATE
REQUEST is received, try to find an MM context with an P-TMSI from
which the TLLI could have been derived. This also checks, whether the
routing area matches.
This is similar to the old behaviour removed by the commits
"sgsn: Only look at TLLIs in sgsn_mm_ctx_by_tlli" and
"sgsn: Remove tlli_foreign2local", except that this will only
be done for RA UPDATE REQUESTs now.
Sponsored-by: On-Waves ehf
Currently the MM context is just overwritten by a call to
sgsn_mm_ctx_by_tlli(msgb_tlli(msg), &old_ra_id) even if it
has already been found by using the BSSGP info. With the changes
made to sgsn_mm_ctx_by_tlli this will never find a MM context if
the routing area has changed. If the routing area has not changed,
the mmctx has already been found if it exists.
This commit splits searching for an MM context (if it hasn't been
found already) from checking, whether a found one can really be
used. The actual search is removed, so that the MS will be forced to
restart the attach procedure, which is less efficient but safe.
Sponsored-by: On-Waves ehf
Currently the code also matches the TLLI against LOCAL and FOREIGN
mappings of the P-TMSI, thus eventually finding MM contexts not
consistent with the TLLI (both tlli and tlli_new differ). On
the other hand, tlli_new is not checked at all.
This commit changes the function to only look at mmctx->tlli,
mmctx->tlli_new, and the routing area.
Sponsored-by: On-Waves ehf
The BSSGP cell identifier is used to get the RA for the TLLI lookup.
The send_0408_message function used in the tests does not set this,
so the RA identifier is always 0-0-0-0.
This commit adds a parameters to pass the RAID and adds missing
dummy RAIDs.
Note that the CI can still not be set and thus is always 0.
Sponsored-by: On-Waves ehf
Currently foreign TLLI are sometimes mapped to local TLLI in the
hope that they will match. This seems to sometimes introduce
inconsisties, possibly leading to a failing assertion in
_bssgp_tx_dl_ud.
This mapping should probably reduce the allocation of additional
LLME during routing area changes.
This commit removes tlli_foreign2local.
Sponsored-by: On-Waves ehf
This patch lets the build script for openbsc find the libsmpp34 installation
with the help of pkg-config instead of assuming the header files are in
/usr/include.
In 'show running-config', timeslot appears as a sub-element of rsl, but it is a
direct child of trx. Fix the timeslot section in vty_out by removing one space
of idention.
Adjust various config examples.
Rationale: it's not relevant for function, but confuses human operators. Fixing
it will save the next hacker some time.
Even if fclose fails the stream is inaccessible and the second fclose
might cause memory violation.
Linux manpage says:
Upon successful completion 0 is returned. Otherwise, EOF is returned
and errno is set to indicate the error. In either case any further
access (including another call to fclose()) to the stream results in
undefined behavior.
Fixes: CID#57958
memcpy has both the source and destination marked as non-null and
we were still passing NULL (with a zero size) to it. While this
makes sense it violates the constraints of the function. Add the
check to see if these values are NULL or not.
+db.c:583:2: runtime error: null pointer passed as argument 2, which is declared to never be null
+ #0 0x40d7f7 in get_equipment_by_subscr (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40d7f7)
+ #1 0x40f6d2 in db_get_subscriber (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40f6d2)
+ #2 0x40bfaa in sms_from_result_v3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40bfaa)
+ #3 0x40c847 in update_db_revision_3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40c847)
+ #4 0x40cbc3 in check_db_revision (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cbc3)
+ #5 0x40cf85 in db_prepare (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cf85)
+ #6 0x406f18 in main /home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test.c:179
+ #7 0x7fd625638a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
+ #8 0x405598 in _start (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x405598)
+
+db.c:590:2: runtime error: null pointer passed as argument 2, which is declared to never be null
+ #0 0x40da23 in get_equipment_by_subscr (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40da23)
+ #1 0x40f6d2 in db_get_subscriber (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40f6d2)
+ #2 0x40bfaa in sms_from_result_v3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40bfaa)
+ #3 0x40c847 in update_db_revision_3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40c847)
+ #4 0x40cbc3 in check_db_revision (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cbc3)
+ #5 0x40cf85 in db_prepare (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cf85)
+ #6 0x406f18 in main /home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test.c:179
+ #7 0x7fd625638a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
+ #8 0x405598 in _start (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x405598)
When a MNCC handler wants to issue the MNCC_BRIDGE primitive
overt the MNCC interface, this was not possible so far via the
MNCC socket. This primitive was so far only available from the
internal MNCC handler, more or less by accident I suppose. The reason
for this is in the way the array of two call references had been passed
into mncc_tx_to_cc().
The debug log prints the received/sent bytes in hex. When this data surpasses
the buffer size available for the log string (4096), the log is truncated
and lacks a newline character. Limit the amount of dumped bytes to 1000.
Sponsored-by: On-Waves ehi
Handle peer restart earlier, so that all the tunnels are deleted by the restart
code path, instead of the first one being deleted due to reused TEI. That
caused confusing logging messages.
Also, when receiving Delete confirmations from the peer that didn't restart,
don't complain about unknown peer, but acknowledge and remove the half
invalidated tunnel. This means that the pending delete entry from the restart
code path is not needed / not used, so don't bother to add pending delete
entries upon peer restart.
The test test_peer_restarted_reusing_tei() hits the situation where a tunnel is
removed because of a reused TEI rather than the restart counter. Adjust the
test to expect the "out-of-band" delete request earlier on, and to still see
the half invalidated tunnel around. Enhance the test by adding the delete
response from the peer that didn't restart, and add a final tunnels_are()
verification.
Sponsored-by: On-Waves ehi
Because the sender is known, one unique TEI per tunnel suffices to map the TEIs
that the peers are sending to gtphub, instead of previously 4 (SGSN<->GGSN
interaction on User and Ctrl plane, where each had an own unique TEI).
Also, previously, a tunnel's endpoints should also have been checked against
each other for TEI reuse, not only against the endpoints of other tunnels. This
simplification fixes that problem for free.
Thus simplify TEI reuse detection and improve VTY show readability and
debugging.
Adjust log and VTY output for tunnels.
Adjust tests accordingly.
Suggested-by: Holger Hans Peter Freyther <holger@moiji-mobile.com>
Sponsored-by: On-Waves ehi
Some logging was multiline to ease human reading of debug output. However,
in the VTY output, these newlines lack a CR motion. Split multiline logs into
separate lines.
Also add one missing space.
Sponsored-by: On-Waves ehi
We now store the pre-printed lchan name in lchan->name to avoid having
to call sprintf every time there is a debug statement somewhere,
particularly as most of those debug statements are going to be inactive
most of the time.
Don't route User message back by sequence number, rather test that a
completely unrelated User message is routed back properly.
Sponsored-by: On-Waves ehi
If an SGSN is behind NAT, we cannot rely on the default ports. Specifically,
if a GGSN sends a message, the forwarding to the SGSN should go to whichever
port the SGSN last sent from (whether sequence nr is known or not).
Add sgsn_use_sender config and VTY command, and store the sender instead
of the GSN Address IE and default port if set.
Sponsored-by: On-Waves ehi
Rather than passing a tunnel pointer as function arguments, keep it in the
gtp_packet_desc struct passed around anyway.
Reason: in the next commit (will add sgsn_use_sender), I need the tunnel to be
passed back out to gtphub_handle_buf(), and besides simplifying existing code,
this also makes passing the tunnel back out trivial.
Sponsored-by: On-Waves ehi
During the peer review session with Holger, these things were deemed fixable.
No need to have a static gtp_packet_desc in gtphub_handle_buf.
No need to memcpy, direct assignment does the job.
Remove obsolete comments.
Fix a stray space.
Sponsored-by: On-Waves ehi
If a GSN indicates that it has reset, tear down each known tunnel for that GSN
individually (don't send the GSNs on the other side a different restart
counter, because they represent more than just this GSN).
Sponsored-by: On-Waves ehi
During resolution of the header TEI, also return the tunnel struct that
resolved the TEI, so the Delete PDP Ctx code does not need to look it up
again.
Upon Delete PDP Ctx Request, remember the IEs and that a request was made.
Upon Delete PDP Ctx Response, find the pending delete and remove the
corresponding tunnel, iff the response indicates success.
Add a context deletion to regression tests, rename the test appropriately.
Sponsored-by: On-Waves ehi
gsn_addr_from_str(): return error upon NULL string.
Add some debug logging.
With an empty config, no bind addresses were set, and the address parser
did not check for a NULL pointer, resulting in a segfault.
Sponsored-by: On-Waves ehi
This is a mostly cosmetic change. Instead of separate buffer handling
functions, reduce some code duplication by using a side_idx just like the
plane_idx, with arrays.
Sponsored-by: On-Waves ehi
This could be done way better, discussion is pending/ongoing. It is indeed
quite unlikely that any user will ever hit this situation, so there is no
strong drive to invest effort in a more comprehensive implementation.
Sponsored-by: On-Waves ehi
There's no need to keep two separate number pools when both can be fed
from the same pool. User and Ctrl plane TEIs can technically overlap without
colliding, but it doesn't hurt if they don't overlap, either.
Sponsored-by: On-Waves ehi
Force passing a restart counter, by adding such arg to gtphub_start() (test
suite is not affected by this).
In gtphub_main.c, add -r,--restart-file <path> and next_restart_count() to
maintain the counter file. While at it, tweak the cmdline help to unify the
formatting (mostly commas and a missing line break).
Send gtphub's own restart counter. So far, the sender's restart counter was
copied through, which would break as soon as more than one GSN would talk to
the same peer with differing restart counters.
Also fix the in-mem restart counter data type (one octet, not two).
Sponsored-by: On-Waves ehi
So far, gtphub worked perfectly by only tracking single TEIs ... for probably
most uses. But a Ctrl plane tunnel may have expired despite a still active
corresponding User plane tunnel. The User plane would continue to work
indefinitely, but if any Ctrl messages followed after more than six hours of
Ctrl silence, they would have been dropped due to an expired TEI mapping.
We want to
- combine expiry of a user TEI with its ctrl TEI. (done in this patch)
- upon delete PDP context, remove both user and ctrl TEI mappings. (future)
- when a peer indicates a restart counter bump, invalidate its tunnels.
(future)
To facilitate these, track tunnels, complete with both SGSN's and GGSN's
address, original and replaced TEIs, all for both user and ctrl plane, in a
single struct. A single expiry entry handles the entire tunnel, instead of
previously four separate expiries for each endpoint identifier.
Add the concept of a "side", being either GGSN or SGSN, to index tunnel
endpoint structs, and so on.
Track the originating side in the gtp_packet_desc.
Add header_tei_rx: set_tei() overwrites header_tei, but the originally received
header TEI is still needed to match a Create PDP Context Response up with its
Request (and for logging).
Adjust the test suite to expect tunnel listing strings instead of TEI mappings,
with a bonus of making it a lot easier to grok, and including the IP addresses.
Add regression test for refreshing tunnel expiry upon use.
Note: the current implementation is as slow as can possibly be, iterating all
the tunnels all the time. Optimizations are kept for a future commit, on
purpose.
BTW, the sequence number mapping/unmapping structures remain unchanged.
Sponsored-by: On-Waves ehi
The expiry queues are already used for resolved GGSN addresses, and will
soon enlist tunnel structs. Hence the naming should be more general.
Sponsored-by: On-Waves ehi
Make 100% sure the user adds expiring_items in chronological order by asserting
that a newly added expiry is >= the last expiry in the queue. Add llist_last()
to facilitate.
Sponsored-by: On-Waves ehi
Instead of passing the current time around in function arguments ('now'),
rather store the current time once upon decoding a GTP packet in the
gtp_packet_desc passed around anyway ('p->timestamp').
Sponsored-by: On-Waves ehi
Some gtphub_bind pointers point to an array of binds, some point directly at
instances. Make the distinction between the two more obvious by adding an
'_arr' suffix to the array ones.
Partly in preparation for upcoming rate counters.
Sponsored-by: On-Waves ehi
Clean up functionality is added for the test suite only, to be able to clean
out all allocations and test against memory leaks.
So far, it was sufficient to expire everything to free a gtphub. In preparation
for the upcoming rate counters, which will need to be freed explicitly, add
gtphub functions to clean up everything.
As added bonus, also close the sockets explicitly -- not really needed upon
program exit, neither by the test suite, but *if* we have a cleanup function,
it should clean up everything properly.
Closing the sockets is however kept separate, for the test suite.
gtphub_start() and gtphub_stop() are for normal use (published in gtphub.h),
and gtphub_init() and gtphub_free() are for the test suite, without sockets.
(gtphub_stop() will probably never be called by anyone, but its existence
completes the picture.)
In gtphub_test.c, have a function to clean up the testing gtphub struct. First,
expire everything by timeout, assert emptiness, then call the cleanup function.
Call from each test in the end.
Sponsored-by: On-Waves ehi
Upon calling gtphub_peer_del(), all addresses and ports should already have
expired (by force). Make sure the code heeds that with a so far missing
assertion.
Sponsored-by: On-Waves ehi
From sgsn_vty.c, copy the cfg_grx_ggsn_cmd to add an ares server to the static
sgsn_instance.
This is sort of preliminary. As described in comments, the sgsn_ares functions
should actually be separated from the static sgsn structure. gtphub keeps such
an sgsn structure just for the sgsn_ares functions.
Sponsored-by: On-Waves ehi
gtphub_ext.c's initial purpose was to wrap a specific function. The file
then turned into everything related to DNS, which fits pretty well. Rename
to gtphub_ares.c.
Tweak the header comment to reflect the new file name.
Sponsored-by: On-Waves ehi
Implement min/max bounds for nr_pool, adjust nr_pool_init() and current tests,
and create unit tests for nr_map wrapping.
Sequence numbers range from 0 to 65535, while TEIs range from 1 to 0xffffffff.
Both cause problems when the nr_pool surpasses the range: seq exit their valid
range, causing unmappings to fail, and a TEI would be mapped as zero (invalid).
Add a comment about TEI wrapping, and lose the comment about random TEIs (not
really important).
Sponsored-by: On-Waves ehi
Use unsigned int for nr_map, just large enough to fit the TEI space.
Adjust log output formats and casts accordingly.
Fixes: TEIs are uint32_t, but the nr_map so far used int. This would cause TEIs
from 0x80000000 on to be handled and printed as a negative value.
Sponsored-by: On-Waves ehi
The del_cb is now also used for ares (GGSN resolution) timeouts, and expiry is
anyway separated from nr_map, so this comment is void.
Sponsored-by: On-Waves ehi
This fixes a bug in the following circumstances:
* BSIC is set to 0 in the config file
* No TSC is explicitly specified at the BST level in the config file
In this case, we ended up using BSIC=0 and TSC=7, as TSC=7 is our
default initialization value.
The TSC of the CCCH/BCCH must always be the BCC, which is the lower 3
bits of the BSIC. Having configuration options for both the BSIC _and_
the TSC at the BTS level therefore makes no sense, as it only adds ways
in which users can configure non-oprational configurations. So we
remove the bts->tsc member, and keep only the ts->tsc members that allow
us to configure a timeslot-specific TSC that's different from the BTS
TSC (= BCC).
s_db.c: In function ‘_insert_ud’:
meas_db.c:65:6: warning: implicit declaration of function ‘rxlev2dbm’ [-Wimplicit-function-declaration]
rxlev2dbm(ud->full.rx_lev)));
^
- an unnecessary if-not-NULL check (1339764);
- a missing nul termination safety net (1339768);
- a typo resulting in the wrong proxy being logged (1339767).
Sponsored-by: On-Waves ehi
gtphub always wants to know the sender, hence make the from_addr pointer
mandatory.
Fixes two coverity complaints (1339766, 1339764).
Sponsored-by: On-Waves ehi
Fit most of the code in 80 chars width. Some instances still leak past 80
characters because of long function names, inline comments or the like, "the
exception proves the rule."
Sponsored-by: On-Waves ehi
For maintenance, it is convenient to have the log level explicit at each
log statement.
Tweak some log levels / message formatting while at it.
Sponsored-by: On-Waves ehi
Allow logging the plane (Ctrl/User) and side (SGSN/GGSN) in functions that only
have a gtphub_bind* to work with, by adding a constant label to each bind.
Sponsored-by: On-Waves ehi
If a GGSN is already known from unmapping, don't invoke a host resolution.
In a live working environment, it wouldn't hurt, because the lookups would
mostly return from the cache. But in a testing environment without a name
server, it barfs on every packet.
Sponsored-by: On-Waves ehi
Initialize llist_heads to empty (2 were missing). Move those for struct gtphub
instances to gtphub_zero() (one moved, one added).
In from_[gs]gsns_read_cb(), use a return type that can actually reflect
negative return values.
resolved_addr.buf: no need to take the address of a byte array var
(cosmetic).
Pass the proper user data address to sgsn_ares_query(), not the address of
the pointer holding the user data address.
Initialize ggsn_lookup->expiry_entry (was missing). Publish the function for that
in gtphub.h so gtphub_ext.c can use it.
Sponsored-by: On-Waves ehi
Looking for a segfault, I added a lot of logging. This may be useful for
live testing ares, leaving it in there for now.
Note: I still want to clean up the logging concerning log levels etc. once
we're out of alpha.
Sponsored-by: On-Waves ehi
Allow a peer sending from an unknown port but a known address, and just
create the port (and unmap the seq nr back to this port later to return
the response to the sender).
Only an SGSN on the Ctrl plane is allowed to make the very first contact
from an unknown address.
Sponsored-by: On-Waves ehi
Split decoding return code GTP_RC_PDU in GTP_RC_PDU_C and GTP_RC_PDU_U.
Don't do IEs in GTP_RC_PDU_U.
Add a unit test for User plane data, expected to fail (nonstandard port case).
In gtphub_test.c, tweak logging so that it is easily visible which test
produced which output. Also add the global resolved_sgsn_addr and ggsn_sender,
symmetrically to resolved_ggsn_add and sgsn_sender.
Sponsored-by: On-Waves ehi
Generalize to make the PDP ctx message definitions and "sending" of messages
from SGSN->gtphub->GGSN and back reusable in future tests.
Publish gsn_addr_from_sockaddr() in gtphub.h for use in gtphub_test.c.
Use an osmo_sockaddr for resolved_ggsn_addr, because one is needed for
comparison in probably every future test.
Add LVL2_ASSERT() to print assertion message and return instead of abort,
so that functions can be called from several tests without losing the
info of which test caused it from which line.
Use globals for struct gtphub and time_t now, to reduce nr of args that need to
be passed around when writing tests. Add a default test setup function.
Sponsored-by: On-Waves ehi
Up to now I used the Echo as a test for sequence nr mappings. But Echos
should be handled differently: they are scoped on the link and an Echo
response should be sent right back to the requester.
Sponsored-by: On-Waves ehi
For the resolving function, change the function signature to return a
gtphub_peer_port. In consequence, publish two functions concerned with
gtphub_peer_port instances for use in test and gtphub_ext.c.
Add GGSN resolution queue, callback and cache. Simple implementation: if an
SGSN asks for a GGSN, it will first get no answer, and I hope it will ask again
once the GGSN is in the cache.
Within gtphub_ext.c, have a dummy sgsn struct, as the sgsn_ares code currently
depends on it (half the functions pass an sgsn instance pointer around, but the
other half use the global one).
In the unit tests, wrap away the ares initialization so that they can work
without a DNS server around. The netcat test breaks because of this, will
remove it.
Using sgsn_ares, implement the gtphub_resolve_ggsn_addr() function, I hope:
untested.
Minor cosmetics just to see if you're paying attention... ;)
Sponsored-by: On-Waves ehi
First steps towards a new GTP hub. The aim is to mux GTP connections, so that
multiple SGSN <--> GGSN links can pass through a single point. Background:
allow having more than one SGSN, possibly in various remote locations.
The recent addition of OAP to GSUP is related to the same background idea.
(This is a collapsed patch of various changes that do not make sense to review
in chronological order anymore, since a lot of it has thorougly transmorphed
after it was first committed.)
Sponsored-by: On-Waves ehf
Extend the ul/dl counting to count the usual messages on the
Gb interface. Add counters for the attach, routing area update,
pdp context activation and deactivation procedures. Update the
test result with the new counters.
RPM post-build-checks found some issue and marks these as error:
[ 38s] I: Program returns random data in a function
[ 38s] E: openbsc no-return-in-nonvoid-function meas_vis.c:118
Holger reports that the bitmap that accounts for available Osmux circuit
IDs is limited to 128, when the maximum number of circuit IDs are
determined by the uint8_t field in the header (ie. 256 circuits).
[hfreyther: Update the testcase now that we have more ids to allocate]
Trigger an OAP registration upon IPA connect. Feed incoming OAP messages to
oap_handle() and send replies returned by it.
Add oap_config to sgsn_config (todo: vty).
Sponsored-by: On-Waves ehf
[hfreyther: Fix coding style]
Add new kitchen sink openbsc/utils.h and libcommon/utils.c to make three so far
static functions public (so I can use them in the upcoming OAP code).
A place to put them could have been the gprs_utils.h, but all general functions
in there have a gprs_ prefix, and todo markings to move them away. All other
libcommon headers are too specific, so I opened up this kitchen sink header.
Replace the implementation of encode_big_endian() with a call to
osmo_store64be_ext(). See comments.
Apply the change in Makefiles and C files.
This change has some implications for the test case. It manipulated
bss_ptmsi_state and sgsn_tlli_state variables to make the output of
rand_r() and thus the TLLI/TMSI used predictable.
This possibility is gone when using RAND_bytes() so instead it is
overridden by a function that returns a deterministic sequence of values
(0x00dead00, 0x00dead01, ...). The test cases are adapted to expect
these values instead of the pseudo random values before.
The gbproxy_test stdout file changes as well, but only where the
TLLI/TMSI is displayed (in the hex dumps as well as the TLLI cache
entries). All other output is the same.
This (currently empty) function is meant to contain code that cleans
up the left-overs of the test functions. This is needed by the next
commit to reset the RAND_bytes sequence.
Currently just the number of intercepted downlink messages is counted
and eventually checked. The contents of the messages is lost. The
PTMSI contained in ATTACH/RAU Accept messages is just 'guessed' by
resetting the random number generator after reference PTMSIs have
been generated. While this works with rand_r, RAND_bytes cannot be
forced to recreate a certain number sequence this way (unless the
backend is replaced).
This commit changes that behaviour so that the last received msgb is
kept and decoded. The PTMSI that has been assigned by the SGSN is
then taken in the affected test cases and used instead of a 'guessed'
one. This is similar to how a real MS would react to the Accept
message.
Sponsored-by: On-Waves ehf
This (currently empty) function is meant to contain code that cleans
up the left-overs of the test functions. This will be needed by the
next commit that will store the last received msgb for later inspection.
Sponsored-by: On-Waves ehf
This API is a bit unfortunate as the caller will also
access the endpoint directly. E.g. like this:
output = bsc_mgcp_rewrite(...,
mgcp_net_src_addr(endp),
endp->net_end.local_port, -1,
In terms of "terminology" the "net" was meant to be bad
internet and the "bts" is the local and trusted network
segment. With this terminology the "bts" would be the
call-agent/MGW and "net" where the BSCs will send data
to but that is not the case and terminology actuallys
refers to:
* net: The addresses exposed to the entity that
made the MGCP call
* bts: The system where we get our data for the
local audio flow.
Fix the method but leave the API as it is. Use the net_end
in the net_src method and the bts_end in the bts_src method.
We put a signed integer into this string but did not account
for the newline and for the terminating NUL of the string. Add
the newline to the string and add one for NUL. Spotted while
accidently having a CID of 255.
There appears to be a leak of CIDs:
<000b> mgcp_osmux.c:544 All Osmux circuits are in use!
There are paths that a CID had been requested and never released
of the NAT. Remember the allocated CID inside the endpoint so it
can always be released. It is using a new variable as the behavior
for the NAT and MGCP MGW is different.
The allocated_cid must be signed so that we can assign outside
of the 0-255 range of it.
Fixes: OW#1493
Extend the osmux only setting from the MGCP MGW to the NAT. This
is applied when an endpoint is allocated and/or when the allocation
is confirmed by the remote system.
Not tested. The impact should only be when the new option is
being used.
Fixes: OW#1492
Some systems only want to use Osmux. In case only Osmux
should be used fail if it has not be offered/acked.
Client:
Verified On, Off and Only with X-Osmux: 3 and without this field.
<000b> mgcp_protocol.c:823 Osmux only and no osmux offered on 0x14
<000b> mgcp_protocol.c:884 Resource error on 0x14
NAT:
Not tested and implemented
Fixes: OW#1492
sizeof(uint8_t) == 1 and there is no need to create an array
with 16 bytes and then only use the first two of them. This
means the CID range is from 0 to 127 and we should be able
to extend this to 256 by changing the array size to 32. Update
the testcase now that we can have more than 16 calls with Osmux.
* Test that one can get an id
* That they are assigned predicatble right now
* That returning them will make the number of used ones go down
* That allocating more will fail
The log message does not help and says where the data is
being sent to. This is because we have both a RTP and RTCP
port. Remember if we failed with RTCP or RTP and improve
the log message.
I was searching a case where the port was bound to a local
address (e.g. 127.0.0.1) and tried to send the data to a
public one (e.g. 8.8.8.8).
The signature of mr_config and the BSC implementation didn't
match and the compiler was warning about it:
osmo_bsc_api.c:530:2: warning: initialization from incompatible pointer type
.mr_config = bsc_mr_config,
^
osmo_bsc_api.c:530:2: warning: (near initialization for ‘bsc_handler.mr_config’)
Change the mr_config again and provide an implementation
that will set the ms and bts data structure. It would be
better to put the size outside of the IE but I am not going
to change it right now. It would also be nice to either move
the AMR setting into the "nitb" structure or have the msc
data be used _after_ the bts settings. This needs to be
cleaned up in the next step.
Manually verified by placing a MO call and checking that
both the channel mode modify and the mode modify request
contain the multi rate config with the rate mr config
(length two bytes, version 1, icmi==1, no start mode being
set).
This way a lot of if/else can just be killed by the caller deciding
which of the two instances to use.
I have copied both branches to new files, replace bts for ms in one
of them and ran diff on it. There is no difference.
Merge two copies into a local static helper function. The format
of the message will change and then it is easier to modify it in
one place than in two.
Sadly the original patch was merged before this clean-up so do
the clean-up as second step.
Conflicts:
openbsc/src/libbsc/abis_rsl.c
openbsc/src/libbsc/gsm_04_08_utils.c
The pre-release didn't add a newline after the apn and the patching
pattern command. Create a quirk command that combines both. The
pre-release didn't include a differentation between routing and
patching.
The TLLI handling has a different and more generic name now. Make
it handle the old one that is actively used.
Add a file with the broken format and the standard config file
test should pick it up.
* Implement the rtp-bridge mode for MNCC
* Audio doesn't flow through the NITB at all
* It only works with IPv4 BTSes right now
* We need to select an audio codec way too early
* No tandem free operation
* Early assignment always equals TCH/F
In case of the RTP bridge mode we need to select the codec
ourselves. Rely on the same (incomplete) codec selection that
can be done using the mncc-int configuration node. This might
gain bearer capabilities support.
In case of a SDCCH a TCH/F will be attempted to be assigned.
This is an open issue for both modes and there should be a
preference for full or half-rate channels somewhere.
Implement sending MDCX on the newly allocated channel and send
the data to the same destination as the currently connected one.
This way the receiver can implement RTP RFC Appendix A.1 and
deal with the new source.
For the LCR rtp-bridge audio should directly flow to the
remote system. In contrast to the original patch audio
will now flow directly from the BTS to the remote system.
This assumes that BTS and the remote system are in the
same network segment and can directly communicate.
There are various limitations in the first iteration of
the implementation:
We could (and in the future) should delay the assignment
but currently we are forced to pick the channel and move
it to the audio state. In case we are located on a SDCCH
we always need to change but if we are on a TCH we could
send the ipa.CRCX and change the audio state a lot later.
The net effect is that the audio codec selection needs to
be done in the NITB code and not in the system connected
to it.
This only works with ip based systems. For E1 systems one
could still use the RTP socket or even try to move this
out of the process.
There is no code for handover handling and it relies on
the remote system dealing with the SSRC change of the
system.
This adds the protocol definition for the RTP bridge extension
of Andreas Eversberg and bumps the protocol version.
I added the missing mncc mappings from value to string.
[ 5cf8fb10ea3addcae74d37f4dbf1c1be664df53e protocol extension
5dac90de38990b188f499c602bf18a4f232070e8 payload extension]
Mike's patch included clean-ups I want to apply separately and
change them a bit. If we return from an else we don't need to
put the else.
* Try the E1 trunk first
* Then try a local virtual trunk
* Fail if none of the above returned
Remove the host portion of the endpoint Id. This requires less
configuration and we are probably fine to trust that MGCP only
received messages designated for it.
When using multiple interfaces on a system one can now configure
which will be served for the BTS ports and which will be served
for the network. The direct usage of source_addr is now only to
initialize the MGCP receiving port itself.
Make it possible to bind the call-agent to a specific IP address
and the network and bts end to different ip addresses. Begin by
clarifying which source ip address we want to have.
Use the existing ulaw encode/decode to support PCMU as well.
The MERA VoIP switch has some severe issues with the GSM codec
and it appears easier to enable transcoding for it.
The mera switch doesn't appear to cope with codec change
between a SIP 180 trying and the 200 ok connection result.
Inserting the codec is touching too many places. Ideally we
should have the transcoding function as pointer in the struct
as well but the arguments differ.. so it is not a direct way
forward.
Iridium is a satellite network which operates a GPRS-like that allows you to
get speeds up to 128kbit/s. However, it takes from 5 to 6 secs to get the
bandwidth allocated, so the conversation is garbled during the time.
This patch uses the new dummy padding support in libosmo-netif that is
controlled through the osmux osmux_xfrm_input_open_circuit().
This includes a new VTY option for osmux.
I guess none of our users knows what a mi_type=0x02 is, but most would
know what an IMSI or a TMSI is. So let's use the newly introduced
gsm48_mi_type_name() function to fix this.
For some odd reasons the XID is not a separate SAPI but has been kludged into
the GMM SAPI. This means we ahve to be careful not to dispatch XID frames into
GMM. We do this by introducing an explicit check for UI frames before the
dispatch to GMM.
The previous code already was doing "the right thing" but printed occasional
messages like "gprs_gmm.c:2082 Unknown GSM 04.08 discriminator 0x01: 01 00 0e
00 32 11 03 16 01 90 63 28 0b". Those should be gone after this patch.
Traffic cannot sent to BTS, if there is (currently) no logical channel
associated with the transaction.
This happens, if TCH traffic is received from upper layer, but there is
no lchan available before completing immediate assignment, handover or
assignment process.
[hfreyther: The code has not been moved to tch_frame_down
but the issue looks similiar]
The NAT sends an incomplete SDP file for the purpose of informing
the BSC about the remote IP/PORT early. The case of an incomplete
SDP file was not considered. Check if there is a codec and if not
skip it.
TODO: We need to have a better end-point life cycle test.
Move forward while preserving the legacy handling. Beging to
extract SDP rtpmap information and select codecs atfer this.
It is a foundation we can now build further and better check
ons.
We have a lot of legacy that I am afraid to break. We have
everything in place to make a good codec selection (e.g. if
we can avoid transcoding, pick the one with best quality or
the lowest speed). Right now I have a specific case where
from all options I want to pick GSM. Guard the codec compat
check behind the disallow transcoding option to make sure
to not break legacy application.
First collect everything we know and the mapping. E.g. a genuis
could remap "3" to "AMR" so we only know the codecs once we are
at the end of the SDP file. Once we have collected everything we
can select the audio codecs. The current code is compatible in
that two codecs will be selected regardless of if they make any
sense or not.
mgcp_set_audio_info could re-use some of our codec information
but then the caller in the MGCP protocol needs to be updated as
well as we use the "I: GSM" information to derive the codec from
there.
The SDP file handling will get more complicated in terms of
codec selection so let's remove it from the protocol handling
before we start blowing it up in size.
The parsing code assumed that there will be a single payload
type and this assumption is clearly wrong. Forward all of the
payload types. The code is still only extracting the first
type from the list. The variable name has been renamed to
reflect this.
Using the talloc leak report we see that there are some msgb's
that are allocated for SMS but we don't have transactions or
SMS around. We need to improve the name of the messages to
uniquely dscribe where they are from but the obvious leak does
occur in this routine.
The no available transaction id is most likely the case where
we leak memory. This should not occur and shows another issue
with the smsqueue/smpp handling. It doesn't explain the subscr
reference count issue either.
Extract of the leak report:
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x2517dc0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x24b56e0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x23e7930
At the rhizomatica sites some unauthorized subscribers have a
last used from long time ago but a bigger reference count. This
means that we have an unbalanced subscr_get/subscr_put that we
need to investigate. These two fixes are genuine fixes but are
unlikely to fix the issue I am not understanding yet.
In case the subscriber is currently busy we would omit the
subscr_put. This seems to be very hard to hit as the subscr
need to be active and at the same time be selected for the
purge operation.
Various paging clean-ups. I couldn't re-produce the assert that
was hit by Rhizomatica in the subscriber code. Let's clean things
up a bit to avoid some of the potential issues this code had.
Always stop paging regardless of where the subscriber is at the
time of the cancellation.
As the comment says we should not rely that the paging
occurs on the current LAC. We might page at more BTS.
Walk all the BTS to stop paging. No callbacks will be
issued by this stop operation.
In case we can't page on a BTS then stop it everywhere. The
callers of paging_request assume that this is kind of an
atomic operation and we should help with that.
Coordinate with the normal subscriber channel requests instead
of going to page ourselves. This might lead to getting a channel
that is of a different type though.
vty_interface_layer3.c:584:4: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=]
sizeof(subscr->extension)-1, VTY_NEWLINE);
When two phones use the same TMSI and no A3A8 is possible
we could end in a hard to detect issue. Assume that the IMSI
will not clash and we have issues for foreign simcards.
In case foreign simcards are used we can not do authentication
and ciphering. In case a TMSI is re-used too early and we do
page using TMSI we can't know which of the two MS is responding
to us. We could change the "secure channel" routine to ask for
the IMSI and only then stop the paging.
As we don't have ciphering there is not much use in using the
TMSI. Add a mode "no assign-tmsi" that will not assign the TMSI
during LU. Now CM Service Request and Paging Response will
work using the IMSI. There can't be a clash with that.
[ciaby fixed the vty write to use the right name]
When we can't find the TMSI then the subscriber is not in our
VLR. We have not consulted with the HLR and it is better to not
use such a severe error code.
in_address is not 'accidently' included by FreeBSD when we include
the osmocom/core/select.h header file. We need to include a bit
more.
In file included from mgcp_protocol.c:38:
../../include/openbsc/mgcp_internal.h:134:21: error: field has incomplete type 'struct sockaddr_in'
struct sockaddr_in forward;
List needs to be executed from within the right configuration
node to see if it is available or not. list on the toplevel
will uncoditionally show "smpp" as part of the logging config.
Struct osmo_msc_data contains int core_ncc, which is actually the
MNC part of the PLMN, not to be confused with the Network Colour
Code.
The following patch renames this field for clarity and consistency
with the standards.
If we have tried SMPP first and it was not routable, and then
tried the local delivery there is no point in trying SMPP with
the same parameters again. Leave early and return unknown sub
to the caller.
default-route would only be looked at after there has been
no subscriber in the local database. Depending on the setup
this is not what one wants. This has been discussed at the
OsmoDevCon and there have been hacks in some branches. Let's
introduce a VTY command to select if SMPP should be consulted
first and then fallback to the current behavior.
Even if it is using BSC/NITB types let's put it in the header
file than just declaring it at a place that could bitrot in a
way that doesn't lead a warning.
The "default-route" for SMPP will be used after a local
subscriber look-up. Sometimes we want to route everything
to SMPP. Make this possible by changing this routine.
We just link to libosmovty and if it requires crypt internally it
needs to link to that (and not us). This looks like a left-over
from when we moved the VTY code out of OpenBSC
We don't need to consume all the entropy of the kernel but can
use libcrypto (OpenSSL) to generate random data. It is not clear
if we need to call RAND_load_file but I think we can assume that
our Unices have a /dev/urandom.
This takes less CPU time, provides good enough entropy (in theory)
and leaves some in the kernel entropy pool.
We are using the token to find the right bsc_config and
then we can use the last_rand of the bsc_connection to
calculate the expected result and try to compare it with
a time constant(???) memcmp.
Check if the NAT has sent 16 bytes of RAND and if a key
has been configured in the system and then generate a
result using milenage. The milenage res will be sent and
noth the four byte GSM SRES derivation.
Generate 16 byte of random data to be used for A3A8 by
the BSC in the response. We can't know which BSC it is
at this point and I don't want to send another message
once the token has been received so always send the data
with an undefined code. The old BSCs don't parse the
message and will happily ignore the RAND.
/dev/urandom can give short reads on Linux so loop
around it until the bytes have been read from the kernel.
Instead of doing open/read/close all the time, open the
FD in the beginning and keep it open. To scare me even
more I have seen /dev/urandom actually providing a short
read and then blocking but it seems to be the best way
to get the random byes we need for authentication.
So one should/could run the cheap random generator on
the system (e.g. haveged) or deal with the NAT process
to block.
Unfortunately the basic structure of the response is broken.
There is a two byte length followed by data. The concept of
a 'tag' happens to be the first byte of the data.
This means we want to write strlen of the token, then we
want to write the NUL and then we need to account for the
tag in front.
Introduce a flag if the new or old format should be used.
This will allow to have new BSCs talk to old NATs without
an additional change. In the long run we can clean that up.
In case the token was not correct, just close the connection.
It is not clear that forcing a new TCP connection is going to
give us any extra security here. But with the upcoming auth
handling it does make sense to have both case look similar.
In the libfilter source code, which is built regardless of --enable-nat,
headers from libosmo-sccp were used, thus causing a build failure (see
below) when building without --enable-nat, and libosmo-sccp not being
installed (or being installed in a prefix not otherwise included in the
build).
The build fails like this:
In file included from ../../../src/libfilter/bsc_msg_filter.c:27:0:
../../../include/openbsc/bsc_nat_sccp.h:27:37: fatal error: osmocom/sccp/sccp_types.h: No such file or directory
As the includes seem not to be actually needed, this change fixes the
issue by just omitting them.
Running "make distcheck" failed trying to generate ".version" into the
read-only unpacked source directory. Actually shipping ".version" in the
tarball fixes that.
There was no context for the SCCP CREF message and this means
that the msc_con was a plain NULL pointer that was dereferenced
and the application would crash.
Use the new API to pass the incoming MSC Connection which sould
be used for the SCCP CREF message as context. The code has not
been fed with an actual SCCP CR message.
The loop was used to print all returned addresses but we can
simply pick the first one. This is fixing a coverity issue that
the loop will be executed eaxactly once (and that was on
purpose).
Simplify the code and just take the first element (which might
be NULL).
Fixes: Coverity CID#1302852
We can't do much in case the fd is failing to be registered.
There should be a timeout that is catching this and it might
be able to repair it self.
Fixes: Coverity CID#1302854
The code to do that doesn't belong to the control interface, so
abstract it out to a separate function gsm_bts_set_system_infos().
[hfreyther: Fix the coding style...]
In case the query for "hostname" will fail c-ares will append the
domain name of /etc/resolv.conf and query again. We don't want that
so claim we provide a list of domain names and then don't provide
any.
I didn't intend to have pushed the c-ares code to master yet.
For real networks we need to check if the requested APN string
is allowed and then resolve the GGSN address through DNS. There
are countries with two or three digit MNCs and one could either
try to keep a list of countries that have two/three digits or
just try both of them. I have opted for the later for the ease
of the implementation.
C-Ares doesn't allow to cancel a request so we will need to
have the MMCTX and the Lookup have different lifetimes. We simply
set ->mmctx to NULL in case the MMCTX dies more early.
The selected and verified apn_str will be copied into the out
parameter. In case no static APN/GGSN config is present and the
dynamic mode is enabled a request will be made.
c-ares is an asynchronous DNS resolver and we need it to
resolve the GGSN address. This is integrating the library
into our infrastructure. We will create and maintain a list
of registered FDs (c-ares is currently only using one of
them) and (re-)schedule the timer after events occurred.
When needing to do an asynchronous DNS query we need
to keep the TLV data around. So create a wrapper that
takes a copy of it and frees it after the call. I can
change the code to add an out parameter to decide if
the msgb should be freed or not.
Pick network failure in case the msgb could not be
cloned in the hope the MS will retry then.
A real SGSN will dynamically resolve the APN name into the
GGSN IP Address. This means that after we have collected all
information we need to start to resolve the GGSN and then
can continue.
This is a left-over from the initial system where no PDP
was provided by the system. For now if there is a subscr
attached and no PDP context provisioned. He is not allowed
to have a data connection.
Update the testcase to create the pdp list entry more
early with a wildcard and then change it to a specific
match.
Include the hlr-Number of the subscriber in the CDR. This is useful
for debugging and understanding which equipment was used during the
test. In contrast to the MSISDN the '+' is emitted as the number
must be in international format already.
Copy the hlr-Number into the sgsn_data and use it during
the purgeMS. There is no unit test that looks at the data
we send so I manually verified this by looking at the output.
Below is the output of the test that purges the subscriber.
<000f> gprs_subscriber.c:170 SUBSCR(123456789012345) Sending GSUP, will send: 0c 01 08 21 43 65 87 09 21 43 f5 09 07 91 83 61 26 31 23 f3
We have verified/selected the APN. Either based on the subscriber
data, a global APN match. But at least this SGSN has looked at
what the MS has asked for and then selected a matching GGSN.
Clear LAC/RAC with pre-defined value in the RAI.
3GPP 29.060 v7.17.0 section 7.3.1 page 23:
"The SGSN may include the Routeing Area Identity (RAI) of the
SGSN where the MS is registered. The MCC and MNC components shall
be populated with the MCC and MNC, respectively, of the SGSN
where the MS is registered. The LAC and RAC components shall be
populated by the SGSN with the value of 'FFFE' and 'FF',
respectively.”
Most SGSNs pass the IMEI(SV). We currently only enquire about
the IMEI and then pad the 'SV' with 1111b (thanks to the encoding
routine). Sadly it insists on always writing the length which
means we have to memmove the data around by a single octet.
Manually verified using the pcu-emu and looking at the trace
using wireshark.
Give the GGSN another opportunity to determine which tarif
to apply for the SGSN/subscriber. This code assumes tha the
RAN is a GERAN system but the assumption has been made in
other places as well.
For PDP context creation we always want to include the RAI
for the current mmctx. This might help commercial GGSNs to
determine which charging to apply.
The charging_id is provided by the GGSN. Copy it into the CDR
part of the data structure so it will remain present until after
the pdp context has been deleted.
Make it possible to set a filename to use for the CDR. By
default no CDR will be generated. Forbid to set the interval
of 0 seconds as this will cause a lot of work. Add a very
basic VTY test.
This is consuming the new signals and allows to install several
different CDR/observing/event/audit modules in the future. For
getting the bytes in/out the code would have had to undo what the
rate counter is doing and at the same time adding a "total" to
the ratecounter didn't look like a good idea, the same went for
making it a plain counter.
Begin writing the values one by one and open/closing a new FILE
for every log messages. This is not efficient but easily deals
with external truncation/rotation of the file (no fstat for and
checking the links and size). As usual we will wait and see if
this is an issue.
Add some new members to our PDP context structure to see what it
is about.
In case there is a subscr attached to the MM context and there
is an encoded MSISDN we will attempt to decode it and in case
of an international number prepend a '+'. Assume that the array
size of gsm_mmcc_called->number is as big as ctx->msisdn for the
strncpy.
When communicating with a GGSN that is not the OpenGGSN
the PDP context activation does fail. This is because on
the activation of the first PDP context we need to supply
a MSISDN. Extend the protocol, parse the MSISDN and then
send it to the GGSN. The second item is that we have only
forwarded the requested QoS of the subscriber. In most
cases this is 0x0, 0x0, ... which means one requests a
rate 0 byte/sec which the GGSN will not allow. Make it
possible to receive, store and use the subscribed QoS of
the Subscriber.
If QoS is only three bytes it does not include the allocation/
retention policy. Otherwise it does. Copy it depending on that.
We should have a macro for the clamping to reduce code duplication.
The insanity does come from the MAP data and this seems to be
the easiest in terms of complexity. It is an array of bytes that
is transported from MAPProxy to the SGSN and then simply forwarded.
The case of more than three bytes is neither unit nor manually
tested so far.
sgsn_create_pdp_ctx should use the subscribed QoS. When selecting
the PDP context we inject the QoS to be used into the TLV structure
and use it during the request. Assume a "qos-Subscribed" structure
only with three bytes and prepend the Allocation/Retention policy
to the request.
The MSISDN should be present for "security" reasons in the first
activation of a PDP context. Take the encoded MSISDN, store it for
future use and then put it into the PDP activation request.
The MM Context contains a field for a decoded MSISDN already. As
we need to forward the data to the GGSN I want to avoid having to
store TON and NPI in another place. Simply store the data in the
encoded form.
QoS is a mess. In MAP there is qos-Subscribed which is then extended
using ext-QoS-Subscribed, ext2-QoS-Subscribed, ext3-QoS-Subscribed
and maybe even ext4-QoS-Subscribed by now. The MAP ASN1 files defined
how these need to be "linearized". Instead of copying this I have
decided to include the two semantics with/without the Allocation/Retention
policy using the size of the data.
It is a bit arbitary to decide which one is the global
and which one is the local one. We might change it around.
I don't think we want to introduce it based on BTS.
For the BSC we will have the gsm48_hdr and don't need to
find data within SCCP. For legacy reasons we need to
initialize con_type, imsi, reject causes early on and
need to do the same in the filter method.
This means we need to require a talloc context and
simply operate on the list. I had considered creating
a structure to hold the list head but I didn't find
any other members so omitted it for now.
Move the filter methods to the filter module. This is
still only usable for the NAT and the _dt/_cr filter
routines need to move back to the bsc_nat in the long
run.
For customer requirements we want to be able to do
filtering on the BSC as well. The same messages need
to be scanned and the same access-lists will be looked
at. In the future we might even split traffic based
on the IMSI. Begin with moving the code to a new top
level directory and then renaming and removing the
nat dependency.
ENDPOINT_NUMBER takes the difference of two pointers. On 64bit
builds the difference is a long and the compiler then complains
about the usage of abs. We will never have thousands of endpoints
so silence the warning by casting the ENDPOINT_NUMBER to int.
mgcp_vty.c:1381:34: warning: absolute value function 'abs' given an argument of type 'long' but has parameter of
type 'int' which may cause truncation of value [-Wabsolute-value]
rtp_port = rtp_calculate_port(ENDPOINT_NUMBER(endp),
^
../../include/openbsc/mgcp_internal.h:206:31: note: expanded from macro 'ENDPOINT_NUMBER'
#define ENDPOINT_NUMBER(endp) abs(endp - endp->tcfg->endpoints)
^
mgcp_vty.c:1381:34: note: use function 'labs' instead
The idea of "subscriber_get_channel" was that different
requests would be coordinated. At the same time we have
seen that the "queue" can get stuck at both 31C3 and the
rhizomatica installations.
Voice calls and SMS do not need coordination. We should
be able to send SMS on a voice channel and switch the MS
from a SDCCH to a TCH in case we establish a voice call.
The SMS code itself needs to coordinate to obey the limit
of one SMS per direction but this should be enforced in
the sms layer and not on the subscriber.
Modify the code to have a simple paging coordination. The
subscriber code will schedule the paging and register who
would like to know about success/failure.
This allowed to greatly simplify the paging response
handling for the transaction code (and in fact we could
move the transaction list into the subscriber structure
now). The code gained to support to cancel the notification
of a request (but not the paging itself yet).
TODO: Cancel paging request in case no one cares about it
anymore.
In case the default TCH/F codec is "EFR" and we do an early
assignment from SDCCH to a TCH we would assign the TCH/H
codec. This is because the lchan_type will be neither a
TCH/H nor a TCH/F.
At the same time the _gsm48_lchan_modify code to check for
half vs. full-rate is the other way around. Align both.
It is full-rate if it is not a TCH_H. This will have some
other complications down the way (early assignment on
cells with only TCH/H). So the mode should not depend on
the _current_ channel but the kind of channel we want.
The debian shlibs:depends macro will add the depends
according to the needed libraries for us. We only need
this for the sqlite3 plugin of libdbi-drivers as there
is no direct linkage.
In test_rtp_seq_state an assignment is accidently done within an
assertion.
This commit changes that into a comparison as it was intended.
Fixes: Coverity CID 1295457, 1295458
Sponsored-by: On-Waves ehf
Currently the src_codec const variable is set to &src_end->codec
before src_end is checked against NULL. Since the assigment is just
an address operation and the memory where it points to is only
accessed after the NULL check, this does not harm technically.
Nevertheless this is potential source for errors if that code is
changed.
This commit moves the definition below the NULL check. This does not
comply with the coding style, but it cannot be split into definition
and a later assignment due to the const qualifier.
Sponsored-by: On-Waves ehf
We might have compiled transcoding into the MGW but
we don't want to enable it for a given user. Add a new
switch that should allow that.
I had manually tested the allow-transcoding/no allow
VTY interface for the primary interface and a new trunk
using show running-config.
It is unlikely that GSM, gsm and GsM refer to different codecs.
The mera mvts does send the audio codecs in lower case even if
RFC 3551 has them in upper case (but copy and paste is sometimes
too hard).
Currently the handling of the buffers is not done consistently. Some
code assumes that the whole buffer may be used to store the string
while at other places, the last buffer byte is left untouched in the
assumption that it contains a terminating NUL-character. The latter
is the correct behaviour.
This commit changes to code to not touch the last byte in the buffers
and to rely on the last byte being NUL. So the maximum IMSI/IMEI
length is GSM_IMSI_LENGTH-1/GSM_IMEI_LENGTH-1.
For information: We assume that we allocate the structure with
talloc_zero. This means we have NULed the entire imsi array and then
only write sizeof - 1 characters to it. So the last byte remains NUL.
Fixes: Coverity CID 1206568, 1206567
Sponsored-by: On-Waves ehf
Currently some VTY command do neither check the length of the source
string before calling strncpy nor ensure NUL-termination afterwards.
This can to destination string buffers whose contents are not
NUL-teminated.
This commit adds checks and corresponding warnings to the VTY
commands 'subscriber TYPE ID name .NAME" and "subscriber TYPE ID
extension EXTENSION".
Fixes: Coverity CID 1206570, 1206569
Sponsored-by: On-Waves ehf
When handling an incoming GSUP cancellation request, the cancel_type
if effectively ignored, such that is always handled as
GPRS_GSUP_CANCEL_TYPE_UPDATE and never as WITHDRAW.
This commit fixes the expression used to set the variable
is_update_procedure.
Fixes: Coverity CID 1267739
Sponsored-by: On-Waves ehf
Currently the inner loop in show_bsc_mgcp iterates of the timeslot
interval [0, 31]. Timeslot 0 is not valid, which causes
mgcp_timeslot_to_endpoint to generate a corresponding warning and to
return an invalid endp value. That value causes an out-of-bound
read access, possibly hitting unallocated memory.
This patch fixes the loop range by starting with timeslot 1.
Note that this does not prevent mgcp_timeslot_to_endpoint from
returning an invalid endpoint index when called with arguments not
within its domain.
Addresses:
<000b> ../../include/openbsc/mgcp.h:250 Timeslot should not be 0
[...]
vty=0xb4203db0, argc=1, argv=0xbfffebb0) at bsc_nat_vty.c:256
max = 1
con = 0xb4a004f0
i = 0
j = 0
[...]
==15700== ERROR: AddressSanitizer: heap-use-after-free on address
0xb520be4f at pc 0x8062a42 bp 0xbfffeb18 sp 0xbfffeb0c
Sponsored-by: On-Waves ehf
I omitted the check as this was already done by the verify
function for this command. Please Coverity and do the check
again even if it is not necessary. I begin to doubt the
usage of a "dedicated" verify method as well.
Silences: Coverity CID 1293150
On DT messages we directly write into the tracked SCCP
connection. This means "imsi" will always be NULL at
this check. Change the code to use con->imsi
Fixes: Coverity CID 1293151
We want to have a program add entries to the allow list
this can be done using:
$ bsc_control.py -d localhost -p 4250 -s net.0.add.allow.access-list.NAME "^IMSI$"
bsc_stat_reject is treating -1 as parsing failure but for the
global barring. Change it to another return value so it is
not counted as parsing failure.
We had issues with odd behavior on the nanoBTS which lead
to the introduction of the "broken" state. On busy multi
BTS cells (e.g. rhizomatica) with wifi backhaul the timeout
we set to wait for a RF Channe Release ACK is sometimes too
little and channels are marked broken that look to be okay
(besides the still to be determined delay).
In case of a sysmoBTS we now know that we can change the
state of a broken channel back to normal in case we do
receive the right response.
Manually verified using the Smalltalk BTS code
PackageLoader fileInPackage: 'FakeBTS'
bts := FakeBTS.BTS new.
bts btsId: '1903/0/0'.
bts connect: 'localhost'.
bts waitForBTSReady.
test := FakeBTS.OpenBSCTest new.
test bts: bts.
test requireAnyChannel
... wait for NITB output
<0004> abis_rsl.c:223 (bts=0,trx=0,ts=0,ss=0) Timeout during deactivation! Marked as broken.
... process pending messages
stdin next
<0004> abis_rsl.c:735 (bts=0,trx=0,ts=0,ss=0) CHAN REL ACK for broken channel. Releasing it.
So the channel went from broken to unallocated.
Change the paging strategy based on on if a LAC override
is in place or not. In case we had changed the LAC we need
to page on all the BTS. Change the "grace" handling to
iterate over the BTS and filter out all non matching ones
LAC in case no LAC handling is active.
Manually verified all four cases with a single BTS:
* No LAC handling and grace period
* LAC handling and grace period
* No LAC handling and not lock
* LAC handling and lock.
Related: SYS#1398
For MT we can't page per lac as we don't know which BTS was
the original one. Split the grace period and normal mode into
two methods so we can bloat both of them later.
We need to use different LAC/CI towards the core network.
It is a bit problematic as LAC/CI is a per BTS attribute
so this feature only works if a BSC manages everything in
the same LAC.
Related: SYS#1398
The write_queue is designed to have a maximum amount of pending
messages and will refuse to take new messages when it has been
reached. The caller can decide if it wants to flush the queue
and add the message again, create a log. But in all cases the
ownership of the msgb has not been transferred. Fix the potential
memory leak in the failure situation.
When reading from RTP socket, the first read() may fail right after
connecting to remote socket. Subsequent read() will work as it should.
If the remote socket does not open fast enough, the transmitted RTP
payload can cause an ICMP (connection refused) packet reply. This causes
the read to fail with errno=111. In all other error cases, the errno is
logged at debug level. In all error cases, reading is not disabled.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Fix typo, stop reading in all cases but ECONNREFUSED]
If a bad TRAU frame is received, it is forwarded to MNCC application
as GSM_BAD_FRAME. The application can now handle the GAP of missing
audio. (e.g. by extrapolation)
If TRAU frames are forwarded via RTP, bad frames are dropped, but frame
counter and timestamp of RTP sender state is incremented.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Merge without testcase, fix typo]
This repository contains a C-language implementation of a GSM Base Station
Controller (BSC). It is part of the
[Osmocom](https://osmocom.org/) Open Source Mobile Communications
project.
OsmoBSC exposes
* *A over IP* towards an MSC (e.g. [osmo-msc](https://osmocom.org/projects/osmomsc/wiki)): 3GPP AoIP or SCCPlite
* *Abis* interfaces towards various kinds of BTS (e.g. [osmo-bts](https://osmocom.org/projects/osmobts/wiki/Wiki), sysmobts, nanoBTS, Siemens, Nokia, Ericsson)
* The Osmocom typical telnet *VTY* and *CTRL* interfaces.
* The Osmocom typical *statsd* exporter.
* Cell Broadcast Service Protocol (*CBSP*) towards a CBC (Cell Broadcast Centre, such as [osmo-cbc](https://osmocom.org/projects/osmo-cbc/wiki)).
* Lb interface towards a *SMLC* (Serving Mobile Location Centre, such as [osmo-smlc](https://osmocom.org/projects/osmo-smlc/wiki/OsmoSMLC)).
Homepage
--------
You can find the OsmoBSC homepage with issue tracker and wiki online at
<https://osmocom.org/projects/osmobsc/wiki>.
GIT Repository
--------------
You can clone from the official osmo-bsc.git repository using
AM_CONDITIONAL(BUILD_IPA_UTILS, test "x$osmo_ac_ipa_utils" = "xyes")
AC_SUBST(osmo_ac_ipa_utils)
# Enable/disable osmo-meas-udp2db
AC_ARG_ENABLE([meas-udp2db], [AS_HELP_STRING([--enable-meas-udp2db], [Build osmo-meas-udp2db: listen to meas_feed on UDP and write it to an sqlite3 database [default=no]])],
AM_CONDITIONAL(BUILD_MEAS_UDP2DB, test "x$osmo_ac_meas_udp2db" = "xyes")
AC_SUBST(osmo_ac_meas_udp2db)
# Enable/disable osmo-meas-pcap2db
AC_ARG_ENABLE([meas-pcap2db], [AS_HELP_STRING([--enable-meas-pcap2db], [Build osmo-meas-pcap2db: read PCAP file with meas_feed data and write it to an sqlite3 database [default=no]])],
The `osmo-bsc/doc/examples/osmo-bsc` directory in the OpenBSC source
tree contains a collection of example configuration files, sorted by BTS
type.
This chapter is illustrating some excerpts from those examples
[[bts_example_nbts]]
=== Example configuration for OsmoBSC with one single-TRX nanoBTS
.OsmoBSC with one single-TRX nanoBTS
====
----
e1_input
e1_line 0 driver ipa <1>
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
handover 0
bts 0
type nanobts <2>
band DCS1800 <3>
cell_identity 0
location_area_code 0x0001
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator mode set-all ascending
rach tx integer 9
rach max transmission 7
ipa unit-id 1801 0 <4>
oml ipa stream-id 255 line 0
gprs mode none
trx 0
rf_locked 0
arfcn 871 <5>
nominal power 23
max_power_red 20 <6>
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config TCH/F
timeslot 6
phys_chan_config TCH/F
timeslot 7
phys_chan_config TCH/F
----
====
<1> You have to configure one virtual E1 line with the
IPA driver in order to use Abis/IP. One e1_line is
sufficient for any number of A-bis/IP BTSs, there is no
limit like in physical E1 lines.
<2> The BTS type must be set using `type nanobts`
<3> The GSM band must be set according to the BTS hardware.
<4> The IPA Unit ID parameter must be set to what has been configured on
the BTS side using the __BTS Manager__ or `ipaccess-config`.
<5> The ARFCN of the BTS.
<6> All known nanoBTS units have a nominal transmit power of 23 dBm. If
a `max_power_red` of 20 (dB) is configured, the resulting output
power at the BTS Tx port is 23 - 20 = 3 dBm.
[NOTE]
====
The `nominal_power` setting does __not__ influence the transmitted power
to the BTS! It is a setting by which the system administrator tells the
BSC about the nominal output power of the BTS. The BSC uses this as
basis for calculations.
====
[[bts_example_nbts_multi]]
=== Example configuration for OsmoBSC with multi-TRX nanoBTS
.OsmoBSC configured for dual-TRX (stacked) nanoBTS
====
----
e1_input
e1_line 0 driver ipa
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
handover 0
bts 0
type nanobts
band DCS1800
cell_identity 0
location_area_code 0x0001
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator mode set-all ascending
rach tx integer 9
rach max transmission 7
ipa unit-id 1800 0 <1>
oml ipa stream-id 255 line 0
gprs mode none
trx 0
rf_locked 0
arfcn 871
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config TCH/F
timeslot 6
phys_chan_config TCH/F
timeslot 7
phys_chan_config TCH/F
trx 1
rf_locked 0
arfcn 873
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config SDCCH8
timeslot 1
phys_chan_config TCH/F
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config TCH/F
timeslot 6
phys_chan_config TCH/F
timeslot 7
phys_chan_config TCH/F
----
====
<1> In this example, the IPA Unit ID is specified as `1800 0`. Thus, the
first nanoBTS unit (`trx 0`) needs to be configured to 1800/0/0 and
the second nanoBTS unit (`trx 1`) needs to be configured to 1800/0/1.
You can configure the BTS unit IDs using the `ipaccess-config`
utility included in OsmoBSC.
[NOTE]
====
For building a multi-TRX setup, you also need to connect the TIB cables
between the two nanoBTS units, as well as the coaxial/RF AUX cabling.
====
[[example_e1_cfg]]
=== Example configuration for OsmoBSC with E1 BTS
The following configuration sample illustrates the usage of BTSs that are
connected via an E1/T1 backhaul.
.OsmoBSC configured for single-TRX E1 Ericsson DUG20
====
----
e1_input <1>
e1_line 0 driver dahdi
e1_line 0 port 3
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
handover 0
bts 0
type rbs2000
band GSM900
om2000 version-limit oml gen 12 rev 10 <2>
cell_identity 0
location_area_code 0x0001
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator mode set-all ascending
rach tx integer 9
rach max transmission 7
oml e1 line 0 timeslot 1 sub-slot full <3>
oml e1 tei 62 <4>
gprs mode none
is-connection-list add 4 512 12 <5>
is-connection-list add 16 524 12
is-connection-list add 28 536 12
is-connection-list add 40 548 12
trx 0
rf_locked 0
arfcn 123
nominal power 42
max_power_red 12
rsl e1 line 0 timeslot 1 sub-slot full <6>
rsl e1 tei 0 <7>
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
e1 line 0 timeslot 1 sub-slot full <8>
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 1 <9>
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 2
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 3
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 1
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 2
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 3
----
====
<1> In this example we use a dahdi E1 card. This card has 4 ports. Here we use port numer 3. It should be noted that the dahdi driver also requires additional configuration, which is not covered by this manual.
<2> In this example we use an E1 Ericsson DUG20, which uses an OML dialect, called "OM2000".
<3> The first usable timeslot on an E1 line is TS1. In this example we will assume that TS1-TS3 are connected to the BTS stright through. TS1 will handle all signaling traffic. Here we assign this timeslot to OML.
<4> OML always requires a TEI (Terminal Equipment Identifier) to set up. This number can be found in the manual of the BTS.
<5> This BTS has an built in “Interface Switch” (IS) that offers flexible way to reconfigure the interconnection between the internal components of the BTS and the external E1 line. This depends on the exact BTS type and configuration. See also <<cfg_ericsson_rbs_is>>
<6> Similar to OML we assign TS1 to RSL as well.
<7> Like with OML, RSL also requires a TEI to be configured. Usually each TRX will have a specific TEI assigned.
<8> CCCH+SDCCH4 will also be mapped on TS1. The traffic for those control channels will be multiplexed alongside the RSL and OML traffic.
<9> The bandwidth of one E1 timeslot matches the bandwidth of 4 GSM air interface timeslots. The E1 timeslot is split up into four sub-slots, which are then assigned to one GSM air interface timeslot each. Since the first timeslot on the first TRX is already used for signaling we begin the sub-slot counting with sub-slot 1 for alignment reasons.
=== Example configuration for OsmoBSC with Ericsson RBS E1 BTS and EGPRS
The following example illustrates the usage of Ericsson RBS2000/RBS6000 BTSs.
This classic E1 BTS has no built in PCU and therefore requires the configuration
of a BSC co-located OsmoPCU (see also: <<cfg_bsc_co_located_pcu>>).
It should also be noted that the Ericsson RBS2000/RBS6000 series is the first
BTS of this type to be supported by OsmoBTS and OsmoPCU. The implementation has
been made possible through funding by the NLnet Foundation.
Ericsson RBS2000/RBS6000 BTSs feature two GPRS modes. A 16kbps GPRS mode where
only CS1 and CS2 are supported and an EGPRS mode where MCS1 to MCS9 are
supported. OsmoPCU offers support for both modes but since the 16kbps mode only
supports classic GPRS with CS1 and CS2 it is more of experimental interest
and shall not be discussed further. The following example will describe how
to configure the 64kbps mode with EGPRS.
In the following example we also expect that the user is already familliar
with the E1 configuration example above (see also: <<example_e1_cfg>>)
.OsmoBSC configured for single-TRX E1 Ericsson DUG20 with EGPRS
====
----
e1_input
e1_line 0 driver dahdi
e1_line 0 port 3
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
handover 0
pcu-socket /tmp/pcu_bts <1>
bts 0
type rbs2000
band GSM900
om2000 version-limit oml gen 12 rev 10
cell_identity 0
location_area_code 0x0001
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator mode set-all ascending
rach tx integer 9
rach max transmission 7
oml e1 line 0 timeslot 1 sub-slot full
oml e1 tei 62
gprs mode egprs <2>
gprs routing area 0
gprs network-control-order nc0
gprs cell bvci 2
gprs nsei 101
gprs nsvc 0 nsvci 101
gprs nsvc 0 local udp port 23100
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 127.0.0.1
is-connection-list add 4 712 36 <3>
trx 0
rf_locked 0
arfcn 123
nominal power 42
max_power_red 12
rsl e1 line 0 timeslot 1 sub-slot full
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
e1 line 0 timeslot 1 sub-slot full
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot full <4>
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 4 sub-slot full
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 5 sub-slot full
timeslot 4
phys_chan_config TCH/F_TCH/H_SDCCH8_PDCH <5>
hopping enabled 0
e1 line 0 timeslot 6 sub-slot full
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 7 sub-slot full
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 8 sub-slot full
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 9 sub-slot full
----
====
<1> This configures the PCU socket path (see also: <<cfg_bsc_co_located_pcu>>)
<2> This configures the general GPRS parameters. The configuration is no
different from BTS with built-in PCU.
<3> The Ericsson RBS2000/RBS6000 series has an built in “Interface Switch” (IS)
that offers flexible way to reconfigure the interconnection between the internal
components of the BTS and the external E1 line. Since 16kbps subslots cannot
supply the bandwidth required for EGPRS the IS must be configured to connect
the 64kbps interface of the TRU to the external E1 line. For a more detailed
description of the IS see <<cfg_ericsson_rbs_is>>.
<4> Since we are using the 64kbps TRU interface we must configure a full E1
timeslot per air interface time slot. For Speech this will have no effect on
the TRAU frame format. The only difference is that always the first 16kbps
subslot of the assigned E1 timeslot is used. OsmoMGW will be instructed
accordingly by OsmoBSC, so no re-configuration of OsmoMGW is required.
<5> In this example we will use air interface TS 4 as PDCH. As mentioned
earlier Ericsson RBS2000/RBS6000 supports the 'DYNAMIC/OSMOCOM' timeslot model.
PDCH timeslots must be configured as dynamic timeslots. It is not possible to
configure static PDCHs. Therefore the phys_chan_config must be set to
TCH/F_TCH/H_SDCCH8_PDCH in order to use the air interface timeslot as PDCH.
NOTE: As of March 2023 the BSC co-located PCU support for Ericsson RBS was
tested only with a single BTS. Even though OsmoBSC and OsmoPCU should be able
to handle multiple BTS, unexpected bahviour should be taken into account.
=== E1 Line number and MGCP trunk number
The switching of the voice channels is done via OsmoMGW, which acts as a media
converter between E1 and VoIP (RTP). OsmoBSC will use the E1 line number to
address the trunk via MGCP.
When configuring OsmoMGW, one needs to make sure that the trunk number that is
set up on OsmoMGW, matches the line number that is set up on OsmoBSC. When those
numbers mismatch the trunk cannot be addressed correctly.
.OsmoMGW trunk configuration that matches the OsmoBSC configuration above
|[bts.N.]handover2.power.budget.interval|RW|No|<1-99>,"default"|How many dB stronger must a neighbor be to become a HO candidate.
|[bts.N.]handover2.power.budget.hysteresis|RW|No|<0-999>,"default"|How many dB stronger must a neighbor be to become a HO candidate.
|[bts.N.]handover2.maximum.distance|RW|No|<0-9999>,"default"|Maximum Timing-Advance value (i.e. MS distance) before triggering HO.
|[bts.N.]handover2.assignment|RW|No|"0","1","default"|Enable or disable in-call channel re-assignment within the same cell.
|[bts.N.]handover2.tdma-measurement|RW|No|"full","subset","default"|Define measurement set of TDMA frames.
|[bts.N.]handover2.min.rxlev|RW|No|<-110--50>,"default"|How weak may RxLev of an MS become before triggering HO.
|[bts.N.]handover2.min.rxqual|RW|No|<0-7>,"default"|How bad may RxQual of an MS become before triggering HO.
|[bts.N.]handover2.afs-bias.rxlev|RW|No|<0-20>,"default"|RxLev improvement bias for AFS over other codecs.
|[bts.N.]handover2.afs-bias.rxqual|RW|No|<0-7>,"default"|RxQual improvement bias for AFS over other codecs.
|[bts.N.]handover2.min-free-slots.tch-f|RW|No|<0-9999>,"default"|Minimum free TCH/F timeslots before cell is considered congested.
|[bts.N.]handover2.min-free-slots.tch-h|RW|No|<0-9999>,"default"|Minimum free TCH/H timeslots before cell is considered congested.
|[bts.N.]handover2.max-handovers|RW|No|<1-9999>,"default"|Maximum number of concurrent handovers allowed per cell.
|[bts.N.]handover2.penalty-time.max-distance|RW|No|<0-99999>,"default"|ime to suspend handover for a subscriber after leaving this cell due to exceeding max distance.
|[bts.N.]handover2.penalty-time.failed-ho|RW|No|<0-99999>,"default"|Time to suspend handover for a subscriber after a failed handover into this cell.
|[bts.N.]handover2.penalty-time.failed-assignment|RW|No|<0-99999>,"default"|Time to suspend handover for a subscriber after a failed re-assignment within this cell.
|[bts.N.]handover2.retries|RW|No|<0-9>,"default"|Number of times to immediately retry a failed handover/assignment, before a penalty time is applied.
|handover2.congestion-check|RW|No|"disabled",<1-999>,"now"|Congestion check interval in seconds, "now" triggers immediate congestion check.
|bts.N.neighbor-list.mode|WO|No|"automatic","manual","manual-si5"|Mode of Neighbor List generation.
|bts.N.neighbor-list.add|WO|No|<0-1023>|Add to manual neighbor list.
|bts.N.neighbor-list.del|WO|No|<0-1023>|Delete from manual neighbor list.
|bts.N.neighbor-list.si5-add|WO|No|<0-1023>|Add to manual SI5 neighbor list.
|bts.N.neighbor-list.si5-del|WO|No|<0-1023>|Delete from manual SI5 neighbor list.
|bts.N.neighbor-list.si2|RO|No|"<arfcn>"|Get space concatenated list of SI2 neighbor ARFCNs.
|bts.N.neighbor-list.si5|RO|No|"<arfcn>"|Get space concatenated list of SI5 neighbor ARFCNs.
|bts.N.neighbor-list.si2quater.uarfcns|RO|No|"<uarfcn>,<scrambling code>,<diversity bit>"|Get space concatenated list of UARFCN neighbors.
|bts.N.neighbor-list.si2quater.earfcns|RO|No|"<earfcn>,<thresh-hi>,<thresh-lo>,<prio>,<qrxlv>,<meas>"|Get space concatenated list of EARFCN neighbors.
Most handover related procedures are explained in 3GPP TS 48.008.
=== How Handover Works
This chapter generally explains handover operations between 2G cells.
==== Internal / Intra-BSC Handover
The BSS is configured to know which cell is physically adjacent to which other
cells, its "neighbors". On the MS/BTS/BSS level, individual cells are
identified by ARFCN+BSIC (frequency + 6-bit identification code).
The BSC instructs each BTS with a list of ARFCNs (i.e. GSM frequency bands)
that qualify as neighbor cells, as part of the System Information Type 2. Each
MS served by a BTS receives the System Information Type 2 and thus knows which
ARFCNs to measure for potential handover. Each MS with an active channel then
returns up to 6 measurements of reception levels (RXLEV) to the BTS, to be
forwarded to the BSC in RSL Measurement Report messages.
Note that the BTS and MS are told only the ARFCNs, not the BSICs, of neighbor
cells; the BSICs are however included in the measurements that an MS returns to
BTS and BSC. Commonly, each ARFCN is owned by one specific operator, so, an MS
considers all visible cells on a given ARFCN as possible neighbors. However, as
soon as an MS reports RXLEV of a specific neighbor cell, the BSC needs to know
which exact cell to possibly handover to, which is why the MS pinpoints the
specific BSIC that it reported measurements for.
The BSC is the point of decision whether to do handover or not. This can be a
hugely complex combination of heuristics, knowledge of cell load and codec
capabilities. The most important indicator for handover though is: does an MS
report a neighbor with a better signal than the current cell? See
<<intra_bsc_ho_dot>>.
[[intra_bsc_ho_dot]]
.Intra-BSC Handover stays within the BSS (shows steps only up to activation of the new lchan -- this would be followed by an RR Handover Command, RACH causing Handover Detection, Handover Complete, ...)
[graphviz]
----
include::handover_intra_bsc.dot[]
----
If the BSC sees the need for handover, it will:
- activate a new lchan (with a handover reference ID),
- send an RR Handover Command to the current lchan, and
- wait for the MS to send a Handover RACH to the new lchan ("Handover Detect").
- The RTP stream then is switched over to the new lchan,
- an RSL Establish Indication is expected on the new lchan,
- and the old lchan is released.
Should handover fail at any point, e.g. the new lchan never receives a RACH, or
the MS reports a Handover Failure, then the new lchan is simply released again,
and the old lchan remains in use. If the RTP stream has already been switched
over to the new lchan, it is switched back to the old lchan.
This is simple enough if the new cell is managed by the same BSC: the OsmoMGW
is simply instructed to relay the BTS-side of the RTP stream to another IP
address and port, and the BSC continues to forward DTAP to the MSC
transparently. The operation happens completely within the BSS, except for the
BSSMAP Handover Performed message sent to the MSC once the handover is
completed (see 3GPP TS 48.008).
==== External / Inter-BSC Handover
If the handover target cell belongs to a different BSS, the RR procedure for
handover remains the same, but we need to tell the _remote_ BSC to allocate the
new lchan.
The only way to reach the remote BSC is via the MSC, so the MSC must be able
to:
- identify which other BSC we want to talk to,
- forward various BSSMAP Handover messages between old and new BSC,
- redirect the core-side RTP stream to the new BSS at the appropriate time,
- and must finally BSSMAP Clear the connection to the old BSS to conclude the
inter-BSC handover.
[[inter_bsc_ho_dot]]
.Inter-BSC Handover requires the MSC to relay between two BSCs (shows steps only up to the BSSMAP Handover Command -- this would be followed by an RR Handover Command, RACH causing Handover Detection, Handover Complete, ...)
[graphviz]
----
include::handover_inter_bsc.dot[]
----
The first part, identifying the remote BSC, is not as trivial as it sounds: as
mentioned above, on the level of cell information seen by BTS and MS, the
neighbor cells are identified by ARFCN+BSIC. However, on the A-interface and in
the MSC, there is no knowledge of ARFCN+BSIC configurations. Instead, each
cell is identified by a LAC and CI (Location Area Code and Cell Identifier).
NOTE: There are several different cell identification types on the A-interface:
from Cell Global Identifier (MCC+MNC+LAC+CI) down to only LAC. OsmoBSC supports
most of these (see <<neighbor_conf_list>>). For simplicity, this description
focuses on LAC+CI identification.
Hence:
- the BSC needs to know which remote-BSS cells' ARFCN+BSIC correspond to
exactly which global LAC+CI, and
- the MSC needs to know which LAC+CI are managed by which BSC.
In other words, each BSC requires prior knowledge about the cell configuration
of its remote-BSS neighbor cells, and the MSC requires prior knowledge about
each BSC's cell identifiers; i.e. these config items are spread reduntantly.
The most obvious reason for using LAC+CI in BSSMAP is that identical ARFCN+BSIC
are typically re-used across many cells of the same network operator: an
operator will have only very few ARFCNs available, and the 6bit BSIC opens only
a very limited range of distinction between cells. As long as each cell has no
more than one neighbor per given ARFCN+BSIC, these values can be re-used any
number of times across a network, and even between cells managed by one and the
same BSC.
[[config_neigh]]
=== Configuring Neighbors
The most important step to enable handover in OsmoBSC is to configure each cell
with the ARFCN+BSIC identities of its adjacent neighbors -- both local-BSS and
remote-BSS.
For a long time, OsmoBSC has offered configuration to manually enter the
ARFCN+BSIC sent out as neighbors on various System Information messages (all
`neighbor-list` related commands). This is still possible; however,
particularly for re-using ARFCN+BSIC within one BSS, this method will not work
well.
With the addition of inter-BSC handover support, the new `neighbor` config item
has been added to the `bts` config node, to maintain explicit cell-to-cell neighbor
relations, with the possibility to re-use ARFCN+BSIC in each cell.
It is recommended to completely replace `neighbor-list` configurations with the
new `neighbor` configuration described below.
[[neighbor_conf_list]]
.Overview of neighbor configuration on the `bts` config node
[frame="none",grid="none",cols="^10%,^10%,80%"]
|====
| Local | Remote BSS | type of `neighbor` config line, by example
Oliver Smith
Max
Pau Espin
Harald Welte
Vadim Yanitskiy
Neels Hofmeyr
Keith Whyte
Philipp Maier
Daniel Willmann
Eric Wild
Sylvain Munaut
Martin Hauke
Alexander Huemer
Dieter Spaar