Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: I316efedb2c1652791434ecf14a1e261367cd2fb7
This adds the assignment counters for the BTS as well and changes the
assignment_count() macro to increase both the counters for the BSC as
well as the BTS.
Related: SYS#4877
Change-Id: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Prepare for MSC pooling by NRI. Before introducing actual NRI decoding and MSC
matching, fix the bsc_find_msc() implementation.
(Indicate the places relevant for NRI by "TODO" comments).
bsc_find_msc() puts an MSC to the end of the internal list of MSCs when it was
used. This has problems:
- Modifying the list affects VTY output, e.g. 'show running-config' and
'show mscs' change their order in which MSCs are shown, depending on how
often a round-robin selection has taken place.
- Emergency calls and normal calls potentially pick quite different sets of
eligible MSCs. When the round-robin choices between these sets affect each
other, the choice is not balanced. For example, if only the first MSC is
allow_emerg == true, every emergency call would reset the round-robin state
to the first MSC in the list, also for normal calls. If there are regular
emergency calls, normal calls will then tend to load more onto the first few
MSCs after those picked for emergency calls.
Fix: Never affect the ordering of MSCs in the internal list of MSCs. Instead,
keep a "next_nr" MSC index and determine the next round-robin target like that.
Keep a separate "next_emerg_nr" MSC index so that emergency call round-robin
does no longer cause normal round-robin to skip MSCs.
Further problems in current bsc_find_msc():
- The "blind:" label should also do round-robin.
- The "paging:" part should not attempt to use disconnected MSCs.
- Both should also heed NRI matches (when they are added).
Fix: instead of code dup, determine Paging Response matching with an earlier
Paging Request right at the start. If that yields no usable MSC, continue into
the normal NRI and round-robin selection.
The loop in this patch is inspired by the upcoming implementation of MSC
pooling by NRI, as indicated by the two TODO comments. The point is that, in
the presence of an NRI from a TMSI identity, we always need to iterate all of
the MSCs to find possible NRI matches. The two round-robin sets (Emergency and
non-Emergency) are determined in the same loop iteration for cases that have no
or match no NRI, or where a matching MSC is currently disconnected.
Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
Testing these functions is actually done in libosmocore. Also, with new
osmo_mobile_identity API, the functions being tested are marked deprecated. So
drop the test.
BTW, the test contained an IMSI of 16 digits, which is too long, yet was
expected to succeed. GSM23003_IMSI_MAX_DIGITS == 15. I first considered fixing
the test data, but the test is in the wrong place here anyway.
Change-Id: I902d31ecd72d71892fad7945f695a9f1fb403bf2
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
This is unlikely to cause any problems, but having a NULL-pointer
that can potentially be dereferenced is dangerous. Fix this.
Change-Id: Icf594604f69023d1483e897edb811e51774b5b8e
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
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
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
Tweak return code handling: also return a failure code when dispatching the
GSCON_EV_A_CONN_REQ event failed.
Change-Id: I939e8a9a865250033e4837439a6b9ec251e5ce4c
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
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
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
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
Remove OpenSUSE bug report link, set version to @VERSION@, make it build with
CentOS 8 etc.
Related: OS#4550
Change-Id: I4b87cb0d80bda7bbfda600310aee24a814f97f3f
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
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 39c609b7c9
Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a
Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
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
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
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
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
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
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
The "new SIGTRAN connection" message is sent on every new transaction
between an MS and MSC, i.e. A LOT during normal operation. Let's
demote it to INFO and clarify that this is about SCCP connection
instead of a generic SIGTRAN term.
Change-Id: I711b70ae84aa98f43ea3f807ea5c8464b71ca6bb
"Paging request failed" message can be logged e.g. when we're already
paging this subscriber which means we get hundreds of these messages
in a perfectly normal situation. Let's demote this to INFO and adjust
the wording.
Change-Id: I97214796906ac599338e87b2b4b5465ab6b2447a
Neels Hofmeyr
Daniel Willmann
Vadim Yanitskiy
Oliver Smith