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
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
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
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
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
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 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
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
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
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
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
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
Andreas Eversberg
Vadim Yanitskiy
Oliver Smith
Pau Espin
Harald Welte
Philipp Maier
Daniel Willmann
Neels Hofmeyr