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"
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
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
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
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
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