aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-12-11debian, osmoappdesc.py, tests: switch to python 3osmith/fix-python3Oliver Smith4-226/+226
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
2019-12-06gsm_04_80: Avoid using deprecated APIHarald Welte1-1/+2
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
2019-12-05doc: osmux: use generated svg instead of pychartOliver Smith2-45/+824
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
2019-12-03exit(2) on unsupported positional arguments on command lineHarald Welte3-0/+13
Change-Id: I3b8781e220326387f1c437c39aff8661326f1e0a
2019-12-02abis_nm.c: fix RSL connection timeout for trx->nr > 0Vadim Yanitskiy1-4/+21
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
2019-12-01Move a_reset_fsm regstration to __attribute__((contructor))Harald Welte1-4/+5
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
2019-12-01manual: Fix copy+paste errorHarald Welte1-1/+1
Change-Id: I787c4bd4b30a6620a987efed4fd8b46e14a7ea64
2019-12-01check for osmo_ss7_init() error return valueHarald Welte1-1/+1
Change-Id: I0297352e3cba5f01a971dc5924f0fcc67d1e6b32
2019-12-01check for osmo_fsm_register() error return valueHarald Welte2-4/+4
Change-Id: I77e8ace007a3d6b9c40d3e158d1cdb7576aab77b
2019-11-23fsm: use deferred deallocationNeels Hofmeyr1-1/+3
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
2019-11-20bsc: Send MS Power Control msg upon max MS power changePau Espin Pedrol10-3/+33
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
2019-11-19abis_nm.c: replace magic numbers with NM_CHANC_* constantsVadim Yanitskiy1-3/+3
Change-Id: I60b20d617bd8710a95977e41ae32a431af4402a9
2019-11-19abis_nm.c: fix error message in verify_chan_comb()Vadim Yanitskiy1-1/+1
Change-Id: Ic72753d821c3ab72cda79be71aed1704beefe983
2019-11-19cosmetic: bs11_config: clean trailing whitespacePau Espin Pedrol1-4/+4
Change-Id: I55f478c753c38baa576abc6ba53c4f6c9cbe61c0
2019-11-19bsc: Adapt maximum MS Power Ctrl level based on band and MS Power classPau Espin Pedrol6-14/+133
Related: OS#4244 Change-Id: I6bff440b7797e710bca5af94fae546e5d55e6972
2019-11-13Fix some typosMartin Hauke48-88/+88
Fix typos and common misspellings in code comments and in the manual. Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c
2019-11-02osmo_bsc_main.c: fix CCCH_CONF computation: use pchan_from_configVadim Yanitskiy1-4/+4
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
2019-11-02osmo_bsc_main.c: simplify computation of CCCH_CONFIGVadim Yanitskiy1-23/+10
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
2019-11-02osmo_bsc_main.c: verify the physical channel mapping at startupVadim Yanitskiy3-0/+63
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
2019-11-02VTY: also print the active phan config in ts_dump_vty()Vadim Yanitskiy1-2/+3
Change-Id: I45c93a737ad82a2525f941e89cd19d4cedbf6f02
2019-10-31gsm_data.h: Remove unused func declarationsPau Espin Pedrol1-3/+0
Change-Id: I189d34b6db78de749e1901733d0df35411e0d583
2019-10-31gsm_data.h: Remove unused field classmark from gsm_subscriber_connectionPau Espin Pedrol1-3/+0
Change-Id: If2826a8f334afabfa3a0198a0bc1eed009962c81
2019-10-31Remove unused API classmark_is_r99()Pau Espin Pedrol2-12/+0
Furthermore, similar API already exist in libosmocore: osmo_gsm48_classmark_is_r99() Change-Id: I6763d8c894f0a0555a9801bddbc0a12c2b945599
2019-10-29rsl: Send IE MS Power Param to osmocom BTS models onlyPau Espin Pedrol1-2/+10
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
2019-10-29rsl.c: Clean up some repeated use of long chains of pointersPau Espin Pedrol1-5/+9
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
2019-10-28rsl: Send IE MS Power Param during CHAN ACT and MS PWR CTRL messagesPau Espin Pedrol1-0/+5
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
2019-10-28bsc_vty: Fix typo in 'no depends-on-bts' cmdPau Espin Pedrol1-1/+1
Change-Id: I32e0d3dc8672206f346d25b45e06e9e3fe0b64e7
2019-10-11sigtran: Set default remote ip to localhost instead of nullPau Espin Pedrol1-1/+2
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
2019-10-03gsm_08_08.c: Mark func bsc_find_msc() staticPau Espin Pedrol2-2/+1
Its currently only used by bsc_compl_l3() in same file. Change-Id: I7273a9452dbc4c1285cfa69269fa36ab09551d89
2019-09-18bsc_subscr_conn_fsm: Cleanly clear BSSAP conn if associated channel closed ↵Pau Espin Pedrol1-5/+28
during WAIT_CC 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
2019-09-08SMSCB: Send ETWS Primary Notifiation via RSL to BTSHarald Welte4-6/+44
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
2019-09-07bsc: gsm_08_08.c: Remove repeated conn not null checkPau Espin Pedrol1-1/+1
msc_is_connected() already checks against NULL. Change-Id: Ie9635cd2c6149cd0f8c017cfcb47481f91c4bed1
2019-09-07a_reset.c: Don't wait 2 seconds to send first BSSMAP RESETPau Espin Pedrol1-4/+3
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
2019-09-06SMSCB: Send ETWS primary warning message via all dedicated channelsHarald Welte3-2/+85
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
2019-09-04manual: Update statements regarding SCCPliteHarald Welte1-14/+7
SCCPlite is long supported (again) by osmo-bsc, let's remove the outdated pointers to osmo-bsc-sccplite. Change-Id: Ia3d831aca7c3c7ef9f257e974faf6e8e360c59f5
2019-09-02doc: update bsc_vty_reference.xmlHarald Welte1-34/+140
Change-Id: I6244a0de8802f437b5b291c76b4fc7bd4262baf8
2019-09-02Cell Broadcast: CBSP and CBCH scheduling supportHarald Welte19-7/+1898
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
2019-08-28gsm_08_08.c: always pick first msc for unsolicit paging responsesPhilipp Maier1-3/+16
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
2019-08-23lchan_select.c: tune log level in lchan_select_by_type()Vadim Yanitskiy1-1/+1
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
2019-08-23abis_nm.c: use LOGP() macro instead of LOGPC()Vadim Yanitskiy1-3/+3
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
2019-08-13neighbor config: allow re-using ARFCN+BSIC pairsNeels Hofmeyr8-60/+240
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
2019-08-13add vty 'no neighbors' to remove all HO targetsNeels Hofmeyr2-0/+111
This is required for an upcoming TTCN3 test that plays through various neighbor configurations. Related: OS#4056 Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc (osmo-ttcn3-hacks) Change-Id: I8623ab581639e9f8af6a9ff1eca990518d1b1211
2019-08-12bsc_msc_data: remove unused member is_authenticatedPhilipp Maier3-10/+0
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
2019-08-07Bump version: 1.4.0.109-caec1-dirty → 1.5.01.5.0Pau Espin Pedrol3-11/+146
Change-Id: I4b73d0a83b1ed1a4dfd17066182820da5e401c9b
2019-08-05Remove undefined param passed to logging_vty_add_cmdsPau Espin Pedrol1-1/+1
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
2019-07-26rest_octets: add Serving Cell Priority ParametersPhilipp Maier2-70/+87
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
2019-07-24osmo-bsc.cfg: work with osmo-bts example cfgOliver Smith2-3/+3
Change cell_identity and unit-id to match osmo-bts-virtual.cfg. Related: OS#3369 Change-Id: Ie8001611756b661ff1871508c6248b2e990ba1d7
2019-07-23turn -Werror=null-dereference into a warningEric Wild1-1/+1
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
2019-07-22doc: Add Osmux documentation to User ManualPau Espin Pedrol2-1/+46
Depends: osmo-gsm-manuals.git f3a734e6777a902abfb03257277454c7a879aeb7 Change-Id: I75dcdddc713b0dc43e2ba577ca377c20fc511f38
2019-07-19vty: Fix typo in VTY command descrption -> descriptionHarald Welte5-20/+42
Let's add deprecated aliases for backwards compatibility Change-Id: I0e5da9d702910cf2571486e22a56f3ec17d0d67b
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 22:00:11 +0000