aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-06-06ts_fsm: Properly cleanup the FSM on cleanup.fairwaves/stats-workAlexander Chemeris1-0/+4
Though it looks like this code is never actually executed because TS in the current model TS FSM instances are created on the BTS structure allocation and are never destroyed. Change-Id: Ie642d201c7b1333321319cd5220c9778d7e6138e
2020-06-06TRX can't be usable when the RSL link is down.Alexander Chemeris1-0/+4
Change-Id: Ib5137e95efd27e019d80ff6164e1f80615e517a6
2020-06-06chan_alloc: Fix calculation of total available channels.Alexander Chemeris1-0/+5
Change-Id: I989ebd7a10d223e4237dda705b0b68d5a91661d0
2020-06-06stats: Fix a case where borken TS counters are not reduced on OML/RSL ↵Alexander Chemeris1-7/+16
disconnect. Change-Id: I49880d5cc26dda0bf5a1f7f5d6dbad1b0faa4fb4
2020-06-06stats: Count transitions from BORKEN state due to LCHAN_EV_TS_ERROR signal.Alexander Chemeris2-0/+9
Change-Id: Ice3379020039dc3634aa3887939740729d720dee
2020-06-06timeslot_fsm: Name TS FSM instances on allocation.Alexander Chemeris1-0/+1
Before this patch FSM instances of configured but not connected BTS's look like this: FSM Instance Name: 'timeslot[0x612000004a20]', ID: '(null)' Log-Level: 'DEBUG', State: 'NOT_INITIALIZED' Now they look like this: FSM Instance Name: 'timeslot(0-0-7-NONE)[0x612000004a20]', ID: '0-0-7-NONE' Log-Level: 'DEBUG', State: 'NOT_INITIALIZED' which makes it possible to attribute them to where they belong. Otherwise, they look like lingering or leaking unattributed FSM instances. Change-Id: Idc74ea142b96323b48826f8a52e13e45d535512a
2020-06-06chan_alloc: Fix typo in a comment.Alexander Chemeris1-1/+1
Change-Id: Iaed3fcd99ec8c08faa75e23af5b50a1d0e0905eb
2020-06-06paging: Remove obsolete comment.Alexander Chemeris1-6/+0
I beleive MSC split is finished a long time ago and everything is already re-wired for the A-interface. Change-Id: If2a0b15e360c44abc92fdeb9004be7ccc0537cdd
2020-06-06stats: Add a BTS counter for paging requests responded elsewhere.Alexander Chemeris2-1/+5
If we have several BTS in a single LAC, only one of them will respond to the paging. Without this counter this situation will lead to "lost" paging requests, i.e. in disparity between attempted pagings and expired/responded/etc pagings. That siad, even after this counter we're still observing some unaccounted ("lost") paging requests, so the saga for correctly counting paging is to continue... Change-Id: I4b27a0559ef2762e62bc3ac30000f17b89b0ed48
2020-06-03is_cm_service_for_emerg(): return false, not 0Neels Hofmeyr1-1/+1
Change-Id: Ife25ed26214abf7aea95b0b7943d9fa585868529
2020-06-03cosmetic: tweak rc type of is_cm_service_for_emerg()Neels Hofmeyr1-1/+1
Change-Id: Id752d3882645708b5b8e1058b6799d3d285286c4
2020-06-03create only one SCCP user per SCCP instanceNeels Hofmeyr1-2/+6
Depends: I9ecbab16b45268f626950303d6ff8296dd6acda0 (libosmo-sccp) Change-Id: I6a2710edeb9ba047ae70e6b49d4c2e5f06d41a4e
2020-06-03CTRL: determine MSC connection status from RESET-ACK, not AS_ACTIVENeels Hofmeyr1-10/+2
Change-Id: I264ba6a72ea93297cfbc99602eccfbf4a890f703
2020-06-03abis_nm: fix: properly truncate feature vector reported by BTSVadim Yanitskiy1-3/+4
The value of the feature vector can not only be greater, but also shorter than size of the buffer! This would potentially result in a buffer overrun. Let's fix this. Change-Id: I65e3228022865ea73de2e4821985df3097b9448b
2020-06-03abis_nm: cosmetic: use sizeof() for printing buffer sizeVadim Yanitskiy1-2/+2
Change-Id: I14be343578a64c1e4ce8ce4d28da9008eb309f3c
2020-06-03abis_nm: cosmetic: add curly braces to complex 'if' statementsVadim Yanitskiy1-5/+10
Change-Id: I74fbb46920c74a194c296feeeb1bb086fcbd572f
2020-05-31handover_test: use 'unknown' BTS type instead of 'sysmobts'Vadim Yanitskiy3-3/+5
This unit test does not really need a BTS of such specific type. Change-Id: Id676042518d06e94a9fb20112334280e2b91074b
2020-05-31bsc_bts_alloc_register(): fix possible NULL-pointer dereferenceVadim Yanitskiy1-0/+1
Change-Id: I4560a7037a0a016636c4626c9fb3ceddfe98058e
2020-05-31bts_sysmobts: fix: properly zero-initialize the feature vectorVadim Yanitskiy1-1/+1
The last argument must be size of buffer, not size of size! Change-Id: I6539a3c9829d4f74a18b1cc2aa522c69ff8e638d
2020-05-31bts_unknown: fix: properly initialize the feature vectorVadim Yanitskiy1-0/+6
This is unlikely to cause any problems, but having a NULL-pointer that can potentially be dereferenced is dangerous. Fix this. Change-Id: Icf594604f69023d1483e897edb811e51774b5b8e
2020-05-31gsm_data: cosmetic: mark argument of is_*_bts() as constVadim Yanitskiy1-6/+6
Change-Id: Ifa084e34cbea006e09c83a530e1434a22895e9aa
2020-05-31doc/manuals: regenerate the VTY reference fileVadim Yanitskiy1-130/+0
Change-Id: I4f7bf671b7948d8c3771d33d40ab5e8cf209e2b2
2020-05-29flatten: move network->bsc_data->* to network->*Neels Hofmeyr14-104/+65
The separate struct osmo_bsc_data is like another separate struct gsm_network for no reason. It is labeled "per-BSC data". These days, all of this is a single BSC and there will not be different sets of osmo_bsc_data. Drop struct osmo_bsc_data, move its members directly into gsm_network. Some places tested 'if (net->bsc_data)', which is always true. Modify those cases to rather do checks like 'if (net->rf_ctrl)', which are also always true AFAICT, to keep as much unmodified logic as possible in this patch. Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
2020-05-29drop MSC types "local" vs "normal"Neels Hofmeyr4-24/+4
Another legacy feature. All that this setting effectively does is prevent MSCs from being contacted for non-emergency calls. To select which MSCs shall handle emergency calls, there is the allow_emerg flag. Change-Id: I7fc630d9c35be9a69a0d378d3de2b2312c69690d
2020-05-29doc/examples: remove deprecated ussd text configNeels Hofmeyr1-4/+0
Change-Id: I7c0b615bbb0a5c50341968a748612448ad9d18e4
2020-05-29drop all BSC originated USSD notification featuresNeels Hofmeyr20-542/+27
The BSC is the wrong network component to originate USSD messaging, as can be seen in the hacks in the USSD code: for example, the BSC would send a CM Service Accept message as if an MSC had accepted the connection, dispatch a USSD and directly send some RR release message (without proper tear down messaging like the lchan_fsm does these days). This made sense in the osmo-nitb world, but by now we are aiming for solid 3GPP compliance. The BSC shall not originate USSD messages. Deprecate all VTY and CTRL commands related to USSD: VTY [no] bsc-welcome-text [no] bsc-msc-lost-text [no] bsc-grace-text [no] missing-msc-text (the commands with 'no' are ignored, without 'no' lead to an error) CTRL ussd-notify-v1 Drop (already unused) ussd.h. Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code. Drop "RF grace" notification, where osmo-bsc was able to notify active subscribers that the RF was being turned off. Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
2020-05-29code cleanup: absorb complete_layer3() into bsc_compl_l3()Neels Hofmeyr1-29/+18
Tweak return code handling: also return a failure code when dispatching the GSCON_EV_A_CONN_REQ event failed. Change-Id: I939e8a9a865250033e4837439a6b9ec251e5ce4c
2020-05-29drop CC 'local-prefix' featureNeels Hofmeyr5-180/+0
It is not entirely clear to me what this used to do once, but I've stumbled upon this before. By now I am certain that this is a non-standard legacy feature. The BSC does *not* redirect connections during CC transactions. Along with this, a bunch of legacy utility functions can be dropped. All of this is unused code. (Preparing for MSC pooling.) Change-Id: Id54afe8ccf0e11b9121a733224054c9565eafb58
2020-05-29Return 0 from gsm0408_rcvmsg() if SCCP link is already closed.Alexander Chemeris1-1/+1
Whether to forward the message or not to an SCCP connection is an internal question for the GSM 04.08 code. Unlike errors with the message decoding, memory allocation and other critical errors, this not an error which should be reported to the caller. abis_rsl_rx_rll() (the caller) shouldn't know about the message routing decisions and should only care about actual errors. This code path is hit in production very often because we frequently receive a Classmark Change message from a phone right after the MSC has shut the SCCP connection but before we close the lchan on the BTS. Change-Id: I2d430ebc894a2345bebaa1841a75e94a3b45eae2
2020-05-29bsc_subscr_find_or_create_by_{imsi,tmsi}(): fix NULL pointer dereferenceVadim Yanitskiy1-0/+4
Change-Id: Icb89d566b51031c2296be0888f8b7e554aa50418
2020-05-28stats: Count paging requests flushed due to MSC Reset.Alexander Chemeris2-0/+6
Change-Id: Ie93fc54fecdfcf615483f7f41a36dbcea61a537b
2020-05-28bsc_subscr_conn_fsm: Fix crash in gscon_forget_lchan()Alexander Chemeris1-1/+1
conn->fi might be NULL and thus can't be safely dereferenced. E.g. we're checking if it's NULL or not just a few lines above. so we should here as well. Here is a backtrace for the crash: (gdb) bt 0 0x000055b948002772 in gscon_forget_lchan (conn=0x55b949c6b870, lchan=lchan@entry=0x7f00ae9ade68) at bsc_subscr_conn_fsm.c:718 1 0x000055b948036c84 in lchan_fsm_wait_rf_release_ack_onenter (fi=<optimized out>, prev_state=<optimized out>) at lchan_fsm.c:1040 2 0x00007f00afc6a599 in state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, keep_timer=keep_timer@entry=false, timeout_ms=2000, T=3111, file=<optimized out>, line=1344) at fsm.c:699 3 0x00007f00afc6aa5d in _osmo_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, timeout_secs=<optimized out>, T=<optimized out>, file=<optimized out>, line=<optimized out>) at fsm.c:748 4 0x00007f00afc78e62 in _osmo_tdef_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, state=state@entry=8, timeouts_array=timeouts_array@entry=0x55b9482b56a0 <lchan_fsm_timeouts>, tdefs=<optimized out>, default_timeout=140730455622800, default_timeout@entry=5, file=file@entry=0x55b948079d39 "lchan_fsm.c", line=1344) at tdef.c:346 5 0x000055b9480341eb in lchan_fsm_timer_cb (fi=0x55b949bcfe10) at lchan_fsm.c:1344 6 0x00007f00afc6b84a in fsm_tmr_cb (data=0x55b949bcfe10) at fsm.c:325 7 0x00007f00afc65926 in osmo_timers_update () at timer.c:257 8 0x00007f00afc65cda in _osmo_select_main (polling=0) at select.c:260 9 0x00007f00afc66526 in osmo_select_main_ctx (polling=<optimized out>) at select.c:291 10 0x000055b947fdcadf in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953 (gdb) p conn->fi $1 = (struct osmo_fsm_inst *) 0x0 Change-Id: I2427266ef4660935cde899462fa6df8d785c420e
2020-05-27drop IMSI filter and libfilter completelyNeels Hofmeyr17-951/+2
Filtering by IMSI in osmo-bsc is a legacy use case with questionable usefulness. Remove. Do not keep deprecated VTY commands: those could be dangerous, since (presumably non-existing) users might assume that the filtering would still be in place. Rather fail to start osmo-bsc for config with an IMSI ACL. The IMSI filtering did, if present, provide the logging with an IMSI to print for the bsc_subscriber. TMSIs should have ended up in logging likewise, which has never been implemented. The proper way to learn the IMSI would be by the Common Id message from the MSC. Furthermore, the upcoming MSC pooling feature will extract the mobile identity again, and will hence make sure that both IMSI and TMSI identities, as available, end up in the bsc_subscriber and will be logged again. So long, IMSI ACL, and thanks for all the fish. Change-Id: I89727af5387e8360362e995fdee959883c37d89a
2020-05-27cosmetic: put comment back at proper place in bsc_vty.cNeels Hofmeyr1-1/+1
Change-Id: Ie5d44fdb78f3bdabede464d88d493e911512bb35
2020-05-22Makefile.am: EXTRA_DIST: debian, contrib/*.spec.inOliver Smith1-1/+7
Change-Id: I8783d650c489f8b352c9d362b3e4b0eb98e6ae83
2020-05-20contrib: integrate RPM specOliver Smith3-6/+9
Remove OpenSUSE bug report link, set version to @VERSION@, make it build with CentOS 8 etc. Related: OS#4550 Change-Id: I4b87cb0d80bda7bbfda600310aee24a814f97f3f
2020-05-19bsc_patch: Don't even parse MM INFO if TZ patching is not enabled.Alexander Chemeris1-5/+5
Change-Id: Ief159111b8753db83861194c2a035a1f08eb77b0
2020-05-19Fix crash in bsc_patch_mm_info()Alexander Chemeris2-11/+3
osmo-bsc has crashed with the following backtrace: 0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f0bc49b38db in __GI_abort () at abort.c:100 2 0x00007f0bc581ba30 in osmo_panic () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 3 0x00005648ceeced69 in conn_get_bts (conn=<optimized out>) at ../../include/osmocom/bsc/gsm_data.h:1392 4 0x00005648cef37164 in conn_get_bts (conn=0x5648cf769e80) at osmo_bsc_filter.c:87 5 bsc_patch_mm_info (conn=conn@entry=0x5648cf769e80, data=<optimized out>, length=<optimized out>) at osmo_bsc_filter.c:48 6 0x00005648cef371b6 in bsc_scan_msc_msg (conn=conn@entry=0x5648cf769e80, msg=msg@entry=0x5648cf77ead0) at osmo_bsc_filter.c:159 7 0x00005648cef33988 in dtap_rcvmsg (msg=0x5648cf72b2f0, length=40, conn=0x5648cf769e80) at osmo_bsc_bssap.c:1215 8 bsc_handle_dt (conn=conn@entry=0x5648cf769e80, msg=0x5648cf72b2f0, len=40) at osmo_bsc_bssap.c:1299 9 0x00005648cef3b2b7 in handle_data_from_msc (msg=<optimized out>, conn=0x5648cf769e80) at osmo_bsc_sigtran.c:152 10 sccp_sap_up (oph=0x5648cf72b378, _scu=<optimized out>) at osmo_bsc_sigtran.c:267 11 0x00007f0bc5813c03 in _osmo_fsm_inst_dispatch () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 12 0x00007f0bc51a8935 in sccp_scoc_rx_from_scrc (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scoc.c:1695 13 0x00007f0bc51a62f3 in scrc_rx_mtp_xfer_ind_xua (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scrc.c:459 14 0x00007f0bc51a9545 in mtp_user_prim_cb (oph=0x5648cf7681f8, ctx=0x5648cf6a8d60) at sccp_user.c:182 15 0x00007f0bc51a09c6 in m3ua_rx_xfer (xua=0x5648cf764a80, asp=0x5648cf45f540) at m3ua.c:586 16 m3ua_rx_msg (asp=asp@entry=0x5648cf45f540, msg=msg@entry=0x5648cf71e880) at m3ua.c:739 17 0x00007f0bc51b0763 in xua_cli_read_cb (conn=0x5648cf441ed0) at osmo_ss7.c:1761 18 0x00007f0bc55fab53 in osmo_stream_cli_read (cli=0x5648cf441ed0) at stream.c:232 19 osmo_stream_cli_fd_cb (ofd=<optimized out>, what=1) at stream.c:321 20 0x00007f0bc580edcf in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 21 0x00007f0bc580f526 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 22 0x00005648ceecfb2f in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953 Apparently, there is no lchan allocated at this moment, so conn_get_bts() crashes. But we only use it to get to "network" which we can do much easier and safer by doing conn->network. Change-Id: Id3f7b3efba60c0f050c1be98e5e539f1dab4cd57
2020-05-19deprecate 'msc' / 'ip.access rtp-base <port>'Neels Hofmeyr4-19/+3
The bsc_msc_data->rtp_base has been unused ever since we introduced the exernal MGW in osmo-bsc [1]. The vty command also still exists. Deprecate the vty command, remove the member. [1] "mgcp: use osmo-mgw to switch RTP streams" commit 39c609b7c924524172ad311bdf89f92b7ccf175a Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
2020-05-19bssap: Handle BSSMAP CONFUSION message.Alexander Chemeris4-0/+59
We decode the mesage and print it to the log files at ERROR log level. We also count it in the BSSMAP message counters. There is not much else we could do about it. Depends: If8afd2d096fb66c6c2f255a08fc1129de3d09cec (libosmocore) Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
2020-05-19stats: Correctly count lchans under BORKEN TS.Alexander Chemeris1-0/+7
lchans under a BORKEN TS should be counted as used just as BORKEN lchans under a normal TS. Change-Id: Ic3dbc6b176d5dcff7ed2589bb875abf93e9f7ab0
2020-05-19stats: Add a BTS/BSC counter PAGING_NO_ACTIVE_PAGING.Alexander Chemeris2-0/+6
This is a corner case but still we should count the events to know when is this happening. And for the number of paging requests to match the number of paging responses. Change-Id: I1755be40d29980b75353cb4b8087d1ce0d92854a
2020-05-19stats: Add counters and gauges for BORKEN lchans/TSAlexander Chemeris5-11/+148
Now we can monitor the situation with the BORKEN lchans and TS in our BTS's over time. Change-Id: I427bbe1613a0e92bff432a7d76592fe50f620ebe
2020-05-19borken: Recover from more TS borken states.Alexander Chemeris1-3/+16
Change-Id: Ic87c325a73690ede1b81b4d33bac65a1a4beea2d
2020-05-19contrib: import RPM specOliver Smith1-0/+145
Copy the RPM spec file from: https://build.opensuse.org/project/show/home:mnhauke:osmocom:nightly Related: OS#4550 Change-Id: Id0f7568953cbf55d4a2278cf088bb37af0d19d78
2020-05-18manuals: update bsc_vty_reference.xmlNeels Hofmeyr1-1/+40
I notice that some merges seem to have missed updating the bsc_vty_reference.xml file. Re-generating it from current master yields these changes. Change-Id: I75269cbed8dd62be23293fd2c1470af6f61e6ad2
2020-05-17log: Demote "SAPI=%u ESTABLISH CONFIRM" message from ERROR to DEBUG.Alexander Chemeris1-1/+1
Not sure why this specific message is ERROR while similar ones around are DEBUG. So let's fix this disparity by demoting this message level. Change-Id: I655d4555f037def354aacbc5f089794f5fe811ed
2020-05-17log: Demote "CHAN RQD: reason" to INFOAlexander Chemeris1-1/+1
The "CHAN RQD: reason" message is purely informational and is a part of normal operation. Nothing to NOTICE there. Let's demote this to DEBUG. Change-Id: I325f2beb3248ed8eb25d1d8494c3868c5be4b758
2020-05-17bssmap: Ignore repeated BSSMAP RESET ACK messages.Alexander Chemeris1-1/+4
We're sending multiple RESET messages to establish a conection with an MSC and MSC can (and often will) respond with multiple RESET ACK messages. We should not treat this as an ERROR as it used to be in the original code. Change-Id: I109d638d5167e24f0357e3541415b9e7269aa5d1
2020-05-16A-bis: fix logging level mismatch in abis_nm_rcvmsg_fom()Vadim Yanitskiy1-2/+2
Change-Id: If8f76af4d1e0eb2d7b3534e620e2816cdbbe0b7d
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 15:43:44 +0000