summaryrefslogtreecommitdiffstats
path: root/src/vty
Commit message (Collapse)AuthorAgeFilesLines
* MAXPATHLEN set if not definedRuben Undheim2019-09-022-0/+10
| | | | Change-Id: I1dce8ace228814b5a7246a00b31309ab9461d266
* fix: vty crash by logging during VTY_CLOSED event handlingNeels Hofmeyr2019-08-301-3/+3
| | | | | | | | | | | | | | | | | | | | When a VTY closes, dispatch the VTY_CLOSED signal before tearing down the VTY buffer and fd. In particular this fixes: - a crash during telnet_close_client(), invoked by the VTY_CLOSED event, which logs to DLGLOBAL and uses vty->obuf that, so far, vty_close() had already unallocated earlier (OS#4164). - the logging about closing a telnet session so far logged: DLGLOBAL INFO Closing telnet connection r=NULL<->l=NULL By dispatching the VTY_CLOSED event while the fd is still valid, we instead get the actual connection IP address and port being closed: DLGLOBAL INFO Closing telnet connection r=127.0.0.1:36708<->l=127.0.0.1:4258 Related: OS#4164 Change-Id: I1d235cbfbfb9aaf411316642c7bcfac12106df44
* vty: Register logp cmd next to logging commandsPau Espin Pedrol2019-08-201-2/+3
| | | | | | | | This way it's easier by osmo_verify_transcript_vty.py to skip and avoid breaking existent test in osmo-hlr. Fixes: d0b3b9edac978c91bf84aa2537aa24426685b1fb Change-Id: Iab9423661e4f4eefca2e3d02b60a43f913ed92a3
* add vty logp command to echo on all log targetsNeels Hofmeyr2019-08-131-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | When reading SUT logs resulting from TTCN3 runs, it can be hard to figure out which log section corresponds to which test code. Add a 'logp' command on VIEW and ENABLE nodes that simply echos an arbitrary message on log output, useful to set markers / explanations from the TTCN3 code, which then appear in all log outputs and can make it trivial to figure out which log section is interesting. logging_vty_test# logp lglobal notice This is the log message DLGLOBAL NOTICE This is the log message From TTCN3, could be used like this, e.g. in BSC_Tests.ttcn: private function f_logp(charstring log_msg) runs on MSC_ConnHdlr { // log on TTCN3 log output log(log_msg); // log in stderr log f_vty_transceive(BSCVTY, "logp lglobal notice " & log_msg); } ... f_logp("f_probe_for_handover(" & log_label & "): Ending the test: Handover Failure stops the procedure."); Change-Id: Ife5dc8999174c74e0d133729284fe526d6eaf8d9
* Bump version: 1.1.0.107-afce-dirty → 1.2.0Pau Espin Pedrol2019-08-061-1/+1
| | | | Change-Id: I05dd1f2725e05f856f1d27c9201a0005de101b8f
* Get rid of osmo_str_tolower() use inside libosmocore codePau Espin Pedrol2019-08-021-11/+13
| | | | | | | | | | | There's no real good reason for using that function (static buffer) instead of osmo_str_tolower_buf(local buffer), so let's use the later. In any case, we get rid of TLS variables in those places, which is a performance improvement. It will also allow later shrinking of those buffers if we decide to define maximum logging category and level name length. Change-Id: I2e99de1142020e4d80ef0a094e4e751f7903f5f9
* vty/vty.c: the command buffer can be accessed directlyVadim Yanitskiy2019-07-301-7/+7
| | | | Change-Id: Ic6d7d68e9a559a6fb5bd6eaf6eccceae51e7ed39
* vty/vty.c: fix vty_read(): prevent further heap-buffer overrunVadim Yanitskiy2019-07-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After reading data from the socket, assigned to a given VTY, we need to '\0'-terminate the received string. Otherwise, further access to that string, stored in a heap buffer vty->buf, would lead to a heap overrun. == How to reproduce? $ python -c "print 'A' * 512" | telnet $HOST $PORT ==21264==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6190000211e0 at pc 0x000000435d2f bp 0x7ffc06c7add0 sp 0x7ffc06c7a578 READ of size 1025 at 0x6190000211e0 thread T0 #0 0x435d2e in __interceptor_strlen (/usr/local/bin/osmo-msc+0x435d2e) #1 0x7fb95bfa5624 in talloc_strdup (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6624) #2 0x7fb95c1be2bc in vty_hist_add /opt/osmocom/libosmocore/src/vty/vty.c:578 #3 0x7fb95c1be2bc in vty_execute /opt/osmocom/libosmocore/src/vty/vty.c:703 #4 0x7fb95c1be2bc in vty_read /opt/osmocom/libosmocore/src/vty/vty.c:1425 #5 0x7fb95c1bfd78 in client_data /opt/osmocom/libosmocore/src/vty/telnet_interface.c:157 #6 0x7fb95b90bd33 in osmo_fd_disp_fds /opt/osmocom/libosmocore/src/select.c:223 #7 0x7fb95b90bd33 in osmo_select_main /opt/osmocom/libosmocore/src/select.c:263 #8 0x5006cc in main /opt/osmocom/osmo-msc/src/osmo-msc/msc_main.c:723:3 #9 0x7fb959935f44 in __libc_start_main /build/eglibc-xkFqqE/eglibc-2.19/csu/libc-start.c:287 #10 0x4226fb in _start (/usr/local/bin/osmo-msc+0x4226fb) == Why exactly 512? Because the initial size of the heap buffer is 512 (see VTY_BUFSIZ). Later on it can be realloc()ated, so X > 512 should also work. Found using AddressSanitizer and Radamsa [1] fuzzer. [1] https://gitlab.com/akihe/radamsa Change-Id: I82f774ad18d0e555eb8f3590a519946d9c583c78
* vty/telnet_interface.c: log connection accept() / close() eventsVadim Yanitskiy2019-07-301-0/+12
| | | | | | | | | | | | | | Unfortunately, osmo_sock_get_name_buf() fails in telnet_close_client(): DLGLOBAL INFO telnet_interface.c:130 Closing telnet connection <error-in-getsockname> because getsockname(), getpeername(), and even close() fail with: "Bad file descriptor". This looks like a bug of the existing code. Change-Id: I77b31abfa159d2f269deaa5a08d94b7bbba7d23c
* vty/logging_vty.c: fix writing of 'print category-hex'Vadim Yanitskiy2019-07-301-0/+2
| | | | Change-Id: I33837f0fac1afe83596fa600916abc05ecb8c356
* vty/telnet_interface.c: avoid unneeded initializationVadim Yanitskiy2019-07-271-1/+1
| | | | | | | | Unconditional initialization follows the structure definition, so there is no need to do it twice. This prevents compiler from warning about potential errors. Change-Id: If9fd2826f132dfa203dda62940d93dbdfcfd92ac
* vty/telnet_interface.c: use DLGLOBAL logging sub-systemVadim Yanitskiy2019-07-271-2/+2
| | | | Change-Id: I1564f4714a33d36792e4982deb8f19d1b740dc0c
* stats_vty: Add verb to sentence for show asciidoc countersDaniel Willmann2019-07-251-1/+1
| | | | Change-Id: Ib444383d2074ddb89b3fe5bbf198bcbfabd7057f
* vty: Simplify char escaping in asciidoc outputPau Espin Pedrol2019-06-251-9/+4
| | | | Change-Id: I7df6858bb98abffc1d5bf420f991ae5854b24638
* vty: Remove trailing whitespace in output from show asciidocPau Espin Pedrol2019-06-191-2/+2
| | | | Change-Id: Ifb3115c7488fbcf082cc9b92abc25cf7c46064e0
* vty: command.c: Fix: single-choice optional args are no longer passed ↵Pau Espin Pedrol2019-06-141-5/+14
| | | | | | | | | | | incomplete to vty func For instance, take command "single0 [one]": If user executes "single0 on", VTY func will receive argv[0]="one" instead of argv[0]="on". Related: OS#4045 Change-Id: I5f4e2d16c62a2d22717989c6acc77450957168cb
* vty: command.c: Fix: multi-choice args are no longer passed incomplete to ↵Pau Espin Pedrol2019-06-141-7/+44
| | | | | | | | | | | vty func For instance, take command "multi0 (one|two|three)": If user executes "multi0 tw", VTY func will receive argv[0]="two" instead of argv[0]="tw". Fixes: OS#4045 Change-Id: I91b6621ac3d87fda5412a9b415e7bfb4736c8a9a
* vty: command.c: Get rid of big indentation blockPau Espin Pedrol2019-06-141-30/+30
| | | | | | This block will become bigger in forthcoming commits. Change-Id: Ibc1494014b1e77ce10950f7268a44d2d2091a6f2
* command.c: Improve return check condition in cmd_execut_command_real()Pau Espin Pedrol2019-06-141-2/+2
| | | | | | | Check against MAX argc is changed to == since it cannot be incremented twice without passing the check. Change-Id: Ia330e475989fda863bedcc3cbf94deaf8dd83037
* vty: command.c: Get rid of huge indentation blockPau Espin Pedrol2019-06-121-91/+94
| | | | | | | | Huge conditional block inside for loop is negated in this patch together with a "continue" keyword, similar to what was already done recently in 4742526645d6137dd90ef369f0415afdb91736dc. Change-Id: I803c4ed38e9ab09bf929528c75a60e6f65da3928
* cosmetic: vty: command.c: Use upper case for enum match_type value namesPau Espin Pedrol2019-06-121-101/+101
| | | | | | | Makes code easier to follow because enum values no longer look like variables. Change-Id: Ib6e9592c5962d047869a280c10f9b557fae6f435
* vty: command.c: Fix is_cmd_ambiguous() returning always 0Pau Espin Pedrol2019-06-111-5/+5
| | | | | | | | | | inner block defined variable "enum match_type ret" was being masking outter block variable "int ret = 0". The ret variable was being given non zero values only inside the inner block, so that change was done on the inner variable and not the outer one, which is returned. Fixes: 5314c513f23688462d7f7937e5ae5e0d5cd4548e Change-Id: Iec87d7db49a096d07e38ff8a060b923a52bfd6ba
* vty: command.c: Get rid of huge indentation blockPau Espin Pedrol2019-06-111-84/+87
| | | | | | | Huge conditional block inside foor loop is negated in this patch together with a "continue" keyword. Change-Id: I9715734ed276f002fdc8c3b9742531ad36b2ef9e
* vty/command.c: cosmetic: add missing curly bracketsVadim Yanitskiy2019-06-011-2/+4
| | | | | | Otherwise it's a bit hard to read the code. Change-Id: I807ec71cfb67976251be844cdb2d2776b1837438
* tdef: Fix license: GPLv2+ instead of AGPLv3+Harald Welte2019-05-271-4/+5
| | | | | | | | | | | | libosmo{core,gsm,vty} code is GPLv2+. The tdef code originated in osmo-msc.git and was moved here without changing the license. That was a mistake, it always was meant to be under GPLv2-or-later after moving to libosmocore.git. Copyright is with sysmocom, so I as the managing director can approve the license change. Change-Id: Ie483ff6f6ea0a56c477649677b4b163c49df11d7
* Bump version: 1.0.1.143-cc72c → 1.1.0Pau Espin Pedrol2019-05-071-1/+1
| | | | Change-Id: I351411ca5913c8b40f23287ec7c9ebfe11bd2bb0
* add vty_is_active()Neels Hofmeyr2019-05-031-0/+10
| | | | | | | | | | | | | For async callbacks it is useful to determine whether a given VTY pointer is still valid. For example, in osmo-msc, a silent call can be triggered by VTY, which causes a Paging. The paging_cb then writes to the VTY console that the silent call has succeeded. Unless the telnet vty session has already ended, in which case osmo-msc crashes; e.g. from an osmo_interact_vty.py command invocation. With this function, osmo-msc can ask whether the vty pointer passed to the paging callback is still active, and skip vty_out() if not. Change-Id: I42cf2af47283dd42c101faae0fac293c3a68d599
* add osmo_str_startswith()Neels Hofmeyr2019-04-111-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move from a static implementation in tdef_vty.c to utils.c, I also want to use this in osmo-msc. The point is that the telnet VTY allows unambiguous partly matches of keyword args. For example, if I have a command definition of: compare (apples|oranges) then it is perfectly legal as for the vty parser to write only compare app One could expect the VTY to then pass the unambiguous match of "apples" to the parsing function, but that is not the case. Hence a VTY function implementation is faced with parsing a keyword of "app" instead of the expected "apples". This is actually a very widespread bug in our VTY implementations, which assume that exactly one full keyword will always be found. I am now writing new commands in a way that are able to manage only the starts of keywords. Arguably, strstr(a, b) == a does the same thing, but it searches the entire string unnecessarily. Change-Id: Ib2ffb0e9a870dd52e081c7e66d8818057d159513
* vty/talloc_ctx_vty.c: use REG_NOSUB flag of regcomp()Vadim Yanitskiy2019-04-111-1/+1
| | | | | | | We don't need to know position of matches: just yes or no. This change would save some computation power. Change-Id: Id55ffe64cc1a35dd83f61dbb0f9828aa676696f9
* vty/talloc_ctx_vty.c: allocate walk_cb_params on stack, not heapVadim Yanitskiy2019-04-111-43/+15
| | | | | | There is no need to allocate struct 'walk_cb_params' dynamically. Change-Id: I96f25f1ddb36b19b12055deaeeb6f58e59180e72
* select: Rename BSC_FD_* constants to OSMO_FD_*Harald Welte2019-03-211-8/+8
| | | | | | | | | | | | The naming of these constants dates back to when the code was private within OpenBSC. Everything else was renamed (bsc_fd -> osmo_fd) at the time, but somehow the BSC_FD_* defines have been missed at the time. Keep compatibility #defines around, but allow us to migrate the applications to a less confusing naming meanwhile. Change-Id: Ifae33ed61a7cf0ae54ad487399e7dd2489986436
* vty/tdef_vty.c: drop redundant comparisonVadim Yanitskiy2019-03-191-1/+1
| | | | | | | | | | | | | | | The amount of arguments is already being checked a few lines before: /* If any arguments are missing, redirect to 'show' */ if (argc < 3) return show_timer(self, vty, argc, argv); so we cannot reach the expression NULL inside this statement: group_arg = argc > 0 ? argv[0] : NULL; Change-Id: Ice59d1a46c2080cd02060e3410706c502db4ce0b Fixes: CID#190873 Logically dead code (DEADCODE)
* represent negative T-timers as Osmocom-specific X-timersNeels Hofmeyr2019-03-061-9/+22
| | | | | | | | | | | | | | | | | | | | fi->T values are int, i.e. can be negative. Do not log them as unsigned, but define a distinct timer class "Xnnnn" for negative T values: i.e. for T == -1, print "Timeout of X1" instead of "Timeout of T4294967295". The negative T timer number space is useful to distinguish freely invented timers from proper 3GPP defined T numbers. So far I was using numbers like T993210 or T9999 for invented T, but X1, X2 etc. is a better solution. This way we can make sure to not accidentally define an invented timer number that actually collides with a proper 3GPP specified timer number that the author was not aware of at the time of writing. Add OSMO_T_FMT and OSMO_T_FMT_ARGS() macros as standardized timer number print format. Use that in fsm.c, tdef_vty.c, and adjust vty tests accordingly. Mention the two timer classes in various API docs and VTY online-docs. Change-Id: I3a59457623da9309fbbda235fe18fadd1636bff6
* add osmo_tdef API, originally adopted from osmo-bsc T_defNeels Hofmeyr2019-02-042-1/+374
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move T_def from osmo-bsc to libosmocore as osmo_tdef. Adjust naming to be more consistent. Upgrade to first class API: - add timer grouping - add generic vty support - add mising API doc - add C test - add VTY transcript tests, also as examples for using the API From osmo_fsm_inst_state_chg() API doc, cross reference to osmo_tdef API. The root reason for moving to libosmocore is that I want to use the mgw_endpoint_fsm in osmo-msc for inter-MSC handover, and hence want to move the FSM to libosmo-mgcp-client. This FSM uses the T_def from osmo-bsc. Though the mgw_endpoint_fsm's use of T_def is minimal, I intend to use the osmo_tdef API in osmo-msc (and probably elsewhere) as well. libosmocore is the most sensible place for this. osmo_tdef provides: - a list of Tnnnn (GSM) timers with description, unit and default value. - vty UI to allow users to configure non-default timeouts. - API to tie T timers to osmo_fsm states and set them on state transitions. - a few standard units (minute, second, millisecond) as well as a custom unit (which relies on the timer's human readable description to indicate the meaning of the value). - conversion for standard units: for example, some GSM timers are defined in minutes, while our FSM definitions need timeouts in seconds. Conversion is for convenience only and can be easily avoided via the custom unit. By keeping separate osmo_tdef arrays, several groups of timers can be kept separately. The VTY tests in tests/tdef/ showcase different schemes: - tests/vty/tdef_vty_test_config_root.c: Keep several timer definitions in separately named groups: showcase the osmo_tdef_vty_groups*() API. Each timer group exists exactly once. - tests/vty/tdef_vty_test_config_subnode.c: Keep a single list of timers without separate grouping. Put this list on a specific subnode below the CONFIG_NODE. There could be several separate subnodes with timers like this, i.e. continuing from this example, sets timers could be separated by placing timers in specific config subnodes instead of using the global group name. - tests/vty/tdef_vty_test_dynamic.c: Dynamically allocate timer definitions per each new created object. Thus there can be an arbitrary number of independent timer definitions, one per allocated object. T_def was introduced during the recent osmo-bsc refactoring for inter-BSC handover, and has proven useful: - without osmo_tdef, each invocation of osmo_fsm_inst_state_chg() needs to be programmed with the right timeout value, for all code paths that invoke this state change. It is a likely source of errors to get one of them wrong. By defining a T timer exactly for an FSM state, the caller can merely invoke the state change and trust on the original state definition to apply the correct timeout. - it is helpful to have a standardized config file UI to provide user configurable timeouts, instead of inventing new VTY commands for each separate application of T timer numbers. Change-Id: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5
* vty api: add vty_out_va()Neels Hofmeyr2019-02-041-12/+19
| | | | | | | | | Provide a va_list type vty_out() variant, to be able to pass on variable arguments from other function signatures to vty_out(). This will be used by Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 for osmo_tdef. Change-Id: Ie6e6f11a6b794f3cb686350c1ed678e4d5bbbb75
* vty telnet: consistently never change nodes upon CTRL-CNeels Hofmeyr2019-02-041-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove any special node exiting from the VTY CTRL-C handling. From a curious VTY transcript test glitch, I noticed weird behavior by the VTY telnet shell: usually, when the user hits CTRL-C, that means to cancel the current command line and present a fresh, clean prompt. However, only on the CONFIG_NODE and CFG_LOG_NODE, a CTRL-C also exits the current node and moves up by one level. This behavior is unexplainable and makes zero sense. No other nodes exit on CTRL-C: - on the ENABLE node, a CTRL-C stays on the ENABLE_NODE and doesn't exit to the VIEW_NODE. - any sub-nodes of the CONFIG_NODE stay unchanged, e.g. 'network' or 'bts' / 'trx', etc. There is no apparent special meaning of CTRL-C on CONFIG_NODE nor CFG_LOG_NODE to justify this odd choice. Particularly, the vty transcript tests using osmo_verify_transcript_vty.py rely on sending CTRL-C to clear the command prompt, so that we can properly test sending '?' to the VTY during transcripts. In a live session, a '?' prints available options and then updates the prompt with identical command arguments. In a transcript test, that doesn't make sense, because each time the transcript writes out a new command to run. Consider e.g. a transcript test like: tdef_vty_test(config)# timer ? tea Tea time test Test timers software Typical software development cycle tdef_vty_test(config)# timer tea ? [TNNNN] T-number, optionally preceded by 't' or 'T'. To be able to issue a fresh command after '?', osmo_verify_transcript_vty.py explicitly sends a CTRL-C to clear the command buffer. Hence there we rely on predictable behavior of CTRL-C. More particularly, the upcoming osmo_tdef_vty transcript tests are apparently the first that want to test '?' behavior on the CONFIG_NODE's root level and fall on their face, because of the implicit exit that happens only there. Change-Id: I4f339ba61f1c273fa7da85caf77ba116ae2697b1
* vty: enable tab-completion for optional-multi-choice argsNeels Hofmeyr2019-02-041-1/+10
| | | | | | | | | | | | | | In cmd_complete_command_real(), detect and strip square braces from multi-choice arguments, to enable tab-completion for commands like > list cmd [(alpha|beta)] > cmd <TAB> alpha beta > cmd be<TAB> > cmd beta Change-Id: I8c304300b3633bb6e9b3457fcfa42121c8272ac0
* vty: enable optional-multi-choice syntax: [(one|two)]Neels Hofmeyr2019-02-041-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Since very recently we sensibly handle commands like cmd ([one]|[two]|[three]) as optional multi-choice arguments. In addition, support the more obvious syntax of cmd [(one|two|three)] Internally, the tokens are mangled to [one] [two] and [three], which is how the rest of the code detects optional args, and makes sense in terms of UI: > cmd ? [one] [two] [three] (i.e. optional arguments are always shown in braces in '?' listings) Before this patch, commands defined with a syntax like [(one|two)], would lead to an assertion (shows as "multiple") during program startup. Change-Id: I952b3c00f97e2447f2308b0ec6f5f1714692b5b2
* vty: enable optional-multi-choice syntax: ([one]|[two])Neels Hofmeyr2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add basic optional multi-choice argument support. The VTY detects optional arguments by square braces. > cmd ? [optional-arg] > cmd optional-arg ok > cmd ok However, within multi-choice args, these braces were so far not treated as optional: > list cmd2 ([one]|[two]|[three]) > cmd2 % Command incomplete In preparation for I952b3c00f97e2447f2308b0ec6f5f1714692b5b2 which will enable the more obvious syntax of cmd [(one|two)] for reasons of internal implementation, first support a syntax of cmd ([one]|[two]) The internal vty implementation always needs square braces around each option. There is currently no good way to prevent developers from defining braces inside multi-arguments, so it is easiest to allow and handle them: > list cmd2 ([one]|[two]|[three]) > cmd2 ok The VTY doesn't guard against a mix like cmd (one|[two]) With this patch, a multi-choice command is treated as optional iff the first element is in square brackets. The remaining elements' square brackets have no effect besides confusing the user. This is not explicitly checked against. In general, I would prefer to check all of these details, but the current VTY code with its endless code duplication and obscure string mangling just doesn't provide that luxury. There are numerous worse errors hidden in there. Change-Id: I9a8474bd89ddc2155c58bfca7bd038d586aaa60a
* Bump version: 0.12.0.128-8dfde → 1.0.0Harald Welte2019-01-191-1/+1
| | | | Change-Id: I1bd973754b1ebc42283f6a07defa60f58523f5a3
* Fix VTY documentation error introduced in "bind" VTY port changeHarald Welte2018-12-231-1/+2
| | | | | | | | | In 99ae401e490e60fc07bef7eacc478be7bdcc9f5a we introduced the ability to specify the TCP port to which the VTY should bind. However, the VTY dcumentation wasn't extended accordingly, causing virtually all master build jobs to fail. Change-Id: I54fb0ca0d3a884a64a349b22de70f3d9bd1a6d54
* vty: Make TCP port configurable and introduce telnet_init_defaultHolger Hans Peter Freyther2018-12-232-3/+31
| | | | | | | | | | | | | | | Extend the vty_bind_cmd VTY command to allow to optionally specify a port in addition to the IPv4 address. Introduce telnet_init_default to relieve client code from having to query the bind IPv4 address (and now the TCP port). Instead a client only needs to pass the default TCP port to use. Client code should use it like: int rc = telnet_init_default(ctx, priv, OSMO_VTY_PORT_SGSN); Change-Id: Id5fb2faaf4311bd7284ee870526a6f87b7e260f3
* vty: The telnet interface is TCP only. Fix the commentsHolger Hans Peter Freyther2018-12-221-2/+2
| | | | Change-Id: I38555c4d4f565ce21dda34fc3857c47b3d802dbd
* make 'show rate-counters' show group indexStefan Sperling2018-10-291-1/+1
| | | | | | | | | | | | | | Show each rate counter group's index in the output of the 'show rate-counters' command, to provide some way of telling apart distinct instances of the same rate counter group. This is not a very user-friendly UI because these indices are generated internally by libosmocore and/or applications, so users cannot easily assign meaning to these indices. However, the current rate counter implementation doesn't allow for more. Change-Id: Ieb151239407e4b2f8859fefec8d0670f5ddf908a Related: OS#3674
*