In the logs, it is nice to see whether e.g. sanitize or -Werror args actually
made it to the gcc command line. With V=1 we see the complete command
invocations that would be hidden otherwise.
Change-Id: Ie89b1c39489ba80fb47716f4c747f2c85960e32e
So far, error reporting just says "Trap/Reply", more accurately report 'GET
REPLY', 'SET REPLY' and 'TRAP' as appropriate.
Change-Id: Ic25a251502499aeda4e2952ec4190a1fa0bebb01
Validate that incoming CTRL commands...
- have decimal IDs,
- return error on trailing characters,
- have invalid characters in variable identifiers,
- send detailed error messages as reply to the requestor.
Adjust ctrl_test.{c,ok}, which best show the change in behavior.
Message handling causes log messages on stderr; previously, stderr was empty.
Add '[ignore]' in testsuite.at so that the nonempty stderr doesn't cause test
failures.
Change-Id: I96a9b6b6a3a5e0b80513aa9eaa727ae8c9c7d7a1
This change defines the GSM FR bit positions as described
in RFC 3551, which will be used by further ECU
(Error Correction Unit) implementation.
Change-Id: I1d0a198af0f8dd1f690b5a81f5c9eb92c43aefed
There are some projects, such as OsmoBTS and OsmocomBB, which
are dealing with raw TCH payloads, so they need to have the
FR/HR/EFR frame length defined. At the moment, each project
defines them itself. Let's share these definitions.
Change-Id: Ib19dd1bf81712d034157f9ce061008be0000ef38
So far it uses 2323, a development default. Instead, assign new ports,
appending to the common range of VTY and CTRL ports: 4261 and 4262.
Related: https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers
Related: I28bd7a97d24455f88fadc6724d45c3264ba2fce4 (osmo-gsm-manuals)
Change-Id: Ife52a968a41cb286f640006587877971ff66c1a4
Recent patch I563764af1d28043e909234ebb048239125ce6ecd introduced returning
NULL from rate_ctr_group_alloc() when the index passed already exists.
Instead of returning NULL, find an unused group index and use that, adjust the
error message.
In stats_test.c, adjust, and also assert allocated counter group indexes
everywhere.
Rationale:
The original patch causes osmo-sgsn to crash as soon as the second subscriber
attempts to establish an MM context. Of course osmo-sgsn is wrong to a) fail to
check a NULL return value and crash and b) to fail to allocate an MM context
just because the rate counter group could not be allocated (it still rejects
the MM context completely if rate_ctr_group_alloc() fails).
Nevertheless, the price we pay for rate counter correctness is, at least in
this instance, way too high: osmo-sgsn becomes completely unusable for more
than one subscriber.
Numerous other places exist where rate_ctr_group_alloc() is called with a
constant index number; from a quick grep magic I found these possible breaking
points:
osmo-sgsn/src/gprs/gb_proxy.c:1431: cfg->ctrg = rate_ctr_group_alloc(tall_bsc_ctx, &global_ctrg_desc, 0);
osmo-sgsn/src/gprs/gprs_sgsn.c:139: sgsn->rate_ctrs = rate_ctr_group_alloc(tall_bsc_ctx, &sgsn_ctrg_desc, 0);
osmo-sgsn/src/gprs/gprs_sgsn.c:270: ctx->ctrg = rate_ctr_group_alloc(ctx, &mmctx_ctrg_desc, 0);
osmo-sgsn/src/gprs/gtphub.c:888: b->counters_io = rate_ctr_group_alloc(osmo_gtphub_ctx,
>phub_ctrg_io_desc, 0);
osmo-bsc/src/libfilter/bsc_msg_acc.c:87: lst->stats = rate_ctr_group_alloc(lst, &bsc_cfg_acc_list_desc, 0);
osmo-pcu/src/bts.cpp:228: m_ratectrs = rate_ctr_group_alloc(tall_pcu_ctx, &bts_ctrg_desc, 0);
osmo-pcu/src/tbf.cpp:793: tbf->m_ctrs = rate_ctr_group_alloc(tbf, &tbf_ctrg_desc, 0);
osmo-pcu/src/tbf.cpp:879: tbf->m_ul_egprs_ctrs = rate_ctr_group_alloc(tbf, &tbf_ul_egprs_ctrg_desc, 0);
osmo-pcu/src/tbf.cpp:880: tbf->m_ul_gprs_ctrs = rate_ctr_group_alloc(tbf, &tbf_ul_gprs_ctrg_desc, 0);
osmo-pcu/src/tbf.cpp:970: tbf->m_dl_egprs_ctrs = rate_ctr_group_alloc(tbf, &tbf_dl_egprs_ctrg_desc, 0);
osmo-pcu/src/tbf.cpp:977: tbf->m_dl_gprs_ctrs = rate_ctr_group_alloc(tbf, &tbf_dl_gprs_ctrg_desc, 0);
osmo-pcu/src/tbf.cpp:1475: ul_tbf->m_ctrs = rate_ctr_group_alloc(ul_tbf, &tbf_ctrg_desc, 0);
osmo-pcu/src/bts.cpp:226: m_ratectrs = rate_ctr_group_alloc(tall_pcu_ctx, &bts_ctrg_desc, 1);
We can fix all of these callers and then reconsider returning NULL, but IMO
even into the future, rate counter group indexes are not something worth
failing to provide service for. For future bugs we should keep the automatic
index picking in case of index collisions. We will get an error message barfed
and can fix the issue in our own time, while the application remains completely
usable, and even the rate counters can still be queried (at wrong indexes, but
life is tough).
Related: I49aa95b610f2faec52dede2e4816da47ca1dfb14 (osmo-sgsn's segfault)
Change-Id: Iba6e41b8eeaea5ff6ed862bab3f34a62ab976914
The recently added ctrl_cmd_parse2() returns non-NULL cmd with error messages
upon parsing errors. In handle_control_read(), use ctrl_cmd_parse2() and send
those back to the CTRL command sender as reply.
Retain the previous "Command parser error" reply only in case ctrl_cmd_parse2()
should return NULL, which shouldn't actually happen at all.
Change-Id: Ie35a02555b76913bb12734a76fc40fde7ffb244d
If a control command fails to parse, we so far discard specific error messages
and instead send just "Command parser error".
In ctrl_cmd_parse() we actually compose detailed error replies, but in the end
simply talloc_free() them and return NULL.
A first step to report these errors to the ctrl command issuer is to not return
NULL and instead return the cmd with type = CTRL_TYPE_ERROR. Add
ctrl_cmd_parse2() to return such instead of NULL.
To stay API compatible, provide ctrl_cmd_parse2() to return a cmd on errors.
ctrl_cmd_parse() retains identical behavior but becomes just a simple wrapper
around ctrl_cmd_parse2() which discards the cmd on error.
No need really to deprecate ctrl_cmd_parse() yet; especially as long as
compiler warnings might break jenkins builds.
Change-Id: I5047c9f977d70b03eea77cbcfd2b96d43ea46880
In ctrl_handle_msg() (code recently propagated from handle_control_read()),
talloc_free() the parsed ctrl_cmd in all code paths. In particular, a free was
missing in case ctrl_cmd_handle() returns CTRL_CMD_HANDLED.
CTRL_CMD_HANDLED is triggered by GET_REPLY / SET_REPLY parsing, as show by
ctrl_test.c. With the memleak fixed, adjust expected test output and make a
detected mem leak abort the test immediately.
Change-Id: Id583b413f8b8bd16e5cf92a8a9e8663903646381
The "memleak!" output shows messages that lack a talloc_free() of the parsed
ctrl command buffer. The leak shall be fixed in a subsequent patch.
Change-Id: I2c3e4d08b769b9cd77593362ea36a28d681cd042
In order to allow unit testing the ctrl iface msgb handling, have a separate
msgb entry point function from the actual fd read function.
An upcoming patch will prove a memory leak in CTRL msgb handling by a unit test
that needs this separation.
Change-Id: Ie09e39db668b866eeb80399b82e7b04b8f5ad7c3
To report invalid characters in identifiers, it is desirable to escape any
weird characters. Otherwise we might print stray newlines or control characters
in the log output.
ctrl_test.c already uses a print_escaped() function, which will be replaced by
osmo_escape_str() in a subsequent patch.
control_cmd.c will use osmo_escape_str() to log invalid identifiers.
Change-Id: Ic685eb63dead3967d01aaa4f1e9899e5461ca49a
To send a Ciphering Mode Command, we may need to derive a Kc from UMTS AKA
tokens. gsm_milenage() derives Kc from 3G tokens, but also derives an SRES.
For SRES, it requires an OPC, which may need to be derived from OP first. All
we need is a Kc, so we could feed a zero OPC ... but to simplify the function
call for cases where just a Kc is required, separate the c3 function out from
gsm_milenage(), as osmo_auth_c3(). Obviously call osmo_auth_c3() from
gsm_milenage() (meaning that osmo-hlr's 55.205 derived auc tests still cover
exactly that implementation).
Prepares: If04e405426c55a81341747a9b450a69188525d5c (osmo-msc)
Related: OS#2745
Change-Id: I85a1d6ae95ad9e5ce9524ef7fc06414848afc2aa
For validating CTRL input, we want to verify that an input variable is a series
of valid osmo_identifier_valid() separated by dots. Allow validating any
additional chars with identifiers, for CTRL vars will be just ".".
Change-Id: I13dfd02c8c870620f937d789873ad84c6b1c45de
Check that no group with the given name and index already exist before
allocating it. Add corresponding test case.
Change-Id: I563764af1d28043e909234ebb048239125ce6ecd
Related: OS#2757
The Cause IE in the 08.08 CIPHER MODE REJECT is a normal TLV IE,
and not just a value. Let's make sure we encode the cause value
properly.
Change-Id: I4f5b231edf6dcb0a9c2bbafb2a59f301f3b2402b
Closes: OS#2766
Some Abis/RSL messages such as "Release Indication" contained 3 extra
bytes from an L3 Information header which should not be there according
to specs in GSM 08.58 (section 8.3 "Radio link layer management
messages"). Other RSL messages were affected by the same issue, except
for "Establish Indication", which had already a workaround in
send_rslms_dlsap.
This commit fixes the issue in a generic way, removes the "Establish
Indication" and fixes the test accounting for the bug, as it otherwise
fails after applying the changes.
Fixes: OS#1635, OS#2336
Change-Id: Ibb116214e8b1798d65a8b0917150496a3c14f344
vty_additions.xml files provide <description>s for <node> tags, but for unknown
reasons, merge_doc.xsl explicitly omits description tags. Do not omit
<description>s so that they show up in the merged document.
This will take effect when next building the osmo-gsm-manuals using this file.
Change-Id: I418e61705043d4df047d8038c5d61623ba64f2e0
In 'show online-help' output, add the node names (currently all derived from
the prompt) as <node><name> entry, so that in the osmo-gsm-manuals, each
section of node commands gets a title. So far, each section of commands has no
name at all, and it is entirely up for guessing which part of the VTY the
commands are about.
Node section names, e.g. for OsmoHLR, will be like
1 VTY reference
1.4 config
1.5 config-log
1.6 config-line
1.7 config-ctrl
1.8 config-hlr
1.9 config-hlr-gsup
Before this patch, all but '1 VTY reference' were plain empty.
A better solution would be to list the actual command name that enters the
node, and to nest the commands identically to VTY node nesting, but since this
information is currently hidden in node command implementations, it is
impossible to derive it. So we should actually make the VTY reflect the node
nesting structure in its data model, which would resolve both the accurate node
name problem as well as produce well-structured output to generate the VTY
references from. This patch is a workaround for lack of a more profound fix of
the VTY data model. At least it makes the VTY references' sections even
remotely useful.
Change-Id: Iaf745b2ab3d9b02fc47025a0eba3beb711068bfe
We use 'show online-help' to generate VTY reference manuals. It is not helpful
to include the common node commands on each and every node level, it clutters
the actual useful help.
Have a separate first section called 'Common Commands', but omit them
elsewhere.
Change-Id: Ie802eccad80887968b10269ff9c0e9797268e0d4
This was always intended to be GPL and not AGPL. "kat" did the
development as part of an internship paid by me and we agreed
to shared copyright.
Change-Id: Ied2041ba20c5737bd967dfaa3017edf72a95b31c
The external sercomm_drv_[un]lock() functions are defined as stubs in
case of non-embedded build only which causes linking issue with
sercomm_test. Let's define the same stubs in sercomm_test
unconditionally - the implementation details of the locking are
irrelevant for the test anyway.
Related: OS#2708
Change-Id: I3dab4f3348871b66b5d6c9fd10b2e448c61f9e73
When creating asciidocs for osmo_counter an empty is not useful.
If there aren't any counter, output a hidden comment
Change-Id: Ie2768100e69dcd7d8d77533688585dd9b43c4a5e
In case of embedded build some tests are failing to link properly. Fix
it:
* do not run fsm_test unless CTRL is enabled
* do not run fr_test unless GB is enabled
* do not link loggingrb_test with libosmovty
Change-Id: Icedad5ba3ed311ccdb97fa3ccd3002f5fda8be68
For the lua console printing I need to print several values with
continuation but also specify the filename. Add a "C" for continue
and forward arguments.
Change-Id: I1d6dcb2567b9ed2c8767f661737b979bc3d1377e
* remove duplicate code: use function from libosmocore
* use utility function to dump ubits
* reformat for easier reading
* link against libosmocore
Change-Id: I8c31b0954176a2c53305936a025c92a793b6d9b6
Previously ctrl request for all counters in
group (e. g. 'rate_ctr.abs.msc.0') will result in human-readable
description which is not regular enough and is hard to both parse and
generate. The ctrl interface is intended for m2m, not for human
interaction. Let's simplify things by making response similar to counter
group request ('rate_ctr.*').
Reply now looks as follows:
GET_REPLY 9084354783926137287 rate_ctr.abs.msc.0 loc_update_type:attach 0;loc_update_type:normal 0;
Previously it was:
GET_REPLY 9084354783926137287 rate_ctr.abs.msc.0 All counters in msc.0
loc_update_type:attach 0
loc_update_type:normal 0
Change-Id: I7a24cc307450efdcd28168fffe477320c59fcd36
Related: OS#2550
When calling the timer_cb, that may have effected an fi termination and
deallocation, e.g. from dispatching events and/or complex choices made.
Current timer_cb implementations expect T to reflect the fired timer number, so
we can't actually set T=0 before calling the timer_cb.
Instead, never reset T to zero, let it always reflect the timer that last
fired. When a new timer starts, T will be set to its new value.
Adding a T arg to the timer_cb() would have been the cleanest solution, so that
fi->T can be set to zero before dispatching the timer_cb. But since we've
already rolled out this FSM API, we should stay backwards compatible.
In the case where the timer returned 1 to request termination, we can assume
that the fi still exists, but to be consistent, don't set T = 0 in that code
path either.
Change-Id: I18626b55a1491098b3ed602df1b331f08d25625a
This should never happen with the current code, but if it ever does, we
should log the error instead of silently returning 0.
Change-Id: I544001d3072e5f12a96a67e4178f9b945c5f6b6c
Related: OS#2550
Harald Welte
Neels Hofmeyr
Philipp Maier
Pau Espin