path: root/src/libbsc/bsc_vty.c
AgeCommit message (Collapse)AuthorFilesLines
2018-03-07implement support for 3-digit MNC with leading zerosNeels Hofmeyr1-7/+21
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout the code base to be able to handle an MNC < 100 that has three digits (leading zeros). The changes to abis_test and gsm0408_test show that this code now handles 3-digit MNC correctly, by not dropping the leading zero as 0xf in the encoded PLMN. Re-implement CTRL commands 'mcc', 'mnc' and 'mcc-mnc-apply' to preserve the presence of the third digit of the MNC. Always reply with all leading zeros. Adjust the expected results in ctrl_test_runner.py, to show that it works. In VTY and CTRL, the parsing of MCC and MNC is inherently made stricter by use of osmo_{mcc,mnc}_from_str() -- they will no longer allow surplus characters and detect errno returned by strtol() (in contrast to atoi()). Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore), Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore), I020a4f11791c61742a3d795f782805f7b7e8733e (libosmocore) Change-Id: I8e722103344186fde118b26d8353db95a4581daa
2018-03-06libbsc/bsc_vty.c: prevent uninitialized accessVadim Yanitskiy1-0/+3
If an out of range 'Last Valid Block' value for 'smscb-command' is passed, a 'last_block' of the 'rsl_ie_cb_cmd_type' struct could be uninitialized. Let's prevent this. Found using Clang Static Analyzer. Change-Id: I57635f2f482ff476ab697b1b9e872ce90aafb999
2018-03-04bsc_vty: Merge more VTY documentation string #definesHarald Welte1-10/+14
Change-Id: I3fcbcd319813e3b220daf8170cadd4ebb2aefa0f
2018-02-28Align syntax of "handover" + "assignment" command with that of lchan act/deactHarald Welte1-7/+9
We already have other commands that operate on a given bts/trx/ts/ss, let's make sure they have a shared/common syntax for consistency. This also fixes the issue that the handover/assignment commands were active already in VIEW_NODE, while they should only have been in ENABLE_NODE. Change-Id: I1f31e9adf9c75348809ebf9f40f6c69fab248e43
2018-02-27Add support for Access Control Class ramping.Stefan Sperling1-0/+113
Access Control Class (ACC) ramping is used to slowly make the cell available to an increasing number of MS. This avoids overload at startup time in cases where a lot of MS would discover the new cell and try to connect to it all at once. Ramping behaviour can be configured with new VTY commands: [no] access-control-class-ramping access-control-class-ramping-step-interval (<30-600>|dynamic) access-control-class-ramping-step-size (<1-10>) (The minimum and maximum values for these parameters are hard-coded, but could be changed if they are found to be inadequate.) The VTY command 'show bts' has been extended to display the current ACC ramping configuration. By default, ACC ramping is disabled. When enabled, the default behaviour is to enable one ACC per ramping step with a 'dynamic' step interval. This means the ramping interval (time between steps) is scaled to the channel load average of the BTS, i.e. the number of used vs. available channels measured over a certain amount of time. Below is an example of debug log output with ACC ramping enabled, while many 'mobile' programs are concurrently trying to connect to the network via an osmo-bts-virtual BTS. Initially, all ACCs are barred, and then only one class is allowed. Then the current BTS channel load average is consulted for scheduling the next ramping step. While the channel load average is low, ramping proceeds faster, and while it is is high, ramping proceeds slower: (bts=0) ACC RAMP: barring Access Control Class 0 (bts=0) ACC RAMP: barring Access Control Class 1 (bts=0) ACC RAMP: barring Access Control Class 2 (bts=0) ACC RAMP: barring Access Control Class 3 (bts=0) ACC RAMP: barring Access Control Class 4 (bts=0) ACC RAMP: barring Access Control Class 5 (bts=0) ACC RAMP: barring Access Control Class 6 (bts=0) ACC RAMP: barring Access Control Class 7 (bts=0) ACC RAMP: barring Access Control Class 8 (bts=0) ACC RAMP: barring Access Control Class 9 (bts=0) ACC RAMP: allowing Access Control Class 0 (bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average (bts=0) ACC RAMP: allowing Access Control Class 1 (bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average (bts=0) ACC RAMP: allowing Access Control Class 2 (bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average (bts=0) ACC RAMP: allowing Access Control Class 3 (bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average Change-Id: I0a5ac3a08f992f326435944f17e0a9171911afb0 Related: OS#2591
2018-02-19HO: introduce ho decision callbacksNeels Hofmeyr1-1/+1
Instead of reacting on S_LCHAN* signals in the handover decision code, introduce callbacks for the handover decision to be invoked by handover_logic.c at the appropriate time. The rationale is explained in a comment to struct handover_decision_callbacks, quoting: " All events that are interesting for handover decision are actually communicated by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate those. However, handover_logic.c cleans up handover operation state upon receiving some of these signals. To allow a handover decision algorithm to take advantage of e.g. the struct bsc_handover before it is discarded, the handover decision event handler needs to be invoked before handover_logic.c discards the state. For example, if the handover decision wants to place a penalty timer upon a handover failure, it still needs to know which target cell the handover failed for; handover_logic.c erases that knowledge on handover failure, since it needs to clean up the lchan's handover state. The most explicit and safest way to ensure the correct order of event handling is to invoke the handover decision algorithm's actions from handover_logic.c itself, before cleaning up. This struct provides the callback functions for this purpose. For consistency, also handle signals in this way that aren't actually in danger of interference from handover_logic.c (which also saves repeated lookup of handover state for lchans). Thus, handover decision algorithms should not register any signal handler at all. " Also: - Publish struct bsc_handover to use it as argument to above callbacks. - Add enum hodec_id to struct bsc_handover, to be able to signal the appropriate hodec algorithm per event. - Add hodec_id argument to bsc_handover_start*() to be placed in the bsc_handover struct. - Publish the LOGPHO logging macros in handover.h along with struct bsc_handover, convenient for logging in callback implementations. Replace handover_decision.c's signal handler with a registered handover_decision_callbacks instance. (Upcoming handover_decision_2 will use all of the callbacks introduced here.) Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
2018-02-19Permit set of multiple different A5 ciphersHarald Welte1-10/+26
So far, the administrator had to pick one particular cipher which would then be used throughout all subscribers/phones. This is a bit impractical, as e.g. not all phones support A5/3. Extend the VTY command syntax in a backwards-compatible way to permit for multiple ciphers. The bit-mask of permitted ciphers from the MSC (sent in ASSIGNMENT COMMAND) is intersected with the vty-configured mask a the BSC. Finally, the best (highest) possible cipher is chosen. Change-Id: I1d1c8131855bcab2392b4f27f6216bdb2fae10e0 Closes: OS#2461
2018-02-16vty: 'show bts': print neighbor cellsNeels Hofmeyr1-0/+38
Print out the current neighbor cell list, works both for manual and automatically populated modes. Examples of output for various configs: Neighbor Cells: Automatic, ARFCNs: (none) Neighbor Cells: Automatic, ARFCNs: 868 (1) Neighbor Cells: Manual, ARFCNs: 123 125 (2) Neighbor Cells: Manual/separate SI5, ARFCNs: 123 125 (2) SI5: 321 (1) Change-Id: I57dae0e01b81a6f028b39f3edcaf430251ca8fe2
2018-02-16vty: 'show bts': list the TRXs' ARFCNsNeels Hofmeyr1-0/+33
Change-Id: I56ee2edc7473dc5e9f3c3463194369024cd64995
2018-02-16HO: cfg: tweak vty writeNeels Hofmeyr1-2/+2
Have expicitly named vty write functions for bts and net levels, so that it is trivial to add commands that exist only on one of each (like the upcoming congestion check timer config for hodec2). Change-Id: Ibea4c20abc50c3d655f6bbb1a643477dfc722c8e
2018-02-16HO: add new_lchan_type arg to bsc_handover_start()Neels Hofmeyr1-1/+1
Upcoming handover_decision_2 will want to be able to handover to a differing TCH type, hence add a parameter to bsc_handover_start(); adjust current callers to pass the old lchan type. Tweak the 'bts' argument to 'new_bts'. Change-Id: I4478ebcaada00897cc38c5a299e07661139ed3c5
2018-02-15vty: 'show bts': fix indentingNeels Hofmeyr1-19/+19
Add two-space indent to many items. Change-Id: I34e3c8928871fc41b9551ab0502a42140ccbdda8
2018-02-15vty: 'show bts': write '(none)' if none are found.Neels Hofmeyr1-0/+4
Change-Id: I77039824b85a14b9d7bdfe6d2f717679b6886915
2018-02-14drop libcommon-cs completelyNeels Hofmeyr1-1/+0
Change-Id: I07d4a48af3154ee4d904686f230a51b8b8a94ff9
2018-02-14libcommon-cs: move vty bits to libbsc/bsc_vty.cNeels Hofmeyr1-1/+197
The gsm_network VTY was partly shared between libmsc and libbsc in the old openbsc.git; now osmo-bsc.git has its own copy, so merge all of it into bsc_vty.c. This leaves common_cs_vty.c practically empty; leave removal of the file to later, when we drop the entire libcommon-cs in I07d4a48af3154ee4d904686f230a51b8b8a94ff9. Note that gsmnet_from_vty() is also already declared in bsc/vty.h. Change-Id: I6f3a596f31762b48afed39a85a343c400826300f
2018-02-14osmo-bsc: Add talloc context introspection via VTYHarald Welte1-0/+1
This requires libosmocore with Change-Id I43fc42880b22294d83c565ae600ac65e4f38b30d or later. Change-Id: I1245b6818eb54f5c0c8adddcd3a01ecc7363fb42
2018-02-05vty: print RTP IP of lchan if actually bound; print remote (mgw) IPHarald Welte1-5/+15
Change-Id: I87840aa0f5b9c04d7736bf5f649142219853711a
2018-02-05Make "waiting indicator" of IMMEDIATE ASSIGN REJECT dynamic.Stefan Sperling1-1/+1
The IMMEDIATE ASSIGN REJECT message contains a wait indicator which tells an MS requesting a channel to wait for a specified amount of time before trying to request a channel again, i.e. the wait indicator controls the T3122 timeout value in the MS. Previously, the wait indicator was fixed to 10 seconds. This is not sufficient if there are a lot of MS requesting channels because the MS will retry too soon. Instead of using a fixed value, maintain a dynamic wait indicator value based on average channel load. The load (used vs. available channels on a BTS) is sampled once per second, and once 8 samples have been collected we update a BTS-specific T3122 wait indicator based on the measured load. While the wait indicator could go up to 255 seconds, this initial implementation keeps it in the range from 10 to 128 seconds. Further experimentation and testing will show whether higher wait indicator values are desirable, if the sampling rate needs to change, or if the function mapping the load measurement to a wait indicator value should change (currently we map the load average linearly into the range [10, 128] inclusive). Change-Id: I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec Related: OS#2592
2018-01-19HO prep: introduce per-BTS handover config, with defaults on net nodeNeels Hofmeyr1-116/+32
It is desirable to allow configuring handover for each individual network cell. At the same time, it is desirable to set global defaults. Treat the 'network' node handover parameters as global defaults, add another set of parameters for each individual BTS. This raises questions on how the 'network' node should affect the individual BTS. The simplistic solution would have been: on creating a BTS in the config, just copy the current defaults; with serious drawbacks: - tweaking any parameter in the telnet VTY on network node will never affect any running BTS. - network node defaults *must* be issued before the bts sections in the config file. - when writing a config back to file, we would copy all net node defaults to each BTS node, making the network node configs pointless. Instead, add a handover_cfg API that tracks whether a given node has a value set or not. A bts node ho_cfg gets a pointer to the network node config and returns those values if locally unset. If no value is set on any node, use the "factory" defaults, which are hardcoded in the API. Only write back exactly those config items that were actually issued in a config file / on the telnet VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if we so desire in the future.) Implement ho parameters as an opaque config struct with getters and setters to ensure the tracking is always heeded. Opaqueness dictates allocating instead of direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts. This is 100% backwards compatible to old configs. - No VTY command syntax changes (only the online help). - If a 'bts' sets nothing, it will use the 'network' defaults. - The 'show network' output only changes in presence of individual BTS configs. On 'show network', say "Handover: On|Off" as before, iff all BTS reflect identical behavior. Otherwise, output BTS counts of handover being enabled or not. Use the same set of VTY commands (same VTY cmd syntax as before) on network and BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure out which ho_cfg to modify. For linking, add handover_cfg.c (the value API) in libcommon, while the handover_vty.c is in libbsc. This is mainly because some utility programs use gsm_network and hence suck in the ho stuff, but don't need the VTY commands. Review the VTY online help strings. Add VTY transcript test for handover options, testing config propagation from network to bts nodes, 'show network' output and VTY online help strings. (Needs recent addition of '... !' wildcard to osmo_interact_common.py.) I considered leaving parts of this more readable, but in the end decided for heavy use of macros to define and declare the API, because more values will be added in upcoming patches and I want to prevent myself from messing them up. Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests) Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
2018-01-19vty: add various manual handover and assignment trigger commandsNeels Hofmeyr1-25/+192
Change-Id: I9745609f2620baa09a693b713d76e355e798abc7
2018-01-19vty: cosmetic: use common BTS, TRX, TS, LCHAN stringsNeels Hofmeyr1-26/+27
Change-Id: Ic015ebd3a330769638dddeab2f52321b0302a5a1
2018-01-19vty: change handover command's arg LCHAN_NR to <0-7>Neels Hofmeyr1-1/+1
Even thought the lchan number range depends on the pchan, using LCHAN_NR allows passing arbitrary arguments. Limit it to 0-7. Change-Id: I2c078b420b6183862acb5c18d1230cf8f6c9f0ce
2018-01-19vty: fix 'show lchan ...' arg [lchan_nr] to [<0-7>]Neels Hofmeyr1-2/+2
A lower-case argument is a keyword, not a variable placeholder. Hence the user would not be able to pass a number, just the "lchan_nr" string itself, hence this would never work. Depending on pchan, lchans can range 0..7, so use that instead. Change-Id: Ib9a0b43b68c4682cd6de24d01c0de421c9ce957a
2018-01-08vty: fix OML link state printingMax1-3/+3
Always print newline regardless of BTS uptime availability. Change-Id: Ib80049fe66de17bc7acfbb774a30075f40a44dee
2018-01-08RSL: print link state per-TRXMax1-0/+1
Change-Id: Ie6fad70b4b11d0bb4927b22e32e842422658ba53 Fixes: OS#2715
2018-01-08cosmetic: remove duplicated codeMax1-14/+11
Change-Id: I16c446ef7dc66769826f6e8ae118d8b07bbf6930
2017-12-23cosmetic: Hide all accesses to conn->bts behind conn_get_bts()Harald Welte1-1/+1
This is a new inline function that hides all accesses to conn->bts. A follow-up patch will then point this to conn->lchan->ts->trx->bts to get rid of the bts field. Change-Id: Ib6cf7097ced34eebe80441c29ab1534f21956a33
2017-12-19Remove bogus MM INFO configurationHarald Welte1-9/+0
The network name and other MM INFO is controlled by the MSC, not the BSC. Change-Id: I1cbf72fc50cff29e7c1633ba752cbf15b4b84c58
2017-12-19Remove bogus vty config for LU reject causeHarald Welte1-4/+0
The LU reject cause (like anything MM related) is under control of OsmoMSC, not BSC. Change-Id: I559ae31d67726845c9699c8b6127e21c6f63ace6
2017-12-19Remove unused RRLP options/codecHarald Welte1-4/+0
RRLP is handled in OsmoMSC after the split from NITB, so let's remove any bogus VTY commands left over in the BSC. Change-Id: Ib626f43a3a3ca69dfc127afe5832eb58f7fb6a38
2017-12-14libbsc: paging: more reasonable (and detailed) paging statisticsHarald Welte1-3/+2
Counting the number of T3113 expirations (one per subscriber per BTS) vs the number of paging attempts (Bsc global) is a ueseless figure, as you cannot relate each other. We count on the BSC level: * how many PAGING we received from the MSC (total) * how many of those were for cells/LACs we don't serve * how many of those resulted in PAGING RESPONSE We count on the BTS leve: * how many PAGING CMD we sent to the BTS (total) * how many of those we ignored as we were already paging * how many of those resulted in PAGING RESPONSE * how many were expired due to T3113 expiring Change-Id: I410bbcbb2621f95f11238f7a5da01ab438f5fee1
2017-12-09Move many counters from BSC-global to per-BTS granularityHarald Welte1-12/+13
We used to have a lot of counters only globlly per BSC, but they're much more useful on a per-BTS level. Change-Id: I954b9dda72b83b91d46a934c221a8b3375743599
2017-11-30auth: remove obsolete VTY commandsPhilipp Maier1-3/+0
authentication (optional|required) is no longer needed, the related decisions are now made in the HLR. Change-Id: Ib6c6331cc86004c4862067031e4fcb12a6975b63
2017-11-29cosmetic: bsc_vty: Document bvci reserved valuesPau Espin Pedrol1-0/+1
Change-Id: I7a4374c3619cb83ef8beef594281f887d9fbf70a
2017-11-29cosmetic: bsc_vty: Fix trailing whitespacePau Espin Pedrol1-2/+2
Change-Id: I7089062285c40ec11af479c98b43d1d407397c82
2017-11-29auth: remove obsolete VTY commandsPhilipp Maier1-7/+0
Authentication is no longer done in the BSC, the variables that set the authentication policy and the IMSI regex have no longer any effect. Remove auth policy and authorized-regexp Change-Id: Ie31b921b5fd0af5501ec0c77c0f08089c10075e2
2017-11-24vty: Add cmd to configure 3g Early Classmark SendingPau Espin Pedrol1-1/+23
In state prior to this patch, "3G Early Classmark Sending Restriction" bit in SI3 rest octets was always set to H, which is a sane default as the policy to send the information is then controlled by "Early Classmark Sending Control" bit in the same octet. However, it seems Quortus SoftCore can have some issues decoding the option, so let's add a vty cmd to be able to disable it for those having any issues. Related: SYS#4021 Change-Id: Ic1afe071038a3bb5871d7ff40f665c8644f801ec
2017-11-01vty: skip installing cmds now always installed by defaultNeels Hofmeyr1-3/+0
vty_install_default() and install_default() will soon be deprecated. Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b Change-Id: If2edf59a687a78d6db6bc73117a27509374b0fc6
2017-10-23libbsc: Use correct printf formatting for uint64_tPau Espin Pedrol1-4/+4
unsigned long can be 32 bits on some arch/OS, while "current" field is always 64 bit because it's a uint64_t. Change-Id: Ibad1e4f09cf912cb654dbe3687a3f2182e2060f5
2017-10-11ctrl: add oml-uptime commandMax1-13/+5
Expose OML link uptime available via vts's "sh bts 0" command with the new "bts.0.oml-uptime" ctrl command. To avoid code duplication, move uptime computation into separate function and use it for both. Change-Id: Iec405aa949d6a38a9c8e64cd7ee4b49fd416835d Related: OS#2486
2017-10-09OML: consider RSL link stateMax1-4/+2
OML link state is available via vty ("sh bts 0" command) and ctrl ("oml-connection-state" RO variable). When showing OML link state, take into consideration RSL link state as well: if OML is up but RSL is missing show it as degraded. That's implemented via BTS model-specific functions (currently Sysmo- and Nano- BTS only) Change-Id: I5952fc59e4d82e0aa627ad91d20f964d9559a4c4 Related: OS#2486
2017-09-27Show OML link uptime in vtyMax1-2/+18
Save the time when OML link to BTS was established and show it in vty. That's useful when troubleshooting issues like periodic/sporadic BTS restart. Related: SYS#3889 Change-Id: I9e4e8504afe8ca467b68d41826f61654e24d9600
2017-09-08Make TRX rf locking more visibleMax1-1/+1
* log administrative state transitions * log what's caused it * while at it, mark boolean variable as such Change-Id: I3e25a19fac4d0b4886d825c9876771b1f66efe58 Related: SYS#3864
2017-09-06move include/openbsc to include/osmocom/bscNeels Hofmeyr1-17/+17
Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-08-30split off osmo-bsc: remove files, apply buildNeels Hofmeyr1-24/+4
Change-Id: I64d84c52f6e38e98144eb9be8f0ab82e0e1f6cca
2017-08-30Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring)Philipp Maier1-0/+81
This was originally a long series of commits converging to the final result seen in this patch. It does not make much sense to review the smaller steps' trial and error, we need to review this entire change as a whole. Implement AoIP in osmo-msc and osmo-bsc. Change over to the new libosmo-sigtran API with support for proper SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and IuPS interfaces. From here on, a separate osmo-stp process is required for SCCP routing between OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new M3UA SIGTRAN. Patch-by: pmaier, nhofmeyr, laforge Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-08-27timer vty: also print the default value in cmd docNeels Hofmeyr1-13/+13
Rationale: allows seeing all timer defaults at once by doing OsmoBSC(config-net)# timer ? Before, defaults are visible only by doing on each timer: OsmoBSC(config-net)# timer t1234 <tab> Change-Id: I8259234e5c62e058dde56d531071440bbab11462
2017-08-27vty: add 'default' keyword to timer configNeels Hofmeyr1-3/+14
Change-Id: I4e837e8bedfad7ac4fd50048ecb016ddb37c2397
2017-08-27cosmetic: vty for timers: remove obsolete range checkNeels Hofmeyr1-6/+0
The VTY parsing already ensures the parameter range being 1..65535, no need to check the range again. Change-Id: I1cffa5b01cd5c589f1e42998e32135f1da8c960b
2017-08-27bsc_vty: Don't allow timers of zero (0)Harald Welte1-2/+2
It typically doesn't make sense to configure any of the GSM RR timer to 0 (Seconds). In fact, accidentially configuring any of the timers to zero might have severe side effects, such as "stuck channels" described in https://osmocom.org/issues/2380 Change-Id: I517828f2f0c80ec01cb63648db2626f17a67fe57