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
Matan Perelman
