| 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
L_NS_NODE and L_BSSGP_NODE had specialized 'exit' and 'end' vty commands, but
all they do is return to the CONFIG and ENABLE_NODEs like the default 'exit'
and 'end' commands. Drop them and use the default 'exit' and 'end' cmds.
Examining BSSGP and NS node behavior in osmo-sgsn exhibited identical list and
exit/end behavior before and after this patch.
Prepares for an upcoming commit incorporating vty_install_default() into
install_node(), see I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b: this patch
changes to the default commands, the upcoming change implies them.
Change-Id: I5b0de066b4249d482c22620d5b1bcb03f381293c
|
|
|
|
|
|
|
| |
Add trailing space and 'config-' prefix to match our common VTY node prompt
style.
Change-Id: I88db128cad9fcc6e53326b4aed5d06ea9102f328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 'vty_app_info' struct could be used by some applications to
provide its talloc context. In the future, it will facilitate
the implementation of talloc context introspection via VTY.
But the 'vty' talloc context, that contains lots of items
(memory chunks), is being bound to an application's one,
so it becomes hard to read the last.
Let's do not bind the 'vty' context automatically, until some
common talloc context export policy is implemented.
Change-Id: I9cb6ce9f24dbae400029e2d9f9c933fbfb16248f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'show online-help' produces XML output with <node id="..."> ids. We
reference those from the osmo-gsm-manuals, but until now, these ids fall out of
sync when the amount of VTY nodes changes.
Change these ids to use the internal node ID constant (as in enum bsc_vty_node)
instead of a simple counter.
If this is merged, we need to adjust the references in osmo-gsm-manuals.git.
Change-Id: Ib07fb9d9106e19f5be6539493e82b5d5991f8bc2
|
|
|
|
| |
Change-Id: Ia58c16d995f6751bdd69defe8a46665aee163f3d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The recent exit-by-indent patch breaks a VTY case where a node is entered but
directly followed by a sibling or ancestor without listing any child nodes.
Regression introduced by I24cbb3f6de111f2d31110c3c484c066f1153aac9.
An example is a common usage in osmo-bts, where 'phy N' / 'instance N' is a
parent node that is commonly left empty:
phy 0
instance 0
bts 0
band 1800
Before this patch, this case produces the error:
There is no such command.
Error occurred during reading the below line:
bts 0
Fix indentation parsing logic in command.c to accomodate this case.
Add a unit test for empty parent node.
Change-Id: Ia0880a17ae55accb092ae8585cc3a1bec9986891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For interactive telnet VTY, remove the implicit move up to the parent node when
a command did not succeed on the current node level.
When reading config files, this behavior was useful to allow skipping explicit
'exit' commands. (A different patch deals with that.)
In the telnet VTY, this behavior was never necessary. Explicit 'exit' commands
can move to the parent node, and typically uninformed users expect to require
that.
On a telnet VTY, counting indents like for reading config files is not an
option: a user will always type from the first column or may paste some leading
spaces without intended meaning.
After this patch, it is thus no longer possible to paste a complete config
across several node levels directly to a telnet session, unless it contains
'exit' commands.
Change-Id: Id73cba2dd34676bad8a130e9c45e67a272f19588
|
|
|
|
|
|
|
|
|
|
| |
libosmocore offers the ipa API as general IPA Multiplex, which is e.g. used for
GSUP in osmo-msc. Looking at talloc reports, it is confusing to see "Abis/IP"
as msgb comment, because osmo-msc does not have an Abis interface.
Rename to "IPA Multiplex" as a more general description.
Change-Id: I3714dd21707bec0c4bcd0871e6ee8ff32d56b125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is very minor but it annoys every time I see it.
The text: "Error occurred during reading below line:"
is not a complete sentence. The default understanding
in english having left out the article implies
that the error occured reading below [the] specified line, not
that the error occured reading [the] specified line.
That is to say, The message implied that the printed line
was the last successfully parsed line.
Change-Id: Ib4dd135feb9609b14983db5dac321a70267d8f30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lapd_est_req() function could be called on uninitialized lapd link
(before lapd_dl_init() and after lapd_dl_exit() functions) due to
invalid usage on higher levels.
In order to prevent using uninitialized lapd link, we should set
LAPD_STATE_NULL state for lapd_datalink in lapd_dl_exit() function.
So all messages for lapd_datalink in null state will be unhandled by
lapd_recv_dlsap() function and lapd_est_req() function will not be
called before lapd_dl_init() function where lapd link state is changed
to idle.
#0 0x00007f46ecd99aa5 in lapd_est_req (dp=<optimized out>, lctx=0x7f46ed80b8b8) at
lapd_core.c:1769
#1 0x00007f46ecd9dda8 in rslms_rx_rll_est_req (msg=msg@entry=0x7f46eeab4940,
dl=dl@entry=0x7f46ed80b888) at lapdm.c:845
#2 0x00007f46ecd9fc03 in rslms_rx_rll (lc=0x7f46ed80b398, msg=0x7f46eeab4940) at
lapdm.c:1157
#3 lapdm_rslms_recvmsg (msg=0x7f46eeab4940, lc=0x7f46ed80b398) at lapdm.c:1223
#4 0x00007f46ed63773d in rsl_rx_rll (msg=<optimized out>, trx=<optimized out>) at
rsl.c:2178
#5 down_rsl (trx=<optimized out>, msg=<optimized out>) at rsl.c:2541
#6 0x00007f46ed641529 in sign_link_cb (msg=<optimized out>) at abis.c:169
#7 0x00007f46ec54b111 in ipaccess_bts_read_cb (link=0x7f46eeab4940, msg=0x0) at
input/ipaccess.c:807
#8 0x00007f46ec548a8e in ipa_client_read (link=0x7f46ee26ae30) at input/ipa.c:74
#9 ipa_client_fd_cb (ofd=<optimized out>, what=1) at input/ipa.c:137
#10 0x00007f46ecfc726f in osmo_fd_disp_fds (_eset=0x7ffe7a9fcd20, _wset=0x7ffe7a9fcca0,
_rset=0x7ffe7a9fcc20) at select.c:167
#11 osmo_select_main (polling=polling@entry=0) at select.c:207
#12 0x00007f46ed63fc25 in bts_main (argc=5, argv=<optimized out>) at main.c:359
#13 0x00007f46ebd76f45 in __libc_start_main (main=0x7f46ed61b120 <main>, argc=5,
argv=0x7ffe7a9fcf18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
#14 0x00007f46ed61b14e in _start ()
Related: OS#1982
Change-Id: I306dad9b78e3becaef14c5305ec25c312feefe3c
|
|
|
|
|
|
|
|
| |
Despite the libosmocoding.map is preset since the library release,
one was not used in a proper way. The LTLDFLAGS were missing, so
let's add them.
Change-Id: Idf677825ff642d50bea43c7f970810783e864fdd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing UMTS AKA with AUTS, it can be interesting to know the SQN.MS that
was encoded in the AUTS. The only way to know this is to provide it as a
separate out-parameter from milenage_gen_vec_auts(), because the SQN.MS from
AUTS stored in umts.sqn is immediately modified non-trivially by
milenage_gen_vec(). Add sqn_ms to struct osmo_sub_auth_data to retain SQN.MS
even after a vector was generated.
Use this to print out SQN.MS for 'osmo-auc-gen -3 -A'.
Adjust test suite expectations.
Related: OS#2464
Change-Id: I9fc05bbf169d06716f40b995154fd42a3f91bef3
|
|
|
|
| |
Change-Id: I72569ed767b6a4d792b2867d02caa65520e27cd3
|
|
|
|
|
|
|
|
| |
From GSM 03.40: "The Service-Centre-Time-Stamp, and any other times
coded in this format that are defined in this specification,
represent the time local to the sending entity."
Change-Id: I4efdb1eaae43aced33961b64d4f14b0040321c10
|
|
|
|
|
|
|
|
|
| |
We only implemented OPC generation from OP in the AUTS case, but not
in the case of normal authentication vector generation. This never
really was visible so far due to the fact that we use OPC at sysmocom,
and never the shared OP value.
Change-Id: Id3fa038dfc2ff1ba63616fa5e8eab0520481ff26
|
|
|
|
|
|
|
|
| |
This basically follows the concept of osmo_timer_setup() and allows
the caller to fill-in all configurable fields of osmo_fd in one
line of code, rather than open-coding it in 5 lines everywhere.
Change-Id: I6dbf19ea22fd65302bfc5424c10418d1b7939094
|
|
|
|
|
|
| |
Those functions can be used to look up the size of (E)GPRS blocks.
Change-Id: I05ff75ef7dfae639886bbd09fe35f03a8af9d988
|
|
|
|
| |
Change-Id: Icc772285636c06e1075a89809f0ac379d7a0002c
|
|
|
|
| |
Change-Id: I88a06e8ba894f16006a8efa259fc536cf300de32
|
|
|
|
|
| |
Change-Id: I9bf8f4dd784ccddbb9926492a85fff3293a0e913
Related: OS#1638
|
|
|
|
|
|
|
|
|
| |
If osmo_sock_init2() was used with CONNECT flag but without BIND
flag, an invalid check for "did we create a socket yet" caused
the socket to never be created, and subsequently the entire function
to return an error.
Change-Id: I0206dbb9c5b8f74d7fb088576941b092acd2ca22
|
|
|
|
|
|
|
| |
In the course of splitting up the openbsc.git repository, we will create
libosmo-mgcp and need a library logging category for that purpose.
Change-Id: I09c587e2d59472cbde852d467d457254746d9e67
|
|
|
|
| |
Change-Id: I320b379429aaf0f7351aed5e4f72a481cc268c05
|
|
|
|
| |
Change-Id: I3e69fba0e21e181d28baee90e95f57216f2617af
|
|
|
|
| |
Change-Id: Ie1853697f4cff5ff98654fa1cae6c68e28a0076b
|
|
|
|
|
|
|
| |
Using this option at socket creation, the caller can request disabling
the IP_MULTICAST_ALL socket option.
Change-Id: I5ab5de45c0b64ceb3636ea98245a23defa24ffd4
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new flag OSMO_SOCK_F_NO_MCAST_LOOP, which can be used
to disable the looping back of multicast packets transmitted throug this
socket to other local sockets on the machine.
As this looping-back is active by default, a single option to deviate
from the default is deemed sufficient.
Change-Id: I24a5b1ebc3f84d2d5d4734e54df50efaea26490b
|
|
|
|
|
|
|
|
|
| |
We had three places at the end of socket initialization functions
calling listen(). Let's unify that and fix some bugs:
* close + return error in case of bad listen() result
* don't call listen() on AF_UNIX SOCK_DGRAM sockets
Change-Id: I7e8dbe3c0486bb3b9810b0add1331e93fc106d82
|
|
|
|
| |
Change-Id: Id703e7a7a1e065181a4c76c088b8dcc1b7fe15a2
|
|
|
|
|
|
|
|
|
| |
This is a convenience helper that will both close a fd, mark it as
closed and unregister it from the event loop abstraction. In most
cases, you probably actually want to use it instead of manually closing
and calling osmo_fd_unregister().
Change-Id: Icd0933eed6a24edde7cdcb378e138897ecc5332c
|
|
|
|
| |
Change-Id: Iaf8a99912f42a56ef785a1642e18238c0b67cf68
|
|
|
|
| |
Change-Id: Ie1bc00670887064da0fea61c3dab036c23ceea25
|
|
|
|
|
|
|
| |
Convert a given frame number into a printable string that displays
the sub components of the frame number.
Change-Id: I8015d2ded3940b01b35df7b72fc35c70c25e9926
|
|
|
|
|
|
|
| |
These PRBS sequences are specified in ITU-T O.150. They are typically
used as test data to be transmitted for BER (bit error rate) testing.
Change-Id: I227b6a6e86a251460ecb816afa9a7439d5fb94d1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* when reading config file (or vty command) ignore "logging level
.. everything" level
* when writing config file, skip "logging level .. everything" level
In both cases print corresponding deprecation warning. The "everything"
level is not working as advertised for quite some time anyway.
This will allow us to gradually deprecate broken "everything" parameter
giving users enough time to update their config files before removing it
entirely.
Change-Id: I73d5c4f238beb88981ad25caa69f64ad6fb7209f
Related: OS#71
|
|
|
|
|
|
| |
Used by osmo-bts, moved from osmo-bts l1sap.c:dump_gsmtime.
Change-Id: Ib5452e2c20f53006c0f6d197fb055728947125d8
|
|
|
|
|
|
|
|
| |
These fields can be in the ISD and the PDP Context inofmration. Store
pointers to this IE in both cases. It needs to be used by the SGSN
when opening a PDP context.
Change-Id: Iedc7c02adcf77ca5c9545119e19c968dfbbb3e6b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a string like
127.0.0.1:2905<->127.0.0.1:60661
it is hard to tell which is the local part. I'd have expected it on the left,
but it is actually on the right.
To avoid doubt and bypass bikesheds on which side should be what, clearly mark
the two sides as remote and local.
(r=127.0.0.1:2905<->l=127.0.0.1:60661)
Change-Id: I43dcc6a1906429bd0955fd7fe2eb5b8495b592d8
|
|
|
|
|
|
| |
Add values from 3GPP TS 48.018
Change-Id: Ie39a6c91a46d179392d861805a106743a07c6fb0
|
|
|
|
|
|
|