| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In many callers of the VTY API, we are lacking the vty_install_default() step
at certain node levels. This creates nodes that lack the 'exit' command, and
hence the only way to exit such a node is to restart the telnet session.
Historically, the VTY looked for missing commands on the immediate parent node,
and hence possibly found the parent's 'exit' command when the local node was
missing it. That is why we so far did not notice the missing default commands.
Furthermore, some callers call install_default() instead of
vty_install_default(). Only vty_install_default() also includes the 'exit' and
'end' commands. There is no reason why there are two sets of default commands.
To end this confusion, to catch all missing 'exit' commands and to prevent this
from re-appearing in the future, simply *always* install all default commands
implicitly when calling install_node().
In cmd_init(), there are some top-level nodes that apparently do not want the
default commands installed. Keep those the way they are, by changing the
invocation to new install_node_bare() ({VIEW,AUTH,AUTH_ENABLE}_NODE).
Make both install_default() and vty_install_default() no-ops so that users of
the API may still call them without harm. Do not yet deprecate yet, which
follows in Icf5d83f641e838cebcccc635a043e94ba352abff.
Drop all invocations to these two functions found in libosmocore.
Change-Id: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces a new command, which could be used to
inspect the application's talloc context directly from VTY.
To enable this feature, an application need to provide it's
context via the 'vty_app_info' struct, and register the VTY
command by calling the osmo_talloc_vty_add_cmds().
The new command is a sub-command of 'show':
show talloc-context <context> <depth> [filter]
Currently the following contexts may be inspected:
- application - a context provided by an application;
- null - all contexts, if NULL-context tracking is enabled.
A report depth is defined by the next parameter, and could be:
- full - full tree report, as the talloc_report_full() does;
- brief - brief tree report, as the talloc_report() does;
- DEPTH - user defined maximal report depth.
Also, there are two optional report filters:
- regexp - print only contexts, matching a regular expression;
- tree - print a specific context, pointed by specified address.
The command output is formatted the same way as in case of calling
the talloc_report() or talloc_report_full().
Change-Id: I43fc42880b22294d83c565ae600ac65e4f38b30d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'show online-help' produces XML output with <node id="..."> ids. We
reference those from the osmo-gsm-manuals.
Instead of numeric IDs coming from internal code, rather use a human-readable
node ID -- referencing id='config-msc' is much easier than referencing id='23'.
Add a char name[] to struct cmd_node, to hold this name. This may be provided
upon struct definition.
Since callers of the VTY API so far don't have a name yet, we would need to add
names everywhere to get meaningful node IDs. There is a way to get node ID
names without touching dependent code:
My first idea was to find out which command entered the node, i.e. command
'msc' enters the MSC_NODE. But it is impossible to derive which command entered
which node from data structs, it's hidden in the vty command definition.
But in fact all (TM) known API callers indeed provide a prompt string that
contains a logical and human readable string name. Thus, if the name is unset
in the struct, parse the prompt string and strip all "weird" characters to
obtain a node name from that. We can still set names later on, but for now will
have meaningful node IDs (e.g. 'config-msc' from '%s(config-msc)# ') without
touching any dependent code.
When VTY nodes get identical node names, which is quite possible, the XML
export de-dups these by appending _2, _3,... suffixes. The first occurence is
called e.g. 'name', the second 'name_2', then 'name_3', and so forth.
If a node has no name (even after parsing the prompt), it will be named merely
by the suffix. The first empty node will become id='_1', then '_2', '_3', and
so forth. This happens for nodes like VIEW_NODE or AUTH_NODE.
If this is merged, we need to adjust the references in osmo-gsm-manuals.git.
This can happen in our own time though, because we manually create the vty
reference xml and copy it to the osmo-gsm-manuals.git and then update the
references from the vty_additions.xml. This anyway has to happen because
currently the references tend to be hopelessly out of sync anyway, placing
comments at wildly unrelated VTY commands.
Change-Id: I8fa555570268b231c5e01727c661da92fad265de
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: This will break users' config files if they do not use consistent
indenting. (see below for a definition of "consistent".)
When reading VTY commands from a file, use indenting as means to implicitly
exit child nodes. Do not look for commands in the parent node implicitly.
The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the
current node, but succeeds on the parent node. That is the mechanism by which
our VTY config files do not need 'exit' at the end of each child node.
We've hit problems with this in the following scenarios, which will show
improved user experience after this patch:
*) When both a parent and its child node have commands with identical names:
cs7 instace 0
point-code 1.2.3
sccp-address osmo-msc
point-code 0.0.1
If I put the parent's command below the child, it is still interpreted in the
context of the child node:
cs7 instace 0
sccp-address osmo-msc
point-code 0.0.1
point-code 1.2.3
Though the indenting lets me assume I am setting the cs7 instance's global PC
to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the
0.0.1.
*) When a software change moves a VTY command from a child to a parent. Say
'timezone' moved from 'bts' to 'network' level:
network
timezone 1 2
Say a user still has an old config file with 'timezone' on the child level:
network
bts 0
timezone 1 2
trx 0
The user would expect an error message that 'timezone' is invalid on the 'bts'
level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts'
to the 'network' level, and instead says that the 'trx' command does not exist.
Format:
Consistent means that two adjacent indenting lines have the exact
same indenting characters for the common length:
Weird mix if you ask me, but correct and consistent:
ROOT
<space>PARENT
<space><tab><space>CHILD
<space><tab><space><tab><tab>GRANDCHILD
<space><tab><space><tab><tab>GRANDCHILD2
<space>SIBLING
Inconsistent:
ROOT
<space>PARENT
<tab><space>CHILD
<space><space><tab>GRANDCHILD
<space><tab><tab>GRANDCHILD2
<tab>SIBLING
Also, when going back to a parent level, the exact same indenting must be used
as before in that node:
Incorrect:
ROOT
<tab>PARENT
<tab><tab><tab>CHILD
<tab><tab>SIBLING
As not really intended side effect, it is also permitted to indent the entire
file starting from the root level. We could guard against it but there's no
harm:
Correct and consistent:
<tab>ROOT
<tab><tab>PARENT
<tab><tab><tab><tab>CHILD
<tab><tab>SIBLING
Implementation:
Track parent nodes state: whenever a command enters a child node, push a parent
node onto an llist to remember the exact indentation characters used for that
level.
As soon as the first line on a child node is parsed, remember this new
indentation (which must have a longer strlen() than its parent level) to apply
to all remaining child siblings and grandchildren.
If the amount of spaces that indent a following VTY command are less than this
expected indentation, call vty_go_parent() until it matches up.
At any level, if the common length of indentation characters mismatch, abort
parsing in error.
Transitions to child node are spread across VTY implementations and are hard to
change. But transitions to the parent node are all handled by vty_go_parent().
By popping a parent from the list of parents in vty_go_parent(), we can also
detect that a command has changed the node without changing the parent, hence
it must have stepped into a child node, and we can push a parent frame.
The behavior on the interactive telnet VTY remains unchanged.
Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
|
|
|
|
| |
Change-Id: I5bd49fbc19e88db96b4adbd56c82e7936059551c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Considering the various styles and implications found in the sources, edit
scores of files to follow the same API doc guidelines around the doxygen
grouping and the \file tag.
Many files now show a short description in the generated API doc that was so
far only available as C comment.
The guidelines and reasoning behind it is documented at
https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation
In some instances, remove file comments and add to the corresponding group
instead, to be shared among several files (e.g. bitvec).
Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
|
|
|
|
|
|
|
|
|
|
| |
Especially for short descriptions, it is annoying to have to type \brief for
every single API doc.
Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes
the first sentence of an API doc as the brief description.
Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
|
|
|
|
|
|
|
|
|
|
| |
The planned sccp-addressbook implementation in libosmo-sccp
requires two additional VTY nodes.
See also in libosmo-sccp.git:
Change-Id I068ed7f7d113dab88424a9d47bab7fc703bb7942
Change-Id: I42aa29c0cccc97f284b85801c5329b015b189640
|
|
|
|
|
|
|
|
|
|
|
|
| |
* remove unused parameter from logging_vty_add_cmds()
* mark log level descriptors static
* change internal static function int check_log_to_target() to more
appropriate bool should_log_to_target()
* deprecate log_vty_command_*() from public API as it should only be
used by logging_vty_add_cmds()
Change-Id: I0e9ddd7ba3ce211302d99a3494eb408907a2916e
Related: OS#71
|
|
|
|
|
|
|
| |
This adds several VTY nodes required by the libosmo-sigtran VTY
interface.
Change-Id: I184a7e3187b48c15c71bf773f86e188fe1daad15
|
|
|
|
| |
Change-Id: I978e1b73aa8097a7db6318d78f9f93457e6ce2af
|
|
|
|
|
|
| |
See OS#1958
Change-Id: I85aee0f8fdfc9c69d0ba9240988c633d3e707f2d
|
|
|
|
|
|
|
| |
It is still too easy to forget syncing, so add another reminder at the end
of the list.
Change-Id: I95191906afa8e6ada31310d0e36de33e3fccf268
|
|
|
|
| |
Change-Id: I08cb52d9399a27e6876e45da36f434708c4fddef
|
|
|
|
| |
Change-Id: I89212e4f149f019099115a85bab353c04170df90
|
|
|
|
|
|
|
| |
4253 used to collide with the sysmobts-mgr VTY port.
Note, openggsn does not actually have a Ctrl interface yet.
Change-Id: If0fa0e606dabd5bc89907a56ef18cdbbbdedb4b7
|
|
|
|
| |
Change-Id: I6a7bf04e589ccfaea98f20900a9bfe9dd4808dce
|
|
|
|
|
|
|
|
|
|
|
| |
For each counter group a ascii doc table is generated
containing all single counter with a reference to a section to
add additional information to the counter
Change-Id: Ia8af883167e5ee631059299b107ea83c8bbffdfb
Reviewed-on: https://gerrit.osmocom.org/70
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Tested-by: Harald Welte <laforge@gnumonks.org>
|
|
|
|
|
| |
The osmo-sip-connector is a new application and is a MNCC to SIP
bridge. It is not implementing transcoding or RTP proxying at all.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This may seem like overkill for a mere const char * config item, but it makes
the Control interface VTY commands reusable in any main() scope (inspired by
libosmo-abis' VTY config).
Add API functions ctrl_vty_init() and ctrl_vty_get_bind_addr(), in new files
src/ctrl/control_vty.c and include/osmocom/ctrl/control_vty.h, compiled and/or
installed dependent on ENABLE_VTY.
Using these functions allows configuring a static const char* with the VTY
commands
ctrl
bind A.B.C.D
which callers shall subsequently use to bind the Control interface to a
specific local interface address, by passing the return value of
ctrl_vty_get_bind_addr() to control_interface_setup().
Add CTRL_NODE to enum node_type, "eating" RESERVED4_NODE to heed that comment
on avoiding ABI changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add VTY command
line vty
bind A.B.C.D
The command merely stores the configured IP-address, which can then be used by
the calling main program to set the telnet port of the VTY line. (Commits in
openbsc and osmo-iuh will follow up on this.)
Add function vty_get_bind_addr() to publish the address in the vty.h API.
Add static vty_bind_addr to store.
For allocation/freeing reasons, a NULL address defaults to 127.0.0.1.
BTW, I decided against allowing keywords 'any' and 'localhost' in place of an
actual IP address to make sure a written config is always identical to the
parsed config.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently there is only the 'show stats' command which shows all
counter and stat_item values. This can lead to many lines of output
if there are per-subscriber rate counters.
The new command added by this commit allows it to only show groups of
a certain level (class_id), similar to the 'level' configuration
command for stats reporter.
The new command is
show stats level (global|peer|subscriber)
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
| |
This is for gtphub, being developed in openbsc.git.
Sponsored-by: On-Waves ehi
|
|
|
|
| |
Sponsored-by: On-Waves ehi
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently every time a node is added to enum node_type, this
constitutes an ABI change, since _LAST_OSMOVTY_NODE will get
incremented accordingly. In this case, every project that adds new
node type based on that value will have to be recompiled.
This commit adds 4 spare node type values, which can be replaced
one-by-one by new real types until they are exhausted to avoid
this kind of ABI change.
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
|
|
|
|
| |
Since the the stat_item and stats functions and data types are meant
to be exported, they get an osmo_ prefix.
Sponsored-by: On-Waves ehf
[hfreyther: Prepended the enum values too. This was requested by
Jacob]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit provides stats configuration similar to the log
configuration.
The following vty commands are added to the config node:
stats reporter statsd Create/Modify a statsd reporter
no stats reporter statsd Remove a statsd reporter
To actually configure a reporter, the config-stats node is entered
when the "stats reporter" command has succeeded. The following new
vty commands are available there:
local-ip ADDR Set the IP address to which we bind locally
no local-ip Do not bind to a certain IP address
remote-ip ADDR Set the remote IP address to which we connect
remote-port <1-65535> Set the remote port to which we connect
prefix PREFIX Set the item/counter name prefix
no prefix Do not use a prefix
enable Enable the reporter
disable Disable the reporter
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This file will contain the VTY code related to statistics.
This commit adds a minimal file with just as single VTY command:
- show stats This command shows all statistical values
To enable this and future commands, the main program needs to call
stats_vty_add_cmds().
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
|
| |
This functions shows the state of all osmo_counters, stat_item
groups, and counter groups.
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
| |
This functions dumps a whole stat item group to the VTY.
Sponsored-by: On-Waves ehf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are mixing enums and hope that no short-enums are used. This
is leading to a lot compiler warnings generated by clang. Change
the API to work with integers.
Porting:
The go_parent_cb implementations in the applications need to be
fixed. The API change leads to a compile time warning.
Fixes:
abis_om2000_vty.c:46:2: warning: implicit conversion from enumeration type 'enum bsc_vty_node' to
different enumeration type 'enum node_type' [-Wenum-conversion]
OM2K_NODE,
^~~~~~~~~
|
|
|
|
|
|
|
|
|
| |
For the BSC/NITB application we see that people modify the band
without modifying the ARFCN. This creates an unbootable config.
Using the new hook the BSC/NITB can check if the config is
consistent and prevent the config file being written.
Related: SYS#739
|
|
|
|
| |
... u_char not being defined on Nuttx.
|
| |
|
|
|
|
| |
imported from http://openbsc.osmocom.org/trac/wiki/PortNumbers
|
|
|
|
| |
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
|
|
|
|
|
| |
The testcase didn't work on Ubuntu 12.04 because vty_create will
directly call vty_event (e.g. not through the plt). This means
that the approach to override vty_event in the testcase failed.
Use the signal interface of libosmocore and make the testcase
use it. The signals can be generally useful as well.
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the vty_install_default() function that is basically the
install_default() function plus the registration of the commands
'exit' and 'end'. The latter is only provided in subnodes of
ENABLED_NODE and CONFIG_NONE.
The VTY test program is extended to check these commands.
Ticket: OW#952
|
|
|
|
|
| |
When you are in the config-log VTY node, you expect "end" to work
like in any other sub-node of config.
|
| |
|
|
|
|
|
| |
This function is able to generate a VTY help string based on an
array of 'struct value_string'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no real reason to keep the include directory a multi-level
recursion, so instead declare everything within include (so that we
can use proper nobase_ declarations) and be it.
Please note that since we removed the sub-Makefile.am, ./configure
will not create the directory structure for us on out-of-tree builds,
so we have to make sure the directory we're generating to exists first.
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
|
| |
|
|
|
|
| |
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
| |
|