|Age||Commit message (Collapse)||Author||Files||Lines|
Test case TC_lost_sdcch_during_assignment from ttcn3-bsc-test
causes osmo-bsc to crash due to for_conn being NULL.
Related: SYS#5526, OS#5255
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.
Related: SYS#5627, OS#5255
Requires: osmo-gsm-manuals.git Id344c29eda2a9b3e36376302b425e9db1f6c0f28
Requires: libosmo-abis.git I8991dd6eb406a5b9a70498974fc1ad339452f871
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
I have now verified by hand against 3GPP TS 44.018 that each one of the
generated octets are indeed correct.
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.
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.
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.
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.
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.
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.
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*().
A clarification that I promised a while back but forgot to submit.
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
Depends: libosmocore.git Change-Id I6280ce1abc283f1491bc6f391b2dd952df33a16b
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.
Depends: libosmocore.git Change-Id I0e55e947b6fef6dad0cf1a6c16b781bef4cc76c5
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 c1a5310a3ed75ff24dc2d6a48c09d8dfc89d944c.
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.
E-UTRAN PLMN ID
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 "188.8.131.52 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.
For neighbors configured without explicit ARFCN+BSIC ('neighbor bts N',
'neighbor lac-ci N M', ...), actually use the local neighbor cell's
So far the code looked correct on first sight, but passed an unused part
of the struct neighbor union, always resulting in ARFCN 0.
This change will allow handling more IEs in the future, like
"Last used E-UTRAN PLMN ID" one.
For "reported feature '%s'...", use the short feature name, which better
matches the message.
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'.
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
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.
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
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.
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.
Before, it is not clear whether the RTP is already done setting up or
the RTP is skipped entirely. This log message clarifies that.
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.
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
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.
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.
Increase the number of values saved in the FIFO from 16 to 60, so there
is more time to read them out.
Allow selection of RX diversity from VTY
Options are a,ab,b
Default is 'a' so there is no change from previous behavior
This commit adds support for Selection of syncronization source.
Options are internal for E1 and external for GPS
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/...>